Umfassende Erklärung zum CocosCreator Hot Update

Vorwort

Dieser Artikel zitiert hauptsächlich die offizielle Dokumentation von Cocos zu Hot-Updates und fasst auf dieser Grundlage den aktuellen Hot-Update-Prozess von Sprout zusammen.

Was ist Hot Change

Hot Updates laden im Wesentlichen die erforderlichen Ressourcen vom Server auf das lokale Gerät herunter und führen eine neue Spiellogik aus, damit die neuen Ressourcen vom Spiel verwendet werden können. Entwickler können damit Fehler beheben und Funktionen freigeben, ohne eine neue Version herauszubringen. So können Entwickler den Überprüfungsmechanismus von Apple umgehen und lange Überprüfungswartezeiten sowie die Kosten mehrerer Ablehnungen vermeiden.

Der standardmäßige Hot-Update-Mechanismus von Cocos basiert nicht auf dem Patch-Paket-Update-Mechanismus. Herkömmliche Hot-Updates generieren häufig Patch-Pakete für mehrere Versionen, laden die Patch-Pakete nacheinander herunter und aktualisieren auf die neueste Version. Der Hot-Update-Mechanismus von Cocos generiert und aktualisiert eine Differenzliste, indem er die neueste Version direkt mit der lokalen Version vergleicht.

Cocos Hot Update Übersicht

Manifest

Bevor Sie das Cocos Hot Update verstehen, müssen Sie zuerst das Manifest verstehen. In Cocos ist Manifest ein Dateiformat und die entsprechende Datei wird als Ressourcenbeschreibungsdatei bezeichnet, die zum Beschreiben der lokal oder remote enthaltenen Ressourcenliste und Ressourcenversion verwendet wird.

Das Manifestformat ist dem JSON-Format nachempfunden und die Bedeutungen seiner Schlüsselfelder sind wie folgt:

{
    "packageUrl": lokaler Cache-Stammpfad der Remote-Ressourcen"remoteVersionUrl": [optional] Pfad der Remote-Versionsdatei, wird verwendet, um zu bestimmen, ob es eine neue Version der Ressource auf der Serverseite gibt"remoteManifestUrl": Pfad der Manifestdatei der Remote-Ressource, einschließlich Versionsinformationen und aller Ressourceninformationen"version": Ressourcenversion"engineVersion": Engine-Version"assets": Liste aller Ressourcen"key": relativer Pfad der Ressource (relativ zum Stammverzeichnis der Ressource)
        "md5": Der MD5-Wert stellt die Versionsinformationen der Ressourcendatei dar. "compressed": [optional] Wenn der Wert true ist, wird die Datei nach dem Herunterladen automatisch dekomprimiert. Derzeit wird nur das ZIP-Komprimierungsformat unterstützt. "size": [optional] Die Bytegröße der Datei, die verwendet wird, um schnell Fortschrittsinformationen abzurufen. "searchPaths": Die Suchpfadliste, die zu FileUtils hinzugefügt werden muss}

Die Manifestdatei kann im Hot-Update-Beispiel von Cocos Creator automatisch vom Version Generator-Skript generiert werden.

Der Unterschied zwischen Projektressourcen und Spielpaketressourcen

Wenn Sie ein Cocos Creator-Projekt erstellen, wird darunter ein Assets-Verzeichnis angezeigt, in dem Ihre Szenen, Skripte, Prefabs usw. entsprechend dem Assets-Bereich im Editor gespeichert sind. Diese Projektressourcen entsprechen jedoch nicht den gepackten Ressourcen. Wenn wir das Build-Panel zum Erstellen der nativen Version verwenden, finden wir die Ordner res und src im Build-Verzeichnis. Diese beiden Ordner enthalten die Spielpaketressourcen, die das Spiel tatsächlich ausführen. src enthält alle Skripte und res enthält alle Ressourcen.

Daher sollte unser Hot-Update von Ressourcen natürlich die erstellten Ressourcen und nicht das Assets-Verzeichnis des Projekts aktualisieren.

In Creator2.4.3 wurde das Ressourcenverwaltungsmodul neu aufgebaut und zur Verwaltung der Ressourcen wurde die Bundle-Modularisierung verwendet. Hier ist eine API, um den Ressourcenpfad über die UUID abzurufen

