小規模ゲーム向けの iOS メモリとパフォーマンスの最適化ガイドがついに登場しました! おすすめコレクション

序文

WeChat ミニゲームの通常モードは、ネイティブプラットフォーム上で HTMLCanvas のレンダリング機能をシミュレートするための C++ レンダリングレイヤーと JS コンパイルエンジンに基づくソリューションであるため、JS コードのコンパイルと実行の効率はゲームのパフォーマンスに大きく影響します。。

通常、JS エンジンはコンパイル速度を向上させるための JIT 機能を提供します。これにより、小規模なゲームが Android 側で優れたパフォーマンスを達成できるようになります。しかし、iOS 側のシステムセキュリティポリシーにより、JS エンジンによる JIT 機能の使用が制限されているため、iOS 側の小規模なゲームのパフォーマンスは常に満足のいくものではありませんでした。

WeChat ミニゲームによって提供されるハイパフォーマンスモードにより、iOS 上のミニゲームも WeChat の内部 Webkit に切り替えてゲームを実行することで JIT 機能を使用できるようになり、実行パフォーマンスが大幅に向上します。

WeChat Mini Games の公式ドキュメントにある水族館のテストから、同じシーンで、iPhone11 Pro Max では、ハイパフォーマンスモードでは 49 FPS に達しましたが、通常モードでは 13 FPS にすぎないことがわかります。

この記事では以下の4つの観点から解説していきます。

ハイパフォーマンスモード
ランタイムメモリ構造
メモリの問題の診断
メモリ最適化のヒント

メモリの問題は Android 側で適切に実行され、iOS 側でより多くのフィードバックが得られるため、この記事では iOS 側でのメモリの最適化のみを紹介します。

ハイパフォーマンスモード

ハイパフォーマンスモードの導入と使用方法については、WeChat ミニゲーム開発ドキュメント: ハイパフォーマンスモードを詳しくお読みください (記事の最後にある QR コードを長押しできます)。

イタリアーノ

WeChatパブリックプラットフォームにログイン -> ホームページ機能マップモジュール -> クリックして「生産改善パッケージ」に入る -> クリックして高パフォーマンスモードをアクティブ化します。
アクティベーションが成功したら、game.json の iOSHighPerformance を true に構成することで、高パフォーマンスモードに入ることができます。
Cocos Creator 3.7 以降では、[プロジェクト] -> [ビルドリリース]パネルでハイパフォーマンスモードを直接確認できます。

このスイッチを外すと、通常はノーマルモードに戻り、２つのモードを比較することができます。

問題に注意してください

ハイパフォーマンスモードでは、ゲームのレンダリングパフォーマンスとパフォーマンスが向上しますが、ゲームのメモリ要件はより厳しくなります。
ハイパフォーマンスモードでは、ミニゲームがブラウザカーネル環境で実行されるため、互換性、メモリ消費量、安定性などの側面を個別にテストする必要があり、通常モードでのテスト結果は再利用できません。
iOS デバイスでは、iPhone 6s/7/8 などの 2G RAM モデルのメモリ制限は 1G、iPhone 7P/8P/iPhoneX/XR/XSAMX/11 などの 3G RAM モデルのメモリ制限は 1.4G です。アプリケーションメモリ使用量がこのしきい値を超えると、プロセスはシステムによって強制終了されます。したがって、開発者は、ピーク時のメモリがこの値を超えないようにする必要があります。
ゲームがメモリに対して最適化されていない場合、ハイパフォーマンスモードをオンにすることはお勧めできません。そうしないと、ローエンド iOS マシンで異常終了しやすくなります。メモリに問題がある場合は、メモリの最適化を参照してください。メモリを完全に最適化するためのヒントは、この記事に記載されています。

ランタイムメモリ

上の図からわかるように、ランタイムメモリは 6 つの部分で構成されています。

JavaScript ヒープ

ハイパフォーマンスモードでは、ミニゲームはブラウザーカーネル環境で実行されるため、JavaScript ヒープにはゲームロジックコードメモリが含まれます。通常、Web モバイル側をパッケージ化し、Mac プラットフォーム上の Safari ブラウザのデバッグツールを使用して、モバイル Safari のメモリ状態をリモートでデバッグできます。通常、JavaScript ヒープでは特定の物理メモリ使用量を確認できないことに注意してください。

