モバイル開発におけるApp Size Optimization: 基本、方法、実践

App Size Optimizationとは

App Size Optimization は、アプリケーションのインストールパッケージのサイズを最小化することを目的としたモバイル開発の分野です。デッドコードやリソースの削除、画像圧縮、ライブラリの最適化、異なるアーキテクチャ向けのビルド分割、オンデマンド配信技術の使用などが含まれます。

アプリケーションのサイズは、ユーザーセグメントによって不均等に影響します。モバイルインフラが発達した地域（米国、欧州、日本）では50MBと100MBの差は気づかれないかもしれません。発展途上地域（インド、インドネシア、ブラジル）では、データプランの制限やモバイルインターネット速度のため、余分なメガバイトごとにインストールコンバージョンが低下します。Google Play はAPKサイズを200MBに制限していますが、100MB未満に保つことを推奨しています。

iOS App Storeの場合、セルラーネットワークでの最大ダウンロードサイズは200MBです（2023年以前は150MBでした）。IPAがこの制限を超えると、ユーザーはWi-Fi経由でしかアプリをインストールできません。AppleはApp Thinningもサポートしており、Slicing、Bitcode、On-Demand Resources — デベロッパーの介入なしに特定のデバイスでのインストールサイズを自動的に削減する技術 — が含まれます。

アプリのサイズが重要な理由

アプリのサイズは、インストールコンバージョンだけでなく、リテンション、アップデート頻度、初回起動速度にも影響します。追加のメガバイトごとに、ユーザーと製品使用の間の障壁となります。

インストールコンバージョンへの影響

Google I/O 2024のデータによると、APKを10MB削減するとインストールコンバージョンが平均3.5%向上します。150MB以上のアプリの場合、同じクラスの50MBのアプリと比較してコンバージョンが20–30%低くなる可能性があります。この効果は特にGoogle Playで顕著で、ユーザーはインストール前にサイズを確認します。App Storeではサイズがアプリページに表示され、データプランが限られているユーザーはインストールをWi-Fiまで先延ばしにし、その後アプリのことを忘れてしまうことがよくあります。

アップデート頻度とOTAアップデート

大規模なアプリはOTAアップデートの頻度が低くなります — ユーザーはパッチのダウンロードをWi-Fiまで先延ばしにし、重要なセキュリティ修正を見逃します。Google PlayはIncremental Updates（最大10MBのパッチ）を許可していますが、完全な再インストールでは依然として完全なAPKまたはAABがダウンロードされます。Apple App StoreはDelta Updatesを使用し、変更されたファイルのみを転送しますが、リソースが変更された場合でもデルタは大きくなる可能性があります。

初回起動と展開

サイズは初回起動時間に直接影響します。アプリはリソースを展開し、コードをコンパイルし（Android）、キャッシュに署名する（iOS）必要があります。200MBのアプリは、平均的なデバイスで50MBのアプリより10–15秒遅く起動する可能性があります。これによりオンボーディングエクスペリエンスが悪化し — ユーザーは読み込みを待たずにアプリを閉じてしまう可能性があります。

リソースとアセットの最適化

リソース — 画像、フォント、サウンド、動画 — は、典型的なモバイルアプリのサイズの60–80%を占めます。リソースの最適化は、最小の労力で最大の効果を得られます。主な方向性は、圧縮、重複と未使用アセットの削除、適切な形式の選択です。

画像最適化

WebP — Googleの画像形式で、同じ視覚品質でPNGより25–35%、JPEGより15–20%優れた圧縮を提供します。AndroidはAPI 18以降、WebPをネイティブサポートしています。iOSでは、SDWebImageやKingfisherライブラリを介してWebPがサポートされ、iOS 17からネイティブサポートが追加されました。AVIF — より現代的な形式で、WebPと比較してさらに10–15%の削減を実現しますが、デコードは遅くなります。

未使用リソースの削除 — サイズ削減の最も簡単な方法です。Androidでは、Android Studioでリファクタリングを使用します：Analyze → Run Inspection → Unused Resources。iOSでは — Build Settings → Remove Unused Resources。プロジェクトには、初期バージョンのスプライト、古いアイコン、未使用の起動画面画像が残っていることが多く、機能的な負荷なしにサイズを肥大化させます。

フォントとサウンドの最適化