cc.assetmanager.utils.getUrlWithUuid //UUID in URL umwandeln. Die hier zurückgegebene URL ist der Ressourcenpfad im Runtime-Spielpaket

SuchpfadeSuchpfade

Bevor wir über Hot Updates sprechen, müssen wir das Konzept der Suchpfade verstehen. Wenn wir den Pfad einer Datei beschreiben, geben wir meistens den entsprechenden „relativen Pfad“ basierend auf einem „Stammverzeichnis“ an und schreiben ihn nicht direkt als „absoluten Pfad“. Dies ist für die Wartung und Migration förderlicher. Bei der Spieleentwicklung ist es tatsächlich schwierig, die Sicherheit und Eindeutigkeit unseres „Stammverzeichnisses“ sicherzustellen. Nehmen wir als Beispiel die Hot-Update-Funktion. Wir haben ein Bild. Angenommen, der relative Pfad des entsprechenden Bundle-Verzeichnisses (der Standardwert ist „Ressourcen“) lautet „./png/icon1.png“. Wenn unsere Spielversion aktualisiert wird und das Bild aktualisiert werden muss, können wir das neue Bild nur von einem anderen Ort lesen lassen, da die Ressourcen im Paket nicht beschreibbar sind. Um die Konsistenz des Codes sicherzustellen, müssen die vorherigen relativen Pfade im Code nicht geändert werden, wenn wir das entsprechende „Stammverzeichnis“ ändern können, und das neue Bild kann gefunden werden.

Im Creator wird eine Reihe von Suchpfadstrategien verwaltet. Die entsprechenden APIs finden Sie unter jsb.fileUtils.getSearchPaths, jsb.fileUtils.fullPathForFilename usw. Das Prinzip sei hier kurz beschrieben. FileUtils speichert ein Array von „Stammverzeichnissen“. Je niedriger der Index, desto höher die Priorität. Wenn wir bei der Suche nach Ressourcen einen „relativen Pfad“ angeben, wird dieser entsprechend der Priorität des „Stammverzeichnisses“ in searchPaths in einen „absoluten Pfad“ gespleißt, um nach Ressourcen zu suchen. Wenn der Pfad gültig ist und die Datei gefunden wird, wird die Suche beendet.

Im Installationsverzeichnis des Spielpakets muss ein Verzeichnis vorhanden sein, in dem die verschiedenen Skripte und Ressourcen gespeichert werden, die wir gepackt haben. Wir nennen es hier das „Spielpaketverzeichnis“. In der Hot-Update-Logik müssen wir ein „Hot-Update-Verzeichnis“ angeben, in dem unsere Hot-Update-Inhalte gespeichert werden. Beide Verzeichnisse sollten als Suchpfade festgelegt werden, und die Versionen müssen so gesteuert werden, dass die entsprechende Suchpfadpriorität umso höher ist, je höher die Priorität des Verzeichnisses ist. Auf diese Weise können wir die neuesten Dateien finden. Im Allgemeinen muss die Priorität des „Hot Change-Verzeichnisses“ höher sein als die des „Spielepaketverzeichnisses“.

Grundlegender Hotfix-Prozess von Cocos

Dies ist das Flussdiagramm der offiziellen Cocos-Website. Bitte beachten Sie, dass der aktuelle Vorgang das erste Mal ist, dass der Benutzer nach der Installation der App das Update der Serverversion überprüft. Der vollständige Hot-Update-Prozess wird komplizierter und wir werden ihn später langsam ergänzen.

Dieser Artikel hilft Ihnen hauptsächlich dabei, die Prozesslogik des Hot-Updates selbst zu verstehen. Auf Einzelheiten wie die Wiederaufnahme von Haltepunkten, den Download-Fortschritt, gleichzeitige Downloads, Fehlererkennung, Dekomprimierung, Fehlerbehebung und andere Details wird vorerst nicht eingegangen. Daher kann das Flussdiagramm für die Berufung wie folgt zusammengefasst werden:

Laden Sie gemäß dem Feld remoteVersionUrl des Manifests im aktuellen Paket die aktuelle Versionsbeschreibungsdatei herunter und vergleichen Sie sie dann mit der lokalen Version. Wenn ein Update erforderlich ist, aktualisieren Sie es auf die entsprechende neueste Version. Andernfalls ist kein Update erforderlich und fahren Sie mit dem nachfolgenden Vorgang fort.