WASM リソース

物理エンジン計算などの JS モジュールの実行パフォーマンスを向上させるために、いくつかの C++ コードを WASM コードスニペットに直接コンパイルして、最適化されたパフォーマンス要件を達成します。たとえば、Cocos Creator が参照するサードパーティの物理ライブラリは WASM バージョンです。

基本ライブラリとキャンバス

基本ライブラリは、WeChat ミニゲームのブラックボックス環境によって公開される API パッケージとして理解でき、ブラウザカーネル環境 API が開発者に公開されるのを防ぐことができます。実際のテストでは、基本ライブラリのメモリは約 70M を占有しました。ミニゲーム環境で作成された最初の Canvas がメイン Canvas であり、レンダリングサーフェスをメインインターフェイスに同期できる、つまりゲームのレンダリングパフォーマンスを提示できる唯一の Canvas でもあります。Canvas のメモリフットプリントは、Canvas の幅と高さに比例します。

音声ファイル

オーディオファイルメモリとは、メモリにロードされたオーディオインスタンスを指します。

GPUリソース

頂点データキャッシュ、インデックスデータキャッシュ、テクスチャキャッシュ、レンダリングサーフェスキャッシュなど。

メモリの問題の診断

ここでは、メモリの問題を迅速に特定し、解決策を見つけるのに役立つ、一般的に使用される iOS メモリ診断ツールをいくつか紹介します。

一般的に使用される iOS デバイスのメモリ表示ツール

Xcodeに付属する機器分析ツール
Perfdog ツール
WeChat開発者ツール

注: iOS ミニゲームのプロセス名はモードによって異なります。

高パフォーマンスモード: WebContent あり

通常モード: WeChat を含む

XCode インストゥルメント

XCode Instruments は、XCode 独自のアプリケーションランタイム分析ツールであり、WeChat ミニゲームプロセスにも適用できます。

アクティビティモニターを使用し、キャプチャするすべてのプロセスに対応するデバイスを選択し、プロセスリストが更新されるのを待ち、フィルタリングする Webkit を入力すると、すべてのプロセスの CPU とメモリのステータスを確認できます。

パーフドッグ

Perfdog (Perfdog) は、iOS/Android/PC/ホストプラットフォーム向けのパフォーマンステストおよび分析ツールです。具体的な使用方法については、https: //perfdog.qq.com/を参照してください。

対応する設定プロセス名を選択すると、関連するパフォーマンスデータが表示されます。

[開発段階でのメモリ調整: 開始時にすべてを制御 | WeChat オープンドキュメント]: https://developers.weixin.qq.com/minigame/dev/guide/performance/perf-action-memory-devを参照してください。 - プロフィール.html

WeChat開発者ツール

WeChat 開発者ツールは主にデバッガを使用してメモリデータを追跡します。操作プロセスは次のとおりです。

デバッグ開発者ツールインターフェイスに入る
[メモリ]にチェックを入れてゲームをリフレッシュしてください
下の画像の左上隅にある小さな丸ボタンをクリックして録画を開始します
録音が終了すると、次のインターフェースが表示されます

ここでは主に 2 つの波形に焦点を当てます。1 つは論理フレームの呼び出しスタックを表示するために使用されるメイン波形で、もう 1 つはメモリ増加の変化を観察するために使用される JS ヒープのピーク曲線です。特定の瞬間に JS ヒープ値が増加していることが観察された場合は、論理フレームの呼び出しスタックを表示して、データのソースを大まかに確認できます。

上記の手順により、ゲームの JS メモリ分布を分析できます。その後、特定の JS メモリのソースとリリースを特定するには、次のメモリリーク検出ツール - リアルタイムメモリ診断を使用する必要があります。。

具体的な手順は次のとおりです。

