非圧縮性の圧縮-モバイルアプリケーションの配布を減らす方法

現在、iOSおよびAndroidプラットフォームのアプリケーションストアでは、アプリケーションサイズに100 MBの制限があります。 この制限に適合しないアプリケーションのApple Storeは、モバイルインターネットを使用したダウンロードを禁止しています。 Google Playでは、これはAPKのサイズの厳密な制限です。APKに収まらないものはすべて、 アドオンファイルに転送する必要があります。 有料のトラフィックを持つユーザーの場合、大きなアプリケーションのダウンロードは非常に高価になる可能性があるため、必ずサイズを小さくするようにしてください。









この記事のフレームワークでは、iOSプラットフォーム用のGardenscapesプロジェクトでこの制限を満たすことができたトリックを紹介します。 この記事は主にモバイルゲームに関するものですが、圧縮方法は普遍的であり、グラフィックの重いプロジェクトに役立ちます。 圧縮方法について説明するには、アプリケーションアーカイブの形成方法を決定する必要があります。

Apple App Storeのフォーマット

IOSアプリケーションは、拡張子が.ipaのバイナリファイルとして配布されます。 これらは圧縮された.zipフォルダーであり、アプリケーション実行可能ファイル（ARMアーキテクチャーを搭載したプロセッサー用）とアプリケーションリソースが含まれています。 .zip形式を使用するということは、アーカイブを操作して学習するための便利なユーティリティを使用してipaファイルを開くことができることを意味します。 具体的には、Appleは独自のLZFSE形式を使用しており、アーカイブを解凍するのはそれほど簡単ではありません。 それにもかかわらず、アーカイブの内容は追加の労力なしで読み取ることができます。 例として、Gardenscapesプロジェクトのipaコンテンツを見てみましょう。







.ipaファイルのリソース割り当て図



ほとんどのリソースはゲームリソースですが、実行可能ファイルはほとんど劣っています。 同時に、システムリソースとSDKリソースはアーカイブ内でかなりのスペースを占有するため、それらを最も頻繁に最適化する意味はありません。

実行可能ファイルのサイズの最適化

実行可能ファイルは、次の2つの理由で非常に多くのスペースを占有します。

1. 2つのアーキテクチャ（32ビットと64ビット）のバイナリコードが含まれています。
   
   
2. ipa実行可能ファイルは暗号化されているため、圧縮率が大幅に低下します。
   
   

iOS 9以降、AppleはApp Thinningテクノロジーを使用し、アーキテクチャごとに異なるパッケージを収集するため、最初のポイントはもはや関係ありません。 開発者の観点からは、これは透過的に機能します。以前と同様に、1つのアプリケーションを送信に送信します。 また、ユーザーはデバイスに応じて32ビットまたは64ビットの実行可能ファイルのみをダウンロードします。 したがって、iOSバージョン9より前のデバイスをサポートしない余裕がある場合、実行可能ファイルのサイズは約半分に分割できます。 同時に、iOS 8以前のバージョンを使用しているユーザーは、両方のアーキテクチャを含むアーカイブをダウンロードします。



ポイント2は常に関連しています。 推定IPAサイズを計算するときは、実行可能ファイルの非圧縮サイズを考慮する必要があります。 最良のケースでは、わずかに収縮します。 Appleが大量のデータ（画像、大きなテキストリソースなど）を実行可能ファイルに保存することをお勧めしないのは 、このためです。これにより、アプリケーションサイズが異常に大きくなる可能性があります。 Xcodeの最適化設定を確認し、余分なライブラリを接続していないことを確認することも価値があります。

リソース最適化

モバイルゲームの場合は、リストに従って、より重いものから軽いものまで、リソースのグループを選択できます。

1. ゲームグラフィックス;
   
   
2. アニメーション
   
   
3. ビデオとサウンド。
   
   
4. フォント
   
   
5. テキストリソースとテキスト設定ファイル。
   
   

ipaはzipアーカイブであるため、最後の2つのリソースグループを圧縮しようとすることはあまり合理的ではありません。 テキストデータは通常、追加の労力なしで非常に強く圧縮されます。

ゲームの圧縮

グラフィックサイズは、次の2つの方法で縮小できます。

1. 透明なピクセルを節約するために、グラフィックをポリゴンアトラスにしっかりと詰め込みます。 多角形のアトラスはRAMを節約するように設計されていますが、アトラスを含むファイルのサイズもわずかに小さくなります。
   
   
2. 必要な品質に応じてグラフィックを異なるグループに分割し、各グループを独自の圧縮形式でパックします。
   
   

私たちのプロジェクトは主にpng、webp、pvrtcを使用します。

• png：ロスレス圧縮形式。 最高の品質を備えていますが、多くのディスク容量を占有します。 webpのロスレスバージョンはサイズが最適であるため、この形式をアプリケーションで使用することはお勧めしません。 ただし、ipaのブート画面とアプリケーションアイコンは.png形式である必要があります。 Macポートで利用可能なoptipngユーティリティを使用して、.pngサイズを最適化します。
  
  
• webp：許容サイズの不可逆バージョン。 さまざまなタイプの画像の品質を変更できますが、長時間解凍されます。 ロスレスオプションもあります。
  
  
• pvrtc： iOS用のハードウェアでサポートされている圧縮形式。 読み込みが速く、スペースをほとんど必要としません。 ただし、いくつかの制限があります。 まず、画像は必ず2の累乗に等しい辺を持つ正方形でなければなりません。
  
  
  
  第二に、pvrtcは不可逆形式であり、非常に不可逆です。 慎重に使用する必要があり、高品質を必要とするグラフィックには使用しないでください。 透明な領域のあるグラフィックにはあまり適していないため、境界線上にアーティファクトが生じます。 pvrtc形式の主な利点は、RAMの節約です。 pngおよびwebp形式とは異なり、レンダリングのためにRGBAで解凍する必要はありません。
  
  

圧縮形式には独自の品質設定があり、カスタマイズすることもできることを忘れないでください。

Webp 100	Webp 95	Webp 85

圧縮例



85、95、100の品質設定で圧縮されたwebp形式の同じ画像の例。違いは顕著ですが、最も圧縮された画像でさえ許容範囲に見えます。 webp85とwebp95のサイズの違いは約3 KBです。



解凍速度に問題があるため、webpは注意して使用する必要があります。 遅いデバイスでは、そのような画像をロードすると、顕著な遅れが生じる可能性があります。 オンザフライでロードされる大きなグラフィックのパッケージ化には使用しないでください。



表は、さまざまな形式で圧縮された場合のアトラス2048x2048の寸法を示しています。

書式	png	pvrtc	webp ロスレス	webp 95品質	webp 85品質
サイズKB	8057	2049	5593	2218	1579

ご覧のとおり、png形式はまったく使用しないでください。 webpおよびpvrtc形式から、グラフィックの品質と読み込み速度の要件を考慮して、適切な形式を選択できます。

アニメーション

Gardenscapesは、主に.swfからエクスポートされたキーフレームアニメーションを使用します。 このようなアニメーションのスペースを節約するには、1秒あたりのフレーム数（FPS）を最適化する必要があります。 このプロジェクトでは、標準周波数は24 FPSであり、アニメーションの品質は低下せず、非常にコンパクトです。 フレームレートに加えて、詳細の量はアニメーションのサイズに影響します。 アニメーションに多くの詳細が含まれている場合、そのサイズも大きくなります。キーフレームの各セットが各パーツに保存されるためです。 追加の圧縮には、アニメーションに特別な不可逆コーデックを使用します。 FSEコーディングも使用しています 。詳細については、 こちらをご覧ください 。

ビデオとサウンド

ここには一般的な推奨事項はありませんが、一般的には、エンコード形式の微調整に帰着します。 ここでは驚異的なゲインを得ることができません。元のバージョンと比較してビデオを約30％圧縮し、サウンドを約10〜20％節約できました。 それはすべて特定のビデオとオーディオに依存します-設定を実験的に選択する必要があります。

フォント

通常、ほとんどのアプリケーションではフォントは多くのスペースを占有しません。 しかし、これは、象形文字を書く言語のローカライズに出会うまでです。 そこの文字数は数千単位で測定できます。 これにより、フォントファイルが数メガバイトに増加します。 これに対処するために、ゲームテキストを含むファイルに基づいてキャラクターのリストを作成する自動スクリプトを使用します。未使用のキャラクターはすべてすべてのフォントから削除されます。

テキストリソースとテキストチューニングファイル

これは通常、最小のリソースグループであり、個別に最適化する必要はありません。 ipaファイル自体はアーカイブであり、テキストデータは適切にアーカイブされています。 それにもかかわらず、私たちのプロジェクトでは、テキストは非常に多くのスペースを占有します。 主に多くのローカライズをサポートする必要があるため。

すべての可能性が尽きた場合

ビルドサイズは本当に問題です。 すべてがどれほど深刻かは、私たちが発明したいくつかの追加の圧縮方法によって理解できます。

1. ipaファイル内では、アプリケーションはいわゆるパッケージにパッケージ化されています。 すべてのアプリケーションファイルは、「Payload / <パッケージ名.app>」フォルダーにあります。 ファイルをzipアーカイブにパックすると、そのフルパスが目次に追加されます。 したがって、<package_name.app>はすべてのゲームファイルの目次に含まれます。 また、ファイルが多数ある場合は、何でも言うことができ、余分な情報が複製されます。 パッケージの名前を1文字だけで、少なくとも少しだけ名前を変更しましたが、サイズは小さくしました。
2. 実行可能ファイルの内容を見ると、C ++ソースファイルへのフルパスがあることがわかりました。 彼らはどこから来たのですか？ いくつかの__FILE __、__ LINE__マクロが実動コードに分類され、コンパイラーはそれらが使用されたソースファイルごとに慎重にそれらを開いたことがわかりました。 このようなマクロの監査を実施し、ビルドをさらに削減しました。
   
   
3. 他にアイデアはありますか？ コメントを書いてください。
   
   

合計

ビルドサイズの最適化は広範なトピックです。この記事では、リソース圧縮の一般的な原則と方法についてのみ説明します。 これに加えて、他の難しい質問が通常発生します：

• リソース管理：重複リソースを取り除き、すべての未使用リソースを見つける方法。
  
  
• 100 MBに収まらない場合、インターネットからリソースをダウンロードするためのシステム。 ユーザーが最小限の不快感を感じるようにリソースの追加読み込みを整理する方法。デザイナーがそれを操作するのに便利です。
  
  
• 特にゲームのバージョンを更新するときに、トラフィックの消費を最小限に抑える方法。
  
  

この記事に記載されている手法は、特定のプロジェクトにおける開発チームの経験です。 しかし、それらは非常に普遍的であり、モバイルゲームだけでなく、他のアプリケーションにも使用できます。

ポスト台本

記事の公開準備中に、Appleは最大ビルドボリュームを150 MBに増やしました。 それは良く見えるだろう。 ただし、Google Playにはまだ100 MBの制限があります。 その結果、すべてがさらに複雑になります。 iOS向けのビルドの準備で150 MBのAppleストアの制限のみに焦点を当てる場合、その後Android向けのビルドの準備では100以内に収めることはできません。



アプリケーションストアの機能を最適に使用するには、iOSとAndroidの異なるビルドを作成する必要があります。 私たちはまだ最善の解決策を見つける過程にあります。 そして、Googleからの制限を増やすための同様のステップを本当に楽しみにしています。 その後、記事のテキストの100を150に単純に置き換えることが可能になり、再びすべてが正しくなります。