Hier müssen wir einige wichtige Punkte genauer analysieren:

_localManifest: das Manifest im aktuellen Paket

Zunächst sollte im „Spielpaketverzeichnis“ eine Standardmanifestdatei vorhanden sein, die die aktuelle Spielversion beschreibt (das Feld „Version“). Dieses Manifest wird im Allgemeinen aktualisiert, wenn das Spielpaket deinstalliert oder installiert wird. Anschließend wird es im „Hot-Change-Verzeichnis“ auch eine Manifestdatei geben, die die Versionsinformationen unter dem aktuellen Hot-Change-Verzeichnis beschreibt. Bei jedem Start des Spiels sollten wir feststellen, ob das „Spielpaketverzeichnis“ oder das „Hot Change-Verzeichnis“ die neueste Version in der aktuellen Umgebung ist, und die entsprechende Priorität in searchPaths anpassen. Das neuere Manifest wird auch als Manifest im aktuellen Paket bezeichnet und im Code mit _localManifest aufgezeichnet.
Beachten Sie, dass es im obigen grundlegenden Hot-Update-Prozess von Cocos keinen solchen Schritt gibt, da es sich um die erste Installation des Pakets handelt. Im Hot-Update-Verzeichnis gibt es keine Manifestdatei, daher ist _localManifest das „Spielpaketverzeichnis“. Der vollständige Hot-Update-Prozess erfordert diesen Beurteilungsschritt.
Den Code, der der obigen Logik entspricht, finden Sie in den Funktionen „init“, „loadLocalManifest“ und anderen Funktionen von AssetsManagerEx.

Fordern Sie zuerst das Remote-Versionsmanifest an

Im Feld „remoteVersionUrl“ des Manifests entspricht es der Versionsdatei des Remote-Servers. Hier ist ein Versionsmanifest der offiziellen Demo zu Ihrem Verständnis.

{
    "packageUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/",
    "remoteManifestUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/project.manifest",
    "remoteVersionUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/version.manifest",
    "Version": "2.0"
}

Wie Sie oben sehen können, verfügt version.manifest über ein Feld „Version“, das auch die Grundlage für unseren schnellen Versionsvergleich ist. Laden Sie version.manifest herunter und vergleichen Sie es dann mit der lokalen _localManifest-Version, um festzustellen, ob das aktuelle Paket aktualisiert werden muss. Dieser Vorgang wird im Code im Allgemeinen checkUpdate genannt.

Die Notwendigkeit temporärer Ordner

Da wir während des Hot-Update-Prozesses mehrere Ressourcen nacheinander herunterladen, treten während dieser Zeit wahrscheinlich verschiedene Probleme auf. Daher benötigen wir einen temporären Ordner, um unsere Downloads vorübergehend zu speichern. Nachdem alle Dateien heruntergeladen wurden, müssen wir auch prüfen, ob die Dateien vollständig sind, bevor wir die alten Ressourcen im „Hot-Update-Verzeichnis“ ersetzen. Laden Sie nicht direkt in das „Hot-Update-Verzeichnis“ herunter. Sobald ein Problem auftritt, können Sie nicht herausfinden, welcher Teil neu und welcher Teil alt ist. Diese Idee lässt sich auch bei der Programmgestaltung anwenden. Bei der Pflege der Daten und Felder, für die wir verantwortlich sind, sollten wir versuchen, diese als Ganzes zu ersetzen und zu aktualisieren, anstatt sie willkürlich zu ändern und Werte zuzuweisen.

Heißer ist heißer und differenziertere Dateien. Wie machen wir das?

Notieren Sie in der Manifestdatei im Feld „Assets“ die Schlüssel- und MD5-Informationen jeder Ressource. Sie müssen nur die im Remote-_remoteManifest aufgezeichneten Ressourcen vergleichen. Neue Schlüssel sind neu hinzugefügte Ressourcen und Ressourcen ohne Schlüssel müssen gelöscht werden. Dateien mit unterschiedlichen MD5s sind Dateien, die aktualisiert werden müssen.
Den entsprechenden Code finden Sie unter: genDiff und andere Funktionen des Manifests.

Nachdem die Hitze besser ist, wie man sie wirksam macht

