Android のパッケージ化された apk のサイズは約: 475M.
パッケージ化されたログを確認する: Console → Open Editor Log;
または、サードパーティのプラグインに依存する: build reports tool (unity ストアでダウンロード可能);
ポジショニングの問題
調査の結果、プロジェクトのテクスチャの割合が非常に高い (82.8%) ことが判明し、アートは写真を tga から小さい png に変更したと述べました。パッケージ本体は小さくする必要がありますが、変更されませんでした。交換後、さらに 3M 大きくなり、その理由を調査し始めました。
テスト用にもっと大きなテクスチャを見つけました.リソース マネージャでのサイズは 0.7M ですが、Unity では 5.3M になります.検証の結果、画像は Unity に入った後、特定の形式に従って圧縮されると結論付けられました。 2 つの当事者の規模が一致しない:
-
テクスチャが Unity にインポートされると、自動的に圧縮形式に設定され、最初にテクスチャに透明なチャネルがあるかどうかが判断されます。
-
Android: 透過チャネルなしで ETC1 に圧縮、透過チャネルありの ETC2 に圧縮、4 で割り切れない場合は RGBA32 にフォールバック
-
IOS: 透過チャネルなしで RGB PVRTC に圧縮し、透過チャネルを使用して RGBA PVRTC に圧縮し、2 の整数乗でない場合は RGBA32 にフォールバックします。
-
したがって、最終的にコンパイルされたパッケージのサイズは、画像自体の形式やサイズとはほとんど関係がなく、制限された解像度での情報の複雑さに依存します。
調査の結果、このプロジェクトのほとんどのテクスチャは RGB16、RGBA 16、RGB32、RGBA32、ETC、ETC 2 形式で圧縮されており、多くのテクスチャのサイズは 2048、4096 であり、無駄が多すぎることがわかりました。テクスチャの割合が非常に大きい。
解決
1: 圧縮方法を ASTC に変更して、
影響の大きい画像を見つけ、圧縮形式を ASTC に変更します。
ASTC は、OpenGL ES3.0 の出現後、2012 年半ばに作成された、業界をリードするテクスチャ圧縮形式です。その圧縮ブロックは、4x4 から 12x12 まで、ピクセルあたり 1 ビット未満に圧縮できます。さまざまな圧縮率があります。選択します。ASTC 形式は RGBA をサポートし、サイズ要件のない 2 の累乗のアスペクト比の寸法と NPOT (非 2 の累乗) テクスチャに適しています。
テスト後、使用された最終的な ASTC メソッド:
(1) 法線マップ: 大量のデータを失うことを避けるには 4x4 で十分です
(2) 詳細なテクスチャ: それらのほとんどは 6x6 であり、明らかな歪みは見られません; 写真のごく一部詳細を追求 4x4 を使用
(3) 一般的なテクスチャ: 6x6 または 8x8 を選択
(4) 関係ありませんが、特に大きなサイズの写真: 8x8、10x10、12x12 を考慮することができます。そうしないと、パッケージが大きすぎます (5
) ) スプライト (UI): 6x6 缶
対応機種
iOS
AppleはA8プロセッサ以降、iPhone6(同梱)、iPad mini 4(同梱)以上のiOSデバイスが対応、2014年以前のiPhone 5sおよびiPad mini 3は対応していません。
Android
Android の主流の圧縮形式は、ETC2 から ASTC に移行しています.Unity の ASTC 形式サポートの公式説明 (公式ドキュメントにジャンプ) では、ASTC の GPU サポートについて言及しています: OpenGL ES 3.1 をサポートするすべての GPU と OpenGL ES 3.0 をサポートする一部の GPU ASTC をサポートするデバイスの 77% が Google Play でカウントされますが、これは中国ではさらに高くなる可能性があります。個人的な観点からは、ASTC 圧縮形式は広く使用されている可能性があります。)
2: 写真のサイズを変更する
Size プロジェクトのテクスチャのサイズは基本的に 2048 です.1 ピースは数メガバイトです
が、実際にはモバイル プラットフォームはそれほど大きくする必要はありません.1024 に変更されます.テストの結果、ほとんどの写真は問題ないことがわかりました。ぼやけた写真がいくつかありますが、2048 に変更できます。
最適化された apk のサイズは 352M です.これはより大きなテクスチャ専用です.均一に最適化されるとより良いでしょう.
結論は
- パフォーマンスを向上させ、メモリを節約するために、芸術によって生成される画像には 2 のべき乗のサイズを使用するようにしてください。それ以外の場合、プラットフォームまたは GPU が NPOT テクスチャ ストリップをサポートしていない場合、Unity は次の 2 の累乗サイズまでテクスチャをスケーリングして塗りつぶします。
- テクスチャの圧縮方式は、状況に応じてASTC圧縮に変更可能です。
- 視覚的に許容できる結果を得るための最小設定である最大サイズを小さくすると、テクスチャ メモリがより速く減少します。
- 法線マップの場合、ETC2 4 ビットの圧縮効果は ASTC 5x5 よりも優れています; 透過チャネルを使用するマップの場合、ETC2 8 ビットは ASTC 4x4 よりも優れています。実際の状況に応じて選択してください。
- テクスチャ アトラスを作成する: 複数のテクスチャを 1 つのテクスチャに配置することで、ドロー コールを減らし、レンダリングを高速化します。テクスチャ アトラスは、Unity スプライト アトラスまたはサードパーティのテクスチャ パッカーを使用して作成できます。
- Read/Write Enabled オプションをオフにします。有効にすると、このオプションは CPU と GPU のアドレス可能なメモリの両方にコピーを作成し、テクスチャは 2 倍のメモリを占有します。ほとんどの場合、このオプションは無効のままにしておく必要があります。実行時にテクスチャを生成する場合は、Texture2D.Apply を介して強制し、makeNoLongerReadable を true に設定して渡します。
- 不要なミップ マップを無効にする: 画面上でサイズが一定のテクスチャ (2D スプライトや UI グラフィックスなど) にはミップ マップは必要ありません。また、カメラからの距離が変化する 3D モデルの場合は、ミップ マップを有効のままにします。