Article by: Max Topolsky, Steve Zegalia
Sentry は 2025年5月に Emerge Tools を買収しました。これにより開発チームに最適なモバイルツールを提供する準備が整いました。そして主力製品の1つである Size Analysis を正式にすべての Sentry ユーザーに提供を開始しました。これで、アプリサイズをもう心配する必要はありません。
CI パイプラインでの自動監視
アプリサイズが増えていく最も一般的なパターンは、少しずつ積み重なっていくことです。小さな変更が時間とともに蓄積し、気づけばモバイル通信でのダウンロード上限を超えているという警告が出るようになります。そうした小さな変更は、加えた時点であれば簡単に最適化できますが、1年後に対処しようとすると、途端に難しい作業になります。
Size Analysis は CI ワークフローに統合できるため、アプリサイズの状態を継続的に把握できます。すべてのビルドをアップロードして差分比較できます。サイズに変化があったときは、単に変わったことがわかるだけでなく、なぜ変わったのか、さらにサイズを小さくするために実施できる推奨修正があるかどうかまで確認できます。
よくあるシナリオを見てみましょう。SDK を追加する場合です。
ここに、Kingfisher を追加した際のステータスチェックがあります。Size Analysis を使うと、すぐに次のことがわかります。
- この PR により、ダウンロードサイズは約500 kB、インストールサイズは約1.5 MB増加しています。
- この PR が失敗したのは、「Install Size の差分が 1 MB を超える場合はチェックを失敗させる」という事前設定済みのしきい値があったためです。
「Comparison Page」を確認すれば、差分が想定どおりであることを確かめたうえで、PR を承認できます。このページでは全体のサイズ変化だけでなく、サイズが変化したすべてのファイルを表形式とビジュアルの両方で確認できます。
この場合、これは意図した差分であることが明らかなので、ステータスチェックを承認し、PRをマージできます 🎉。
次のシナリオを見てみましょう。新しいヒーローイメージを追加する場合です。
全体のサイズ差分は今回も確認できますが、今回は2つの Insights も表示されています。追加した画像が最適化されていないだけでなく、重複していることもわかります。中をクリックして見ると、最適化できる具体的なファイルと、それによってどれだけ容量を削減できるかを確認できます。
アプリに 9 MB 追加する代わりに、この PR の増加分は 3 MB に近いところまで抑えられます。こうしたインサイトがすべての PR にあると想像してみてください。サイズの問題に後からさかのぼって対応するために工数を使うのではなく、Size Analysis は、そもそもそうした問題が最初から起きないように防いでくれます。
すべてのビルドをアップロードする場合でも、リリースビルドに合わせて週に1回アップロードする場合でも、Size Analysis はアプリサイズに対する可視性と、実行可能なインサイトを提供します。
アプリのサイズ削減
アプリサイズのじわじわとした肥大化を防ぐには自動監視が重要ですが、実際には、すでにアプリのスリム化が必要になっている場合もあります。アップロードしたすべてのビルドについて、Size Analysis は、サイズの内訳と、サイズをどう減らせるかを詳しく示してくれます。
ここでは CalAI アプリ（公開されている App Store ビルドを分析）を見てみましょう。CalAI のインストールサイズは約 250 MB です。Size Analysis を見ると、アプリサイズの大きな割合（30%）が、asset.car ファイルが2回重複していることに起因していると、すぐにわかります。
Insight の詳細を開くと、すべての Insight の一覧を確認できます。
あるいは、treemap 上ですべての Insight をハイライト表示し、ノードにカーソルを合わせることで、そのサイズをどのように削減できるかを確認することもできます。
ビルドの詳細を見ると、すぐに改善できるサイズ削減の余地を見つけるのに役立つだけでなく、サイズがどこから来ているのかを理解するのにも役立ちます。以下は Chess.com アプリです。（これも公開されている App Store ビルドを分析したものです。）
重複ファイルや不要なバイナリデータに関する Insights がいくつか表示されていますが、openingbook.json という比較的大きなノードがあることも確認できます。
21 MB もの JSON はかなり大きく、すぐに疑って見るべき対象です。このファイルを調べると、実際には Chess.com がハイライト表示しているあらゆる定跡の一覧であることがわかります（Chess.com で対局したときに、見慣れない定跡名が表示されたことがあるなら、その元データがこれです）。
ここでの問題は JSON が minify されていないことです。そのため単純に minify するだけで 21 MB → 13 MB まで減らせます。さらにこれを SQLite ファイルにすることでサイズを小さくできる可能性がありますし、以前ローカライズのサイズについてこちらで紹介したのと同様にキーの重複排除を行って、より積極的に最適化することもできます。
Chess の JSON の脱線話はさておき、要点は、Size Analysis を使うとアプリサイズの増加要因と、その削減方法が明確になるということです。Size Analysis の改善ポイントを適用するのは簡単で、次のように進められます。
- アプリに余計な肥大化要因が入り込まないよう、自動監視を行う
- サイズ削減の機会を、対応できるタイミングで順次つぶしていく（あるいは、近いうちには Seer がやってくれるかもしれません 😉）
- 継続的に追跡する
Size Analysis を始めるには
すべてのSentryプランには、月次請求期間ごとに100件のビルドアップロードが含まれています（より多くのアップロード容量が必要な場合は、Enterpriseプランをご利用ください）。アップロードされたビルドはモバイルビルドのリリースページで確認でき、必要に応じてPRに自動サイズ変更通知を追加することもできます。正確な設定手順については、Size Analysis のドキュメントを参照してください。
Sentryアカウントをお持ちでない場合は、無料で始めることができます。
Original Page: Size Analysis is generally available in Sentry
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
