CocosCreatorのホットアップデートの包括的な説明

序文

この記事では、主に Cocos のホット アップデートに関する公式ドキュメントを引用し、これに基づいて、Sprout の現在のホット アップデート プロセスを要約します。

ホットチェンジとは

ホットアップデートは基本的に、必要なリソースをサーバーからローカルデバイスにダウンロードし、新しいゲームロジックを実行して、ゲームで新しいリソースを使用できるようにします。これにより、開発者は新しいバージョンをリリースせずにバグを修正し、機能をリリースできるため、Apple のレビューメカニズムを回避し、長いレビュー待ち時間と複数の拒否によるコストを回避できます。

Cocos のデフォルトのホット アップデート メカニズムは、パッチ パッケージ アップデート メカニズムに基づいていません。従来のホット アップデートでは、多くの場合、複数のバージョンのパッチ パッケージが生成され、パッチ パッケージが順番にダウンロードされて最新バージョンにアップデートされます。 Cocos のホット アップデート メカニズムは、最新バージョンとローカル バージョンを直接比較して、差分リストを生成し、更新します。

Cocos Hot アップデートの概要

マニフェスト

Cocos Hot Update を理解する前に、まずマニフェストを理解する必要があります。 Cocos では、マニフェストはファイル形式であり、それに対応するファイルはリソース記述ファイルと呼ばれ、ローカルまたはリモートに含まれるリソース リストとリソース バージョンを記述するために使用されます。

マニフェスト形式は JSON 形式をモデルにしており、その主要フィールドの意味は次のとおりです。

{
    "packageUrl": リモート リソースのローカル キャッシュ ルート パス"remoteVersionUrl": [オプション] リモート バージョン ファイルのパス。サーバー側にリソースの新しいバージョンがあるかどうかを判断するために使用されます。"remoteManifestUrl": バージョン情報とすべてのリソース情報を含むリモート リソース マニフェスト ファイルのパス。"version": リソースのバージョン。"engineVersion": エンジンのバージョン。"assets": すべてのリソースのリスト。"key": リソースの相対パス (リソース ルート ディレクトリを基準)
        "md5": md5 値はリソース ファイルのバージョン情報を表します "compressed": [オプション] 値が true の場合、ファイルはダウンロード後に自動的に解凍されます。現在サポートされているのは zip 圧縮形式のみです "size": [オプション] 進行状況をすばやく取得するために使用されるファイルのバイト サイズ "searchPaths": FileUtils に追加する必要がある検索パス リスト}

マニフェスト ファイルは、Cocos Creator ホット アップデート例のバージョン ジェネレーター スクリプトによって自動的に生成できます。

プロジェクトリソースとゲームパッケージリソースの違い

Cocos Creator プロジェクトを作成すると、その下にアセット ディレクトリが表示されます。このディレクトリには、エディターのアセット パネルに対応するシーン、スクリプト、プレハブなどが保存されます。ただし、これらのプロジェクト リソースはパッケージ化されたリソースと同じではありません。ビルド パネルを使用してネイティブ バージョンをビルドすると、ビルド ディレクトリに res フォルダーと src フォルダーが見つかります。これら 2 つのフォルダーには、実際にゲームを実行するゲーム パッケージ リソースが含まれています。 src にはすべてのスクリプトが含まれ、res にはすべてのリソースが含まれます。

したがって、リソースのホット アップデートでは、プロジェクトのアセット ディレクトリではなく、ビルドされたリソースが自然に更新されるはずです。

Creator2.4.3では、リソース管理モジュールが再構築され、バンドルモジュール化を使用してリソースを管理するようになりました。 uuidを介してリソースパスを取得するためのAPIは次のとおりです。

cc.assetmanager.utils.getUrlWithUuid // uuid を url に変換します。ここで返される url は、ランタイム ゲーム パッケージ内のリソース パスです。

searchPaths検索パス

ホットアップデートについて話す前に、searchPaths の概念を理解する必要があります。ほとんどの場合、ファイルのパスを記述するときは、「ルート ディレクトリ」に基づいて対応する「相対パス」を指定し、「絶対パス」として直接記述することはありません。これにより、メンテナンスと移行が容易になります。ゲーム開発において、「ルート ディレクトリ」の確実性と一意性を保証することは実際には困難です。ホットアップデート機能を例に挙げてみましょう。画像があります。対応するバンドルディレクトリ（デフォルトはリソース）の相対パスが「./png/icon1.png」であると仮定します。ゲームのバージョンが更新され、画像を更新する必要がある場合、パッケージ内のリソースは書き込み可能ではないため、別の場所から新しい画像を読み取ることしかできません。コードの一貫性を確保するために、対応する「ルートディレクトリ」を変更できれば、コード内の以前の相対パスを変更する必要がなく、新しい画像を見つけることができます。

