ビットマップは、アプリ内で最もメモリを消費するオブジェクトであることが多く、デコードとスケーリングのオペレーションは、フレーム レンダリングのクリティカル パスに頻繁に存在します。ビットマップのメモリ使用量を最適化すると、ジャンク、ANR、OOM 関連のプロセスの強制終了が減少し、UI の応答性、バッテリー寿命、全体的な安定性が大幅に向上します。
ビットマップのメモリ使用量が多いことを特定する
Android Vitals は、Android デバイスからデータを集計して、アプリのビットマップ メモリ使用量に関する指標を提供します。デフォルトでは、これらの指標は、日単位のデータの 28 日間のサマリーとして計算されます。このデータは、さまざまなデバイスタイプとバージョンにおけるメモリ効率の傾向と潜在的な回帰を特定するのに役立ちます。
Android Vitals は、次のプロセス状態別に分類されたアプリのビットマップ メモリ使用量を共有します。
- フォアグラウンド: アプリのプロセスが表示されます。P99 は、フォアグラウンドと他のプロセス状態とで大幅に異なることが想定されますが、P99/P50 の比率が著しく高い（3.5 倍を超えるなど）場合は、多くの場合ビットマップのメモリリークを示しているため、デベロッパーは調査する必要があります。これは、一般的な使用量（P50）と外れ値の使用量（P99）の差異を確認することで特定できます。一般的なアセットの肥大化はすべてのパーセンタイルでメモリを均一に増加させますが、メモリリークは時間の経過とともに複合化し、テールエンド データ（P99）を大きく歪めます。アプリが他の状態に移行した後、フォアグラウンドのビットマップ割り当てが不必要に保持されないようにします。
- ユーザーが認識しているサービス: アプリのプロセスが認識可能な状態で実行されています。これには、フォアグラウンド サービス、優先ジョブ、ユーザーが開始するデータ転送ジョブが含まれます。アプリは、これらの状態に移行する際に、大きなフォアグラウンド ビットマップ割り当てを保持してはなりません。これらのサービスは長時間実行されるタスクを想定して設計されているため、大きなアセットを保持すると、全体的なユーザー エクスペリエンスが低下し、Low Memory Killer Daemon（LMKD）が優先度の低いプロセスを終了してメモリを再利用せざるを得なくなります。
- バックグラウンド: アプリがバックグラウンド サービスを実行しているか、最近バックグラウンドに移行したものの、まだキャッシュに保存されていません。このプロセス状態はフォアグラウンド プロセスや知覚可能プロセスよりも重要度が低いため、アプリはここで大きなビットマップ アセットを明示的に解放して、メモリ負荷を軽減する必要があります。
- Cached: アプリがキャッシュに保存されている状態です。この状態は、LMK などのシステム メモリ プレッシャーに非常に敏感です。この状態では、OS による強制終了を回避するために、アプリはビットマップ メモリ使用量を積極的に削減する必要があります。
ビットマップのメモリ使用量が多い原因
使用されていない仮想メモリも計算に含まれることがあります。ビットマップのメモリ使用量が予想以上に高い場合は、未使用のメモリを割り当てていないことを確認します。