ビルドされたアプリのファイルサイズを最小限にすることは、特にモバイルや容量制限のあるアプリストアなどで重要です。サイズを小さくするためにまずは、最も関与しているアセットを特定することであり、これらのアセットは最適化の候補として最も有力です。この情報はビルド直後エディターログで見つけることができます。コンソールウィンドウに移動し( Window < Console)、右上の小さいドロップダウンパネルメニューから Open Editor Log を選択してください。
タイプによってアセット項目ごとに分類されたログが提供され、サイズに貢献するための個々のアセットの全リストを表示します。一般的にスクリプト、レベルやシェーダーはしばしば無視できますが、テクスチャ・音楽・ビデオ等が、最もストレージを占有します。File Headers について少し触れておくと項目としてはアセットではありません。ヘッダーは、実際は特別なデータで“生”アセットファイルを保存するための参照と設定です。ヘッダーは、通常アセットのサイズにほとんど違いを与えませんが、Resources フォルダー内に多数の大規模アセットがある場合は、値が大きくなる可能性があります。
ログは自身のアセット内で削除や最適化したいときに役立ちますが、利用する前によく考える必要があります。
Unity は、インポートしたアセットを独自の内部フォーマットに変換するため、ソースアセットの種類はさほど関係ありません。例えば、プロジェクトでマルチレイヤーの Photoshop のテクスチャがある場合、ビルドされる前に平坦化され、圧縮されます。テクスチャをPNG ファイルとしてエクスポートしてもビルドサイズに違いはありません。ですから、開発時に最も便利なフォーマットにするべきです。
Unity は、ビルド中に使用していないアセットを省くので、プロジェクトからアセットを手動で削除する必要はありません。削除されない唯一のアセットは、スクリプト (一般的にかなり小さい) と Resources フォルダー内のアセットです (Unity 側でどれが必要か判断することができないからです)。これを踏まえて、Resources フォルダー内のアセットは本当にゲームに必要とするものだけを含めているか確認する必要があります。Resources フォルダのアセットをアセットbanndoru で置き換えることも可能ですーつまり、Unity はアセットを動的に読み込み、そうすることによって、プレイヤーサイズを削減します。
通常、テクスチャはビルドサイズのうち、ほぼ大部分を消費します。まず最初に、圧縮テクスチャ形式を使用できるかどうかを確認してください。詳細は、 platform-specific Texture compression を参照してください。
圧縮形式を使用してもサイズが減らない場合は、テクスチャの大きさ (ピクセル) を減らしてみてください。実際のソースのコンテンツを編集することなくこれを行うには、プロジェクトビューでテクスチャを選択し、インスペクターウインドウで Max Size を小さくします。これがゲーム内でどのように表示されるかを確認するには、シーンビュー でテクスチャを使用するオブジェクトを拡大し、それから、シーンビューで見た目が悪くなり始めるまで、Max Size を調整します。テクスチャの最大サイズを変更してもテクスチャアセットには影響せず、ゲームの解像度に影響するだけです。
デフォルトでは、Unity はインポート時にすべてのテクスチャを圧縮します。ワークフローをより高速にするため、 Unity < Preferences の順に選択し、 Compress Assets on Import のチェックボックスをオフにします。この設定にかかわらず、すべてのテクスチャはビルド内で圧縮されます。
ゲームファイルでの使用スペースを減らすよう、 メッシュ およびインポートされたアニメーションクリップを圧縮できます。メッシュの圧縮を行うには、圧縮したいメッシュを選び、それから、インスペクターウインドウで Mesh Compression を Low、Medium、High のいずれかにします。メッシュとアニメーションの圧縮は、少ないスペースしか取りませんが圧縮は不精密なデータになることに注意してください。あなたのモデルで許容できる圧縮レベルを試してみてください。
メッシュ圧縮は小さいデータファイルを生成するだけで、ランタイムで使用するメモリは少なくならないことに注意してください。アニメーションの Keyframe Reduction を使うと、データファイルを縮小し、ランタイムで使用するメモリも減ります。一般に、常に Keyframe Reduction を有効にしておくとよいでしょう。詳しくは アニメーションクリップ を参照してください。
デフォルトでは、Unity はビルドされたプレイヤーでのみ次の DLL を含みます。
mscorlib.dll
Boo.Lang.dll
UnityScript.Lang.dll
UnityEngine.dll
プレイヤーをビルドするとき、System.dll や System.Xml.dll に依存するものを避ける必要があります。Unityでは、デフォルトでビルドされるプレイヤーにこれらの DLL が含まれませんが、DLL 内のクラスを使用する場合は、含まれることになります。この DLL はプレイヤーのストレージを 1 MB 程度圧迫します。ゲームで XML をパースする必要がある場合は、代替手段として Mono.Xml.zip のようなサイズの小さいものをシステムライブラリを使用してください。たいていのジェネリックコンテナは mscorlib に含まれていますが、スタックとその他いくつかが、System.dll に含まれているだけです。そのため、可能な場合は、System.dll を避けるべきです。
Unity は一部のモバイルデバイス向け.NET API の互換性レベルとして、2つをサポートしています (NET 2.0 と Net 2.0 サブセット)。 Player Settings でビルドに最適なレベルを選択することができます。
.NET 2.0 API プロファイルは、フルの .NET 2.0 API に近いものです。ほとんどのライブラリルーチンは完全に実装されています。したがって、このオプションは既存の .NET コードと最高の互換性を提供しています。しかし、多くのゲームではフルライブラリを必要とすることはありません。さらに、不必要なコードは貴重なメモリ領域を食いつぶしてしまいます。
メモリの無駄を避けるため、Unity は .NET 2.0 Subset API プロファイルもサポートしています。これは Mono の “monotouch” プロファイルに近いもので “monotouch” の制約がすべて Unity の .NET 2.0 サブセットに適用されます。“monotouch” プロファイルの制約に関する詳細は MonoTouch limitations を参照してください。一般的に必要とされない多くのライブラリルーチンはメモリを節約するために、このプロファイルから外されます。しかしながら、それらのルーチンに関して、依存関係周りでコードが正しく動作しない可能性もあります。このオプションは最適化するために役に立ちますが、適用した後で既存のコードが正しく動作するか確認する必要があります。