Creator では、一連の検索パス戦略が維持されます。対応する API については、jsb.fileUtils.getSearchPaths、jsb.fileUtils.fullPathForFilename などを参照してください。ここでその原理を簡単に説明します。 FileUtils は「ルートディレクトリ」の配列を格納します。インデックスが小さいほど、優先順位が高くなります。リソースを検索するときに「相対パス」を指定すると、searchPaths の「ルートディレクトリ」の優先順位に従って「絶対パス」につなぎ合わせてリソースを検索します。パスが有効でファイルが見つかった場合は、検索を中止します。

ゲーム パッケージのインストール ディレクトリには、パッケージ化したさまざまなスクリプトやリソースを保存するディレクトリが必要です。ここではこれを「ゲーム パッケージ ディレクトリ」と呼びます。ホット アップデート ロジックでは、ホット アップデート コンテンツを保存する「ホット アップデート ディレクトリ」を指定する必要があります。両方のディレクトリを検索パスとして設定し、ディレクトリの優先度が高いほど、対応する検索パスの優先度が高くなるようにバージョンを制御する必要があります。このようにして、最新のファイルを見つけることができます。一般的に言えば、「ホット変更ディレクトリ」の優先度は「ゲーム パッケージ ディレクトリ」の優先度よりも高くする必要があります。

Cocosの基本的な修正プロセス

これはcocos公式サイトのフローチャートです。現在のプロセスは、ユーザーがアプリをインストールした後、初めてサーバーのバージョン更新を確認するプロセスです。完全なホットアップデートプロセスはより複雑になり、後でゆっくりと追加される予定です。

この記事は主に、ホット アップデート自体のプロセス ロジックを理解するのに役立ちます。ブレークポイントの再開、ダウンロードの進行状況、同時ダウンロード、エラー検出、解凍、エラー回復などの詳細については、今のところ説明しません。したがって、控訴フローチャートは次のように簡単にまとめることができます。

現在のパッケージのマニフェストの remoteVersionUrl フィールドに従って、現在のバージョン記述ファイルをダウンロードし、ローカルバージョンと比較します。更新が必要な場合は、対応する最新バージョンに更新します。それ以外の場合は更新は不要で、後続のプロセスを続行します。

ここでは、いくつかの重要なポイントをさらに分析する必要があります。

_localManifest: 現在のパッケージのマニフェスト

まず、「ゲーム パッケージ ディレクトリ」に、現在のゲーム バージョン (「バージョン」フィールド) を記述するデフォルトのマニフェスト ファイルが存在する必要があります。このマニフェストは通常​​、ゲーム パッケージがアンインストールまたはインストールされたときに更新されます。次に、「ホット変更ディレクトリ」には、現在のホット変更ディレクトリの下のバージョン情報を記述するマニフェスト ファイルも存在します。ゲームを起動するたびに、「ゲーム パッケージ ディレクトリ」または「ホット チェンジ ディレクトリ」が現在の環境で最新バージョンであるかどうかを判断し、searchPaths で対応する優先順位を調整する必要があります。新しいマニフェストは、現在のパッケージのマニフェストとも呼ばれ、_localManifest を使用してコードに記録されます。
上記の cocos の基本的なホット アップデート プロセスはパッケージの最初のインストールを表しているため、このような手順はありません。ホット アップデート ディレクトリにはマニフェスト ファイルがないため、_localManifest が「ゲーム パッケージ ディレクトリ」になります。完全なホット アップデート プロセスには、この判断の手順が必要です。
上記のロジックに対応するコードについては、AssetsManagerEx の init、loadLocalManifest などの関数を参照してください。

まずリモートバージョンマニフェストをリクエストする

マニフェストの「remoteVersionUrl」フィールドは、リモート サーバーのバージョン ファイルに対応します。理解を深めるために、公式デモの version.manifest を以下に示します。

{
    "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",
    "バージョン":"2.0"
}

上記のように、version.manifest には「version」フィールドがあり、これが簡単なバージョン比較の基礎にもなります。 version.manifest をダウンロードし、それをローカルの _localManifest バージョンと比較して、現在のパッケージを更新する必要があるかどうかを検出します。このプロセスは、コード内では通常 checkUpdate と呼ばれます。

一時フォルダの必要性