Wenn wir neue Ressourcen hinzugefügt haben, wie können wir dafür sorgen, dass diese wirksam werden, ohne den Code anzupassen? Haha, wie ich oben gerade vorgestellt habe, müssen wir nur unsere Suchpfade so anpassen, dass das „Hot Change-Verzeichnis“ eine höhere Priorität hat als das „Spielepaketverzeichnis“.
Im obigen Flussdiagramm empfiehlt Cocos, cc.sys.localStorage zu verwenden, um den _localManifest entsprechenden Pfad zu speichern, und zu Beginn des nachfolgenden App-Starts den entsprechenden Pfad aus cc.sys.localStorage zu lesen und auf searchPaths festzulegen.
Die obige Lösung ist sicherlich machbar, aber für ein vollständiges Client-Framework, insbesondere für Lobby-Spiele mit mehreren Unterprojekten, halte ich persönlich diesen dynamischen Speicherpfad und Einstellungspfad nicht für eine geeignetere Lösung. In Bezug auf das Architekturdesign müssen wir zunächst das „Hot Change Directory“ des gesamten Clients bestimmen und die Priorität festlegen, d. h. die Suchpfade des gesamten Projekts werden gemäß der von uns festgelegten Logik festgelegt, anstatt dynamisch angepasst zu werden. Dies hat den Vorteil, dass die Suchpfadlogik an einer eindeutigen Stelle bestimmt wird und dann nur die Ressourcen unter dem entsprechenden Pfad gemäß der Logik hinzugefügt oder gelöscht werden müssen, was die Erweiterung und Wartung erleichtern sollte. Es ist jedoch auch zu beachten, dass bei dieser Lösung mit festen Suchpfaden beim Installieren und Ersetzen der App der Vergleich zwischen der neuen Version des „Spielpaketverzeichnisses“ und der vorherigen Version im „Hot Change Directory“ beibehalten werden muss. Wenn beispielsweise die Version nach der lokalen Installation und Aktualisierung der App höher ist als die vorherige Version des „Hot Change Directory“, können Sie erwägen, alle Ressourcen unter dem vorherigen „Hot Change Directory“ zu löschen. Eine andere, problematischere Logik ist, dass die Version nach der Installation und Aktualisierung der App immer noch niedriger ist als die Version des „Hot Change Directory“. Es ist zu beachten, dass das „Hot Change Directory“ vor der Aktualisierung differenzielle Dateien relativ zum „Spielpaketverzeichnis“ speichert. Nach der Aktualisierung ändern sich die Dateien im „Spielpaketverzeichnis“, sodass die differenziellen Dateien im „Hot Change Directory“ möglicherweise nicht mit dem aktuellen „Spielpaketverzeichnis“ kompatibel sind. In diesem Fall kann das „Hot Change Directory“ auch erneut verglichen und die differenziellen Dateien im laufenden Betrieb geändert werden.

So gehen Sie mit Ressourcen alter Versionen um

Obwohl das Hot-Update von Cocos eine Differenzdatei ist, zeichnet sein Manifestskript alle Ressourcen des entsprechenden Bundles auf. Wir können wissen, welche Ressourcen nicht mehr benötigt werden. Die Funktion genDiff wurde oben ebenfalls erwähnt, aber ich persönlich denke, dass beim Löschen alter Ressourcen Vorsicht geboten ist. Stellen Sie zumindest sicher, dass die neuen Ressourcen aktualisiert werden, bevor Sie die alten Ressourcen löschen.

Zusammenfassen

Wenn die Leser das oben genannte Wissen verarbeiten und die von Cocos bereitgestellten Grundfunktionen verwenden, können sie ihren eigenen Hot-Update-Prozess vollständig anpassen. Kurz gesagt lädt ein Hot Update die neuesten Remote-Ressourcen herunter, um die vorhandenen Ressourcen im aktuellen Paket zu ersetzen. Beispielsweise können Sie bei einigen kleinen Projekten das gesamte Paket herunterladen und ersetzen und Details wie Versionsvergleich, Suchpfadanpassung, Dateiüberprüfung usw. ignorieren.

Oben finden Sie eine umfassende Erläuterung der Details des CocosCreator-Hot-Updates. Weitere Informationen zum CocosCreator-Hot-Update finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!