アプリのメモリ制限を緩和するための準備

優れたユーザー エクスペリエンスは Android のミッションの中核であり、その約束を果たすには、デバイスの高速性、応答性、信頼性を維持する必要があります。そのため、メモリの最適化がこれまで以上に重要になっています。エコシステム全体で、メモリ価格の上昇に対応して、新しいデバイスの物理メモリ容量が維持または減少していますが、ユーザーはシームレスで高性能なアプリ エクスペリエンスを期待し続けています。

Android 17 では、メモリを過剰に使用してシステム全体の速度低下を引き起こすアプリからユーザー エクスペリエンス全体を保護するため、まず Google Pixel デバイスを対象に、アプリごとのメモリ上限を導入しました。今後 1 年間で、4 GB から 16 GB 以上のデバイスまで、デバイスの RAM 構成のポートフォリオ全体で Android のアプリごとのメモリ上限を活用するメーカーが増えていくでしょう。 アプリがこれらの制限を超えると、アプリの動作が遅くなり、強制終了される可能性があります。OS のスロットリングを防ぎ、シームレスなユーザー エクスペリエンスを維持するには、アプリのメモリ使用量を最適化することが不可欠です。  

この投稿では、これらの制限がどのように機能するのか、新しい Android Vitals 指標を使用してメモリ使用量を測定する方法、アプリやゲームを最適化するための具体的な手順について説明します。

メモリ上限について

アプリがメモリ容量を超えると、Android はデバイスの応答性を保護するために段階的な措置を講じます。

1. zRAM スワッピング: アプリが割り当てられた上限に達すると、システムはアプリのページを zRAM（圧縮された RAM）に強制的に移動します。zRAM は即時の削除を防ぎますが、ページの圧縮と解凍によって CPU オーバーヘッドが増加し、UI のジャンクやエクスペリエンスの遅延が顕著になる可能性があります。
2. プロセスの終了: アプリのメモリ使用量が zRAM のしきい値を超えて増加し続けると、システムによって終了されます。  アプリ セッションがフィールドでこれらの制約の影響を受けたかどうかを判断するには、ApplicationExitInfo 内で getDescription() を呼び出すことができます。システムが制限を適用した場合、終了理由は REASON_OTHER として報告され、説明文字列には「MemoryLimiter:AnonSwap」が含まれます。また、TRIGGER_TYPE_ANOMALY を使用してトリガーベースのプロファイリングを活用し、メモリ上限に達したときにヒープダンプを自動的にキャプチャすることもできます。  

アプリごとのメモリ上限とシステムによる適用について詳しくは、Android 17 アプリのメモリ上限に関するドキュメントをご覧ください。さまざまなデバイス構成でアプリをテストするには、メモリ制限ツール adb コマンドを使用します。

メモリの問題のモニタリングと診断

測定できないものは最適化できません。Android エコシステム全体でメモリリーク、過剰なヒープ割り当て、メモリ不足（OOM）クラッシュを特定するには、補完的なモニタリング ツールを活用する必要があります。

• Android Vitals によるマクロレベルの健全性: Google Play Console の Android Vitals では、メモリ使用量（匿名 RSS + スワップ） やビットマップ メモリ使用量などの重要な指標を確認できます。これにより、追加のオーバーヘッドなしで、人口レベルの広範な可視性を確保できます。これにより、さまざまなプロセス状態（フォアグラウンド、バックグラウンド、ユーザーが認識するサービス、キャッシュ）と RAM クラスの範囲にわたるメモリ分布の明確なスナップショットを取得し、メモリの異常値を特定できます。
• Firebase Crashlytics によるメモリ制限の終了と OOM のトラッキング: 主要な指標に影響を与える前にメモリの著しい低下を把握できるよう、Crashlytics バージョン 20.1.0 では、メモリ不足の例外とメモリ制限の終了を把握、優先順位付け、修正するのに役立つデバッグデータが追加されています。これらのイベントをカスタムログや Key-Value メタデータとともにトラッキングすると、メモリ障害が発生したときにプロセス ステータスのコンテキストをすぐに把握できます。
• ProfilingManager を使用したフィールド内トレース: パフォーマンスのオブザーバビリティ フレームワークを維持できるチームの場合、Android 15（API レベル 35）で導入された ProfilingManager API を使用すると、アプリは Java ヒープダンプやヒープ プロファイルなどの詳細なメモリ デバッグ アーティファクトを、本番環境のデバイスから直接プログラムでリクエストして収集できます。また、TRIGGER_TYPE_OOM や TRIGGER_TYPE_ANOMALY などの特定のシステム シグナルに基づいてヒープダンプのキャプチャをトリガーすることもできます。 

他のメモリ モニタリング手法については、ドキュメントをご覧ください。

まとめと次のステップ

Android では、すべての RAM クラスでアプリごとのメモリ上限が拡大されているため、メモリ使用量を監査する絶好の機会です。

1. メモリの最適化を優先する: おすすめの方法を使用して、アプリのメモリ上限による影響をアプリが受けないようにします。
2. メモリ使用量をモニタリングする: アプリのメモリに関する動作をモニタリングして、異常な動作を検出して解決します。  
3. ゲームを最適化する: ゲームに関する最新のガイダンスと複雑なマルチメディア アプリに沿って、プロセス状態全体でメモリの節約を最大化します。

役立つリソースと参考資料

• Android 17 の動作変更: アプリのメモリ上限
• Android Vitals: メモリ使用量（RSS + スワップ指標） と ビットマップ メモリ使用量
• Android デベロッパー ブログ: Android 17 でのメモリ効率の優先順位付けの手順
• デベロッパー ガイド:  アプリのメモリを管理する