ホットアップデートプロセスでは、複数のリソースを順番にダウンロードするため、この期間中にさまざまな問題が発生する可能性があります。そのため、ダウンロードを一時的に保存するための一時フォルダーが必要です。すべてのファイルがダウンロードされた後、「ホットアップデートディレクトリ」内の古いリソースを置き換える前に、ファイルが完全であるかどうかを確認する必要もあります。「ホットアップデートディレクトリ」に直接ダウンロードしないでください。問題が発生すると、どの部分が新しく、どの部分が古いかがわからなくなります。この考え方はプログラム設計にも応用できます。担当するデータやフィールドをメンテナンスする際は、勝手に変更したり値を割り当てたりするのではなく、全体として置き換えたり更新したりするように心がけるべきです。

よりホットなファイルはよりホットで差別化が図られていますが、これをどのように実現するのでしょうか?

マニフェスト ファイルの「assets」フィールドに、各リソースのキーと md5 情報を記録します。リモートの _remoteManifest に記録されたリソースを比較するだけで済みます。新しいキーは新しく追加されたリソースであり、キーのないリソースは削除する必要があります。md5 が異なるファイルは更新する必要があるファイルです。
対応するコードについては、Manifest の genDiff およびその他の関数を参照してください。

暑さが和らいだら、どうやって効果を出すか

新しいリソースを追加した場合、コードを調整せずにそれらを有効にするにはどうすればよいでしょうか?ハハ、上で紹介したように、「ホット変更ディレクトリ」が「ゲーム パッケージ ディレクトリ」よりも優先されるように searchPaths を調整するだけで済みます。
上記のフローチャートでは、cocos は cc.sys.localStorage を使用して _localManifest に対応するパスを保存し、その後のアプリ起動の最初に cc.sys.localStorage から対応するパスを読み取って searchPaths に設定することを推奨しています。
上記のソリューションは確かに実現可能ですが、完全なクライアント フレームワーク、特に複数のサブプロジェクトを持つロビー タイプのゲームの場合、この動的なストレージ パスと設定パスはより適切なソリューションではないと個人的には思います。アーキテクチャ設計の観点から、まずクライアント全体の「ホット変更ディレクトリ」を決定し、優先順位を決定する必要があります。つまり、プロジェクト全体の searchPaths は、動的に調整されるのではなく、設定したロジックに従って固定されます。これの利点は、searchPaths ロジックが一意の場所で決定され、その後は、対応するパスの下のリソースのみをロジックに従って追加または削除する必要があるため、拡張とメンテナンスが容易になることです。ただし、この固定 searchPaths のソリューションでは、アプリをインストールして置き換えるときに、新しい「ゲーム パッケージ ディレクトリ」バージョンと「ホット チェンジ ディレクトリ」内の以前のバージョンの比較を維持する必要があることにも注意してください。たとえば、アプリのローカル インストールとアップグレード後のバージョンが「ホット チェンジ ディレクトリ」の以前のバージョンよりも高い場合は、以前の「ホット チェンジ ディレクトリ」の下にあるすべてのリソースをクリアすることを検討できます。もう 1 つの厄介なロジックは、アプリをインストールしてアップグレードした後のバージョンが「ホット チェンジ ディレクトリ」のバージョンよりも低いことです。「ホット チェンジ ディレクトリ」には、アップグレード前の「ゲーム パッケージ ディレクトリ」を基準とした差分ファイルが格納されていることに注意してください。アップグレード後、「ゲーム パッケージ ディレクトリ」内のファイルが変更されると、「ホット チェンジ ディレクトリ」内の差分ファイルが現在の「ゲーム パッケージ ディレクトリ」と互換性がなくなる可能性があります。この場合、「ホット チェンジ ディレクトリ」を再比較して、差分ファイルをホット チェンジすることもできます。

古いバージョンのリソースの扱い方

cocos のホットアップデートは差分ファイルですが、そのマニフェストスクリプトには対応するバンドルのすべてのリソースが記録されます。どのリソースが不要になったかを知ることができます。genDiff 関数についても上で説明しましたが、個人的には古いリソースの削除には注意が必要だと思います。少なくとも、古いリソースを削除する前に、新しいリソースが更新されていることを確認してください。

要約する

読者が上記の知識を理解し、Cocos が提供する基本機能を使用すれば、独自のホット アップデート プロセスを完全にカスタマイズできます。簡単に言えば、ホット アップデートは最新のリモート リソースをダウンロードして、現在のパッケージ内の既存のリソースを置き換えます。たとえば、小規模なプロジェクトでは、パッケージ全体をダウンロードして置き換え、バージョンの比較、searchPath の調整、ファイルの検証などの詳細を無視することができます。

上記は、CocosCreator ホットアップデートの詳細についての包括的な説明です。CocosCreator ホットアップデートの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。