左上隅の小さな丸ボタンをクリックして、下の記録ボタンに入ります. ヒストグラムの出現は特定のメモリブロックの作成を示し、ヒストグラムの消失はメモリブロックが解放されたことを示します。左上のゴミ箱ボタンは、JS エンジンの GC をアクティブに起動するボタンで、クリックするとメモリのリサイクルを高速化できます。
左上隅の小さな赤い丸ボタンをもう一度クリックして記録を終了します。このとき、青い領域を選択すると、メモリブロックに含まれるオブジェクトが表示されます。これらは、まだリリースされていないリソースです。オブジェクトを選択した後、Retainers インターフェイスでオブジェクトのメモリ参照関係を確認できます。この時点で、コード層の論理関係に基づいてメモリオブジェクトを解放する必要があるかどうかを判断し、メモリリークが存在するかどうかを確認できます。

メモリ最適化のヒント

一般的な WeChat ミニゲームプロジェクトのメモリは、次の部分で構成されます。

ミニゲーム基本ライブラリ
エンジンスクリプトメモリ
ビジネススクリプトメモリ
オーディオメモリ
フォントメモリ
画像メモリ
キャンバスメモリ

メモリのコンポーネントがわかれば、さまざまな部分に対して最適化を行うことができます。

iOS の高パフォーマンスモードを例に挙げると、一般的に使用されるメモリ最適化手法は次のとおりです。

小規模ゲームの基本ライブラリのメモリは通常 ~= 70M ですが、これは常駐メモリであり、最適化できません。
エンジンのメモリ使用量はロード時に決定されます。エンジンのロードによりレンダラーが初期化されるため、通常、メインの Canvas メモリ使用量もこの時点で決定されます。このメモリ使用量は、レンダリング解像度の倍数を構成することで最適化できます。実行時、エンジンモジュールのニーズに応じて一部のキャッシュメモリが動的に追加され、開発者は機能のニーズに応じてエディタのプロジェクト設定で機能を調整することで、エンジンメモリの使用量を削減できます。
スクリプトメモリにはエンジンとビジネスコード、および構成テーブルデータが含まれます。ゲームの開発量に応じて、ビジネスコードと構成テーブルデータのメモリのサイズは数百 M になり、ユーザーのみが最適化できます。
単一のデュアルチャネルオーディオインスタンスは約 20M になる場合があります。オーディオの再生後にインスタンスを解放すると、このメモリ損失が軽減されます。また、シングルチャネルオーディオに合理化してメモリを削減することもできます。
中国では一般に中国語フォントが使用され、ロード後のメモリ使用量は少なくとも 10M を超えるため、システムフォントを使用し、アプリケーション内の共有リソースを使用するようにしてください。開発条件が許せば、ビットマップフォントやSDFフォントレンダリングも使用可能です。
画像メモリは一般的に使用されるリソースであり、ロードのニーズに応じて、テクスチャを塗りつぶしてから解放するか、メモリにキャッシュして次回テクスチャを再充填するかを選択できます。iOS 側では、astc 圧縮テクスチャ形式を使用し、画像リソースメモリを解放できる動的バッチ処理を無効にすることをお勧めします。圧縮されたテクスチャ自体も、png よりも使用するメモリが 50% 以上少なくなりますが、astc のファイルサイズは png よりも大きくなるため、パッケージサイズは大きくなります。通常、最初のパッケージのサイズを減らすために、画像リソースをミニゲームの下請けまたはリモートの下請けに投入しようとします。
Canvas オブジェクトは、TTF フォントテキストのレンダリング時に作成されます。Canvas オブジェクトは、使用後にキャッシュプールにリサイクルされます。テキストレンダリングのフォントサイズが大きいほど、キャッシュプールも大きくなります。現在、エンジンはリサイクルメカニズムを提供していません必要に応じて、エンジンを変更して Canvas キャッシュプールを解放できます。ゲームのメモリ使用量が比較的高い場合は、TTF フォントの代わりにビットマップフォントを使用できます。
JSON ファイルなど、エンジンによって提供される機能に従ってオンデマンドでリリースされる他の JS メモリオブジェクトもあります。

この記事は、Cocos エンジンの公式テクニカルサポートチームによって提供され、エンジンの公式オープンソースウェアハウスである WeChat ミニゲームメモリ最適化ガイド (IOS) に同期されています。Star and Fork へようこそ。

参考記事

過去のハイライト