前回の記事「Unityローディングモジュール詳細分析——Texture編」で、テクスチャアセットのローディングパフォーマンスについて話しました。今回は他の主流アセットのローディング効率について説明します。
アセットローディングパフォーマンステスト用コード
前の記事で提出したテストコードと同様に、他のアセットのローディングパフォーマンス分析にもこのテストコードを採用します。各アセットを特定サイズのAssetBundleファイルに作成し、下記のコードを介して異なるデバイスに1つずつローディングを行います。異なるデバイスのアセットローディングパフォーマンス を取得して比較します。
テスト環境
エンジンバージョン：Unity5.2バージョン
テストデバイス：グレードの異なる3つのモバイルデバイス（Android：Redmi 2、Redmi Note2、Samsung S6）
メッシュアセット
テクスチャアセットと同じように、メッシュアセットがロードするとCPU使用率が高くなり、ローディング効率はそれ自体のサイズ（メッシュデータ量）によって決まります。そのため、データ量の異なるメッシュアセットを選択してローディング効率を詳しく分析します。
テスト1：面数の異なるメッシュアセットのローディング効率テスト
面数が異なる4つのメッシュアセットを選択しました。含まれる面数は1K、5K、10K、および50Kであり、Tangent頂点属性は含まれていません。4つグループのメモリ使用量はそれぞれ195KB、0.8MB、1.4MB、および3.9MBであり、対応するAssetBundleサイズは43KB、108KB、178KB、および507KBです。
テスト用メッシュ：
これらのメッシュアセットを3つの異なるグレードのモデルにロードします。偶然性を減らすために、各デバイスでロード操作を10回繰り返し、平均値を最終的なパフォーマンスオーバーヘッドとして採用します。具体的なテスト結果を次の表に示します。
上記のテストを通じて、下記の結論を取得することができます。
1、アセットのデータ量はローディングパフォーマンスに大きな影響を与えます。面数が多いほど、ローディングに時間がかかります。デバイスのパフォーマンスが悪いほど、時間コストの違いが明らかになります。
2、ハードウェアデバイス性能の向上により、ローディング効率の違いはますます目立たなくなります。
テスト2：面数が同じ場合、違う頂点属性のローディング効率テスト
このテストのサンプルデータとしてテスト1のメッシュアセットを選択し、パッケージ化時に頂点属性を追加します。4つグループメッシュアセットのメモリ使用量はそれぞれ287KB、1.2MB、2.1MB、および5.8MBであり、対応するAssetBundleサイズは72KB、228KB、376KB、および937KBです。テスト1と同じように、3つの異なるグレードのモデルでロード操作を10回繰り返し、平均値を最終的なパフォーマンスのオーバーヘッドとして採用しました。 具体的なテスト結果を次の図に示します。
上記のテストを通じて、次の結論を取得することができます。
1、頂点属性の増加は、メモリとAssetBundleパッケージのサイズに大きな影響を与えます。テスト1でTangent頂点属性を添付しなかったメッシュデータと比べて、テスト2のメッシュデータはメモリ上大幅に増加し（増加の量はメッシュ頂点数に関連しています）、AssetBundleサイズも倍（1〜2）になって増加します。
2、頂点属性の増加は、ローディング効率に大きな影響を与え、頂点数が多いほど、影響は大きくなります。
**注意：**よく見られるモデルの頂点属性は、主にPosition、UV、Normal、TangentやColorであります。Color属性はTangent属性と同じようです、メッシュ頂点がこの属性があれば、メモリ、物理体積やローディングパフォーマンスにも影響します。
Draw Call Batchingを使用する時、異なる属性のメッシュモデルを一緒に合併しないでください。たとえば、100個のメッシュモデルがStatic Batchingを行い、99個のモデルにPositionとUVの2つの属性しかなく、残りの1つのモデル関数にPosition、UV、Normal、Tangent、Colorの5つの属性がある場合、エンジンが合併する時に、まずは前の99個のモデルの頂点属性を補充し、次に合併を行います。これにより、実質的に大量のメモリ使用量が増加し、不要なメモリの浪費が発生します。
テスト3：Read/Write機能をON/OFFにする場合のローディング効率テスト
テスト1のメッシュアセットデータを使用し、Read/Write機能をオフして、Read/Write機能がローディング効率に与える影響を確認します。オフにした後、４つグループメッシュアセットのメモリ使用量はそれぞれ104KB、454KB、0.8MB、および2.3MBであり、対応するAssetBundleサイズは38KB、94KB、152KB、および428KBです。テスト1と同じように、3つの異なるグレードのモデルでロード操作を10回繰り返し、平均値を最終的なパフォーマンスコストとして採用しました。
具体的な結果は下記のように、
このテストを介して、こんな結論ができました。
1、Read/Write機能をオフにすれば、AssetBundleの物理サイズを減らします。減少量はアセット自体のデータ量に関連しています。 同時に、Read/Write機能をオフにするとメッシュアセットのメモリ使用量を大幅に減らします。
2、Read/Write機能をオフにすることは、このアセットのローディング効率を少し向上できます。
上記のテストと分析を通じて、メッシュアセットに関してUWAからのアドバイスは下記のようです。
1、視覚効果を確保することを前提として、「十分なら良い」という原則を可能な限り採用します。つまり、メッシュアセットの頂点数と面数を減らします。
2、開発チームが頂点属性の使用に注意してください。上記の分析から、頂点属性が多いほど、メモリ使用量が多くなり、ロード時間が長くなることがわかります。
3、プロジェクト実行中にメッシュアセットデータにRead/Write操作が行われない場合（Morphing動画など）、Read/Write機能をオフにすることをお勧めします。これで、ローディング効率も向上できし、メモリ使用量を大幅に減らせます。
上記のローディング効率問題のために、UWAが一つ一つのメッシュアセットパラメーターを詳しく分析しました。パフォーマンステストとアセット検出の2つのツールを使用して、プロジェクトのOnline実行フェーズとOffline制作フェーズを二重検出します。これにより、アセットの使用状況をすばやく表示し、パフォーマンス問題を引き起こす具体的なアセットを特定します。
メッシュ頂点データの検出には、次の2つの方法で確認できます。
1、パフォーマンステストレポートで確認できます。
2、アセット検出レポートで確認できます。
メッシュ頂点属性の検出には、パフォーマンステストレポートで確認できます。
メッシュ頂点Read/Write機能の検出には、アセット検出レポートで確認できます。
説明：上記のテストデータは、UWAが使用したテスト用メッシュローディングデータであります。説明すべきなのは、数値の違いにより、AssetBundle圧縮のサイズが異なるため、異なるメッシュアセットのローディング効率はわずかに異なることに注意してください。同時に、注意すべきなのは、異なるローディング方式（1つスレッドがアセットごとにロードする/複数のスレッドが同時にロードする）の効率も完全に異なります。この点については、将来の記事で説明します。最後に、より普遍的なテスト結果を皆さんに提供するために、今後もさらにテストを行います。
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
今なら、UWA GOTローカルツールが15日間に無償試用できます！！
よければ、ぜひ！
UWA公式サイト：https://jp.uwa4d.com
UWA GOT OnlineレポートDemo：https://jp.uwa4d.com/u/got/demo.html
UWA公式ブログ：https://blog.jp.uwa4d.com