Instruments でMonoメモリ割り当てを確認する方法

今回の主な話題：

1）InstrumentsでMonoメモリ割り当てを確認する方法

2）Addressable v1.11.2に関する疑問

3）UV2の展開によって引き起こしたMeshの頂点数の増加

4）Unityエディターでのコードのコンパイル速度の向上

5）Renderdocのデバッグに関する疑問

Memory

Q：たとえば、10MBのアレイが割り当てられると、少なくとも10MBのMonoメモリがUnity Profilerで開かれます。

では、Instrumentsで、割り当てられたメモリ情報をどのように確認しますか？Allocationsの情報は、このプロセスで割り当てられたすべてのメモリ情報ですか？100MBのメモリを割り当てようとしましたが、Allocationsの統計は増加しませんでした。

A：こちらでもテストしました：

100MBのintアレイを作成しました。実際のSizeは400MBであるはずです。

次に、Profileに移動して次のことを確認します。

ManagedHeapが400MBのスペースを正しく割り当てていることがわかります。

それに、iOSをパッケージ化し、Xcodeで実行します。実行する前に、まず、RunというSchemeのMallocStackを選択します。

RUNした後、「Memory」をクリックし、メモリグラフMemory Graphをエクスポートして次のことを確認します。

アプリのメモリはVirtualMemoryスペースに割り当てられているため、VM RegionsのVM_ALLOCATE部分を確認してください。

128X3 +16というちょうど400MBの割り当てはであることがわかります。

コールスタックも非常に簡単に判別できます。

これがテストコードです。

次に、Instrumentsについて見ていきます。まずはAllocationsの部分です。下にはいくつかのオプションがあることに注意してくだいさい。

最後のオプションに注意してください。一番目のオプションを選択する場合は、

All Heap＆Anonymous VM、All HeapはAppの実際に割り当てられた物理スペースに対応します。VMが含まれません。それに対し、Anonymous VMの公式な説明は次のとおりです：

interesting VM regions such as graphics- and Core Data-related. Hides mapped files, dylibs, and some large reserved VM regions。

したがって、比較的大きな予約済み割り当てスペースは表示されません。

このオプションを「All VM Regions」に切り替えると、割り当てられた400Mが表示されます。

また、右側の詳細ページには、コールスタックも正しく表示されます。

さらに、VM Trackerからも観察できます。 VMTrackerのSnapshotsを開きます。

このように、400MBの詳細な割り当て情報を確認できます。

プログラムの他の部分もメモリを適用する必要があるため、Virutal Sizeは400MBよりわずかに大きいことがわかります。400MBはそれぞれResidentとSwappedに格納されます。Resident部分は基本的にDirty Sizeと同じであり、スペースのこの部分がDirtyとしてマークされ、スワップアウトできないことを示します。残りの約240MBは、使用するのに十分な物理スペースがあることを保証するために、一時的にスワップアウトできます。これは、スペースのこの部分を申し込み、特定の賦値の初期化と使用を実行しなかったためでもあります。

賦値が使用された場合はどうなりますか？コードテストを修正して、

Instrumentsを実行した後に観察します。

この400MBはすべてDirty Size内にあることがはっきりとわかります。この状況は本当に、このAppとiOSにメモリストレスをかけます。

推奨読書：

《写给Unity开发者的iOS内存调试指南》（中国語注意）

《Understanding iOS Memory (WiP)》

Addressable

Q：Addressable v1.11.2起動エディターが「Fast Mode」で実行している時に、「SubAssetの取得に失敗しました」という問題について。

A：今日は、Addressablesシステムを使用してプロジェクトを1.8.4から1.14.2にアップグレードしました。AssetReferenceが指すアセットがインスタンス化する時、常に現れた「無効なKey」エラーに気づきました。調査の結果、1.11.2から、FastModeをさらに加速するために、公式によってプロセスの修正が行われたと発見しました。

以前のバージョンでは、たとえ「Fast Mode」であってもBuildが必要であり、Buildによって生成されたCatalogがPlay時に読み取られました。Catalogは、すべてのAssetEntryとSubAssetをシリアル化し、ResourceLocationMapオブジェクトを生成してから検索します。SubAssetを指すため、多くのAssetReferenceが使用されています。現時点では問題ありません。

バージョン1.11.2以降、Fast Modeは、Catalogファイルパスではなく、エディター環境でAddressableAssetSettingsオブジェクトのGUIDを直接提供します。したがって、FastMode専用の初期化操作は、Play後の初期化中に有効になります。この時に、ResourceLocationMapではなく、AddressableAssetSettingsLocatorが生成されました。このLocatorは、エディターGroupウィンドウが対応する表示可能なGroup内のAssetEntryをトラバースしただけで、AssetEntry内のSubAssetはトラバースされないため、ゲームでSubAssetを使用すると、無効なKeyエラーが報告されます。

公式Changelog：

Refactored Play Mode Script for “Use Asset Database” to pull data directly from the settings. This reduces the time needed to enter play mode.

提案：

一時的にv1.8.4バージョンのみを使用します（プロジェクトに長く使用され、比較的安定しています）

1.9.2から1.11.2までのバージョンの使用はお勧めしません。他のbugもあります。

最新の状況にアップグレードし、Simulate Groupsを使用して開発します

公式からの改善を待ちます

Rendering

Q：UnityでUV2（Generate Lightmap UVs）を自動展開すると、個別のオブジェクトのMesh内の頂点の数が増加します。

自動的に展開した地面の場合、頂点の数が134から136に変更されました。UV2を展開しないなら問題ありません。頂点の数を増やさずにUV2を展開する方法はありますか？

FBXモデルをインポートする場合、「Meshを最適化する」およびその他の頂点に影響を与えるオプションが選択されていません。

A：2つのメッシュがLightmapの2つの不連続領域に対応する場合があり、2つのメッシュに頂点が共有される可能性があるため、2つの頂点に分割する必要があります。他のデータは同じですが、UV2が異なります。これは正常です。

頂点を増加させたくないなら、アーティストが手動でUV2を設定してエクスポートする限り実現可能です。それでも、モデルが一部のメッシュは囲まれて閉じている場合、頂点が重ならないことを保証するのは難しいです。実際、現時点では、頂点はすでにMayaなどのツールに追加してエクスポートされました。Unityに変化が見えないかもしれません。

Build

Q：Unityエディターでコードのコンパイル速度を向上させる方法はありますか？現在コードを変更するたびに、コンパイルの待機時間は30分近くになります。

A1：大規模なプロジェクトにとって、これは確かに頻繁に遭遇する状況です。一般的に、UnityEditorはスクリプトの依存関係に従ってコードをコンパイルします。これは主に次の4つのステップに分けられます。

Standard Assets、Pro Standard AssetsとPluginsフォルダーにあるRuntime Scriptをコンパイルします。

上記の3つのフォルダーにおけるEditorフォルダーの下にあるScriptをコンパイルします。

プロジェクト内の残りのすべてのRuntime Script（Editorフォルダー以外のScript）をコンパイルします。

残りのScript（つまり、Editorフォルダー内のScript）をコンパイルします。

Unityエディターのスクリプトコンパイル機能を理解した後、開発チームは、長期間変更する必要のないいくつかのスクリプトコード（例えば、さまざまなプラグインコードなど）をStandard Assets、Pro Standard Assets またはPluginsフォルダーに入れることをお勧めします。これなら、これらのコードは一度だけコンパイルする必要があり、その後の時間を節約できます。

あるテストでは、プロジェクトで上記の変更を行った後、元のプロジェクトのコンパイル時間が23秒から7秒に短縮されました。これはかなりチームのコンパイル時間を節約します。