今回の主な話題：UGUI Atlasバッチ処理時のInclude in オプションをどうのように理解しますか、Android端末のジャムを指定する方法、フォグ効果を実現する方法、シリアライズ化されたファイルの冗長な引用をクリーンアップする方法。
UGUI
Q1: UGUIのバッチ処理についていくつかの疑問があります。
1）UGUIのバッチ処理はいつ行われましたか？バッチ処理はEditorで合併された大きな画像なら、AssetBundleをパッケージする時にアトラスファイルと関連する小さな画像のみがパッケージされて、合併した大きな画像は見ていませんでした。では、これはUnityがLate in bindingを行う時に合併しましたが？
2）Include in Buildにいったい何が含まれていますか？私の理解では、チェックすると生成した大きな画像が含まれ、チェックしないと含まれません。では、まだ質問１に戻ります。チェックしない場合、大きな画像は実行中に生成しましたか？
3）小さな画像のサイズはパフォーマンスに影響しますか？まず、小さな画像のソースはパッケージ本体のサイズに確実に影響します。
質問1と質問2に基づいて、大きな画像は実行時に生成されなら、大きな画像を生成する時に、I / Oはバイトストリームの形式で空白の大きな画像に入力、合併しますか？そうであれば、実行中大きな画像を生成するボトルネックはソースファイルのサイズと形式はずでしょう？（アトラスとソースの圧縮形式は違うと仮定します。）
回答は以下になります。
1、Unityのバッチ処理のタイミングは設定次第です。
上図のように、パッケージ化時でもエディターの実行時でも合併することができます。Editorで合併された大きな画像はキャッシュディレクトリLibraryAtlasCacheに配置されます。2、About “Include in Build” behaviourを参照できます。
私の理解では、Include in Buildをチェックすると、アトラスリソースがAppにパッケージされます（AssetBundleパッケージではない）。アトラスはAssetBundleパッケージに管理させている場合、チェックしないほうがより良いです。そうしないとリソースは２倍になります。どちらのリソースは２倍になれるのは、テストする必要があります。
3、Unityは最終的に合併した大きな画像のみを使用し、小さな画像自体はリリースされたAppまたはAssetBundleパッケージに入らないため、小さな画像のソースファイルのサイズはパフォーマンスに直接影響しません。ただし、通常、小さな画像のサイズとSpriteの設定は、合併されたアトラスに影響を与えるため、最終的なパフォーマンスに間接的な影響を及ぼします。
Sprites Atlasが違うSprite Packer Modeオプションでパッケージすることについて、実験をしました。結果は次通ります。
1.最初の3つのオプション（Disabledと２つのLegacy Sprite Packer）の結果は同じ場合
パッケージしたAssetBundleに何もありません。この状況で、散図までもありませんはずです、完全にリソースをロードできません。さらに、UnityのBugの疑いが見つかりました。新しく作成されたAtlasとすでにパッケージ化されているAtlasでは、禁止オプションでパッケージ化の結果が異なります。
2.後の２つのオプションの結果は同じ場合
AssetBundleパッケージを生成すると、アトラスがすでに作成されました。
制作
Q2: マテリアルのShader、またはGameObjectコンポーネントのMonobehaviorは、開発中に一つのShaderのPropertyまたはコードのシリアライズ化パラメータを削除する場合があります。これらのパラメータが削除された後、マテリアルまたはGameObject Prefabファイルにある、このパラメータのシリアライズ化データは削除されていません。
たとえば、下図にあるTestGetDependencyという名前のコンポーネント。パラメータtestSubjectがコードからもう削除されていました。
ただし、このGameObjectのPrefabに、testSubjectのレコードがまだ存在します。
これにより、AssetDataBase.GetDependenciesみたいな方法を使用してアセット依存を取得する時、testSubjectによって引用されるオブジェクトを取得するため、パッケージ化時に不要なリソースが含まれることになります。スクリプトを使用してSerializedObjectをスキャンする方法でこれらの引用をクリアできますが、これには違う状況ごとに個別のスクリプトが必要です（現在はShaderのみがマテリアルに対応し、コードファイルはPrefabに対応します）、遺漏または不適切な処理が行われる可能性があります。
ですから、Unityネイティブのクリーニング方法はあるかどうかを知りたいです。または、業界でスクリプトによってこのようなシリアライズ 化引用問題を処理する一般的な方法を知りたいです。
もう一度保存したら大丈夫です。
さらに厄介なのはShaderです。serializedObjectを自分で分析してからクリーンアップする必要があります。
レンダリング
Q3: 下図のように、パフォーマンスレポートで、Camera.Render下CreateVBOのオーバーヘッドが高いことがわかりました。これはどのように発生しますか？
これは基本的に、メッシュの再構築が引き起こします。非UGUIのUI再構築、テキストメッシュ再構築などで良く見られます。再構築する時のCPU時間コストは、主にメッチュ再構築の量に影響されます。ただ1フレームの場合、問題ありませんが、頻繁にオーバーヘッドが発生する場合は、特別な注意を払う必要があります。
制作
Q4: 図のように、インターフェイスフォグ効果を実現したいです。UIで実現するほうがいいでしょうか？それともそのようなシーンを作って実現するほうがいいでしょうか？現在の星図は3DのPrefabでアリ、黒いベースマップで覆い、影響範囲に応じてベースマップの明るい領域を変更する予定です。何か関するプラグインありますか？どこから始めればいいのでしょうか？
RenderTextureを作成できます。ピクセルとマップを1対1で対応させ、RenderTextureカラーの変更に介して、Shaderに対する計算を行って、効果を得ます。Unity 5.4以降、配列をShaderに渡すことでこの効果を実現できます。
メモリ管理
Q5: 異なるAndroidとApple設備で（1G、2G、3G、4G…）、クラッシュが発生しないように、ゲームのメモリピーク値をどのぐらい高く設置したら良いですか？
ここである人がiOSのメモリピークを更新し続けます。投稿の下で誰かがメモリピークをテストするためのツールも投稿しました。非常に使いやすく、参照できます。
https://stackoverflow.com/questions/5887248/ios-app-maximum-memory-budget.
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
UWA公式サイト：https://jp.uwa4d.com
UWA公式ブログ：https://blog.jp.uwa4d.com