プレイヤーのファイルサイズを削減する 2 つの主な方法は、Xcode の Active Build Configuration と、Unity の Stripping Level を変更する方法です。
完成版のリリース用のビルドは、Xcode 4.x/5.x のコマンドの Product -> Archive で行われることを想定しています。このコマンドを使用すると、リリース設定でのビルドの作成とすべてのデバッグシンボルの削除を確実に実行できます。 このコマンドを送った後、最近の Xcode は Organizer ウィンドウの Archives タブに切り替わります(手動で移動するには、Window -> Organizer の順にメニューを選択します)。そちらには App Store size estimation と Distribution の 2 つのとても便利な機能があります。 ビルドサイズ見積り機能はとてもよい働きをしますが、3G ダウンロードリミット (現在は 100MB) に設定する場合、エラーへの対策としていくらか余分なマージンを常に持っておくことをお勧めします。
ストリッピング作業によるサイズの最適化は以下のように行われます。
Strip assemblies : スクリプトのバイトコードが分析され、スクリプトから参照されないクラスやメソッドは DLL から削除されます。その結果それらを AOT コンパイルフェーズから除外することができます。この最適化によりメインのバイナリサイズや付随する DLL のサイズは削減され、リフレクションが使用されないかぎり問題ありません。
Strip ByteCode レベル: .NET DLL (Data フォルダーに保管) はストリッピングされてメタデータのみになります。これができるのは、すべてのコードが AOT フェーズですでにプリコンパイルされていて、メインバイナリにリンクされているためです。
Use micro mscorlib レベル: 特別で小さいバージョンの mscorlib が使用されます。いくつかのコンポーネント、例えば、Security、Reflection.Emit、Remoting、non Gregorian calendars、その他はこのライブラリから除かれます。さらに内部コンポーネント間の相互依存関係は最小限になります。この最適化によりメインバイナリや mscorlib.dll サイズを削減できますが、いくつかの System や System.Xml アセンブリクラスと互換性がないため慎重に使用してください。
これらのレベルは累積なので、レベル 3 の最適化は暗示的にレベル 1、2 を含み、レベル 2 は暗示的にレベル 1 を含みます。
Micro mscorlib はコアライブラリが大きくストリッピングされたバージョンです。Unity で Mono ランタイムに必要なアイテムのみが残ります。micro mscorlib を使用するベストプラクティスは、アプリケーションで必要ない .NET のクラスや機能を使用しないことです。GUID などは、そのいい例です。GUID はカスタム作成された擬似 GUID で簡単に置き換えることが可能で、結果的によりよいパフォーマンスやアプリケーションサイズを得られます。
詳細は managed bytecode stripping with IL2CPP を参照してください。
ノート アプリケーションに必要とされているのに誤ってストリッピングされてしまったクラスがどれなのかを判断するのが難しい場合があります。シミュレーターでストリッピングされたアプリケーションを実行し Xcode コンソールのメッセージをチェックすると、有用な情報が得られることがしばしばあります。
空プロジェクトはサイズ最適化をすべてオフにすると App Store で 22MB 未満です。コードストリッピングを使用すると、メインカメラのみの空のシーンは App Store でおよそ 12MB 未満に縮小できます (zip や DRM 設定)。
アプリをパブリッシュするときに App Store では最初にバイナリファイルを暗号化して zip で圧縮します。暗号化によってコードセグメントがよりランダムになり、圧縮の条件が悪くなります。上記の「リリースモードでビルド」を参考にして、提出する前に App Store サイズを見積もる方法を確認してください。
2017–14–06 編集レビュー 無しに修正されたページ - ページのフィードバックを残す
2017–07–27 編集レビュー 無しに修正されたページ - ページのフィードバックを残す
2017–14–06 - IL2CPP のストリッピング セクションを更新