アプリサイズの最適化（ダウンロード容量の削減）
背景与问题
OPC（B 方向）。アプリのダウンロードサイズは大きいほど、回線が遅い環境・古い端末・更新を避けがちなシニア層でインストールと更新のハードルになる。両プラットフォームの公式ガイドを基準に、既定設定と点検項目を決める。
发现
（出典はいずれも 2026-09-17 アクセス）
- Android 公式：Android App Bundle（AAB）で提出すると端末構成ごとに最適化された APK が生成され不要リソースを配らない。R8 による shrink・未使用リソース削除・vector drawable・アセット圧縮が定石（Reduce your app size）。
- Apple 公式：アセット最適化、On-Demand Resources（ODR）で必要時に取得、Xcode の App Thinning Size Report で端末別サイズを確認、セルラー通信のダウンロード上限以下を保つ（Reducing your app's size）。
- 共通の定石：画像は WebP 化・未使用ライブラリ/デッドコード削除・複数 CPU アーキの同梱回避・リリース前にサイズレポート確認（r/androiddev の実務も一致）。
- 推测：シニア層の回線・端末は平均より不利で、大きなアプリは「更新すら避けられる」——サイズは機能でなく配信の属性。
结论
- 既定設定を両公式に合わせる：AAB+R8（Android）、ODR+Thinning report の確認（iOS）。新規アプリは初回からこの設定で始める（後からは手間が増える）。
- リリース前チェックに「画像 WebP 化と未使用リソースの有無」を 1 項目追加（opc-release-precheck-5min）。サイズはリリースごとに前回比較で増減を見る。
- サイズレポートの自動化を CI に足せるなら足す：iOS Thinning report・Android bundletool の出力をコミットに添付（opc-ci-fastlane-pipeline と接続）。
- 目標値は設けず前回比で管理：絶対値の目標はプラットフォームに依存し、増分管理なら劣化の早期発見になる（推测ベースの運用判断）。
待办 / 下次继续
关联
opc-release-precheck-5min opc-ci-fastlane-pipeline opc-app-battery-optimization opc-test-device-lab