カスタムフォントは5–15MBを占有する可能性があり、特に書体全体（Regular、Bold、Italic、BoldItalicのすべてのスタイル）が含まれている場合は顕著です。サブセッティング — アプリでサポートされていない言語のグリフを削除 — を通じて、必要なスタイルと文字サブセットのみを使用します。Google FontsやTransfonterなどのサービスは、最小限の文字セットを作成できます。オーディオには、WAVや非圧縮形式の代わりにAAC/HE-AACを使用します — 品質を損なうことなく最大90%の削減が可能です。

コードとライブラリの最適化

コードはアプリサイズの20–40%を占めますが、その最適化はリソースより複雑です。依存関係の分析、難読化、機能を壊すリスクなしでのデッドコード削除が必要だからです。

Android向けProGuardとR8

ProGuard は、コードの難読化、最小化、最適化を実行するAndroidツールです。R8 — その後継で、Android Gradle Pluginに組み込まれており、より高速かつ効率的に動作します。R8は未使用のクラスとメソッドを削除し、変数名を短縮し、命令数を減らすためにコードを書き換えます。R8によるDEXファイルサイズの一般的な削減率は30–50%です。

// build.gradle — 最小化のためのR8設定
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

ライブラリと依存関係の最適化

ライブラリ — サイズ肥大化の一般的な原因です。1つのライブラリが、アプリに直接的な利益をもたらさずにサイズを5–20MB増加させる推移的依存関係を引き込む可能性があります。明示的な依存関係宣言とともに、AndroidにはGradle Version Catalog、iOSにはSwift Package Managerを使用します。Android StudioのBuild AnalyzerやXcode Build Timelineでサイズを分析します。重いライブラリを軽量な代替品に置き換えます：例えば、Apache HTTP（15MB）の代わりにOkHttp（3MB）。

iOSでの未使用コードの削除

Dead Code Stripping — Xcodeのリンク段階で未使用のメソッドとクラスを自動的に削除します。Build Settings → Dead Code Stripping = YESで有効にします。Bitcode — Appleが異なるアーキテクチャ向けに再コンパイルできる中間表現で、未使用の関数を削除します。ただし、Xcode 14以降、Bitcodeはオプションになり、サイズ削減への貢献はObjective-Cプロジェクトで5–15%、Swiftではそれ以下です。

App Thinningとオンデマンド配信

App Thinning — 特定のデバイスに必要なリソースのみを配信することで、インストールされたアプリのサイズを自動的に削減するAppleの技術です。Slicing、On-Demand Resources、Bitcodeの3つのコンポーネントで構成されています。Androidでは、Dynamic Deliveryを備えたAndroid App Bundle（AAB）がこれに相当します。

Android App Bundle（AAB）

AAB — Google Playでの公開形式で、ストアがデバイスごとに個別にAPKを生成し、そのアーキテクチャ（armeabi-v7a、arm64-v8a）、画面密度（mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi）、言語のリソースのみを含めます。ユニバーサルAPKからAABへの移行時の一般的なインストールサイズ削減率は20–40%です。Play Feature Delivery はオンデマンドでのモジュール読み込みを可能にし、Install-timeモジュールはベースインストールに含まれます。

// build.gradle — AABとDynamic Featuresの設定
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

iOSのOn-Demand Resources

On-Demand Resources（ODR）— リソース（ゲームレベル、高解像度画像、動画）がユーザーに実際に必要とされた場合にのみAppleのサーバーからダウンロードされるiOSのメカニズムです。初期インストールサイズは50–80%削減できます。リソースは3つのカテゴリに分類されます：Initial Install Tags（インストール時にダウンロード）、Prefetched Tag Order（インストール後にバックグラウンドでダウンロード）、On-Demand（リクエスト時にのみダウンロード）。Appleは、最初の画面で必要ないコンテンツ（ゲームレベル、追加コンテンツ、動画チュートリアル）にODRを使用することを推奨しています。

SwiftUI はBundle.module属性を介してODRをサポートし、UIKitはNSBundleResourceRequestを使用します。UnityやUnreal Engineのゲームでは、ODRはネイティブラッパーレベルで統合されます。主な制限事項は、ストレージが不足するとODRリソースがシステムによって削除されることです。そのため、重要なデータはメインビルドに含める必要があります。