Android 17では、メモリを大量に消費するアプリの扱いが変わる。GoogleはまずPixelでアプリ単位のメモリ上限を導入し、1つのアプリがRAMを使いすぎて端末全体の応答性を悪化させるのを防ぐ。割り当て量を超えたアプリは速度を抑えられ、圧縮メモリへ追い出され、それでも使用量が増え続ければプロセスが終了される可能性がある。メモリ効率は単なる推奨事項ではなく、Androidの動作条件そのものになりつつある。
Android 17でアプリごとのメモリ上限を導入
Googleによれば、上限に達した瞬間にアプリを閉じるのではなく段階的に介入する。端末全体の快適さを守りながら、アプリ側に回復の余地を残す考え方だ。ゲーム、メディア編集、複雑なツールなど、大量のデータを長時間メモリに保持するアプリほど影響を受けやすい。
RAM上限を超えると何が起きるのか
割り当て上限に達すると、Androidは一部のメモリページを圧縮RAM領域であるzRAMへ強制的に移せる。物理RAMの圧迫を和らげられる一方、圧縮と展開にはCPU処理が必要で、アプリ終了前の段階でもUIの引っ掛かりや遅延が起きる可能性がある。
– 第1段階 — zRAMスワップ：メモリページを圧縮してzRAMへ移し、物理RAMへの負荷を下げる。プロセスは維持できるがCPU負荷による遅延が出る場合がある。
– 第2段階 — プロセス終了：zRAMのしきい値を超えて使用量が増え続けるとAndroidがアプリを終了できる。ApplicationExitInfoでは「MemoryLimiter:AnonSwap」を含む説明から確認できる場合がある。
Googleが今メモリ管理を厳しくする理由
Googleは背景にメモリ価格の上昇を挙げる。新しい端末でも物理メモリ容量を据え置く、あるいは減らす動きがある一方、利用者は従来と同じ高速で滑らかな体験を期待している。そこでAndroid側が、最適化不足の1プロセスによって端末全体が遅くなるのを防ぐ必要が高まった。
対象はPixelだけにとどまらない。Android 17ではPixelから始まるが、今後1年でより多くのメーカーが4GBから16GB超まで幅広いRAM構成の端末にアプリ単位の上限を採用する見込みだ。開発者はPixel固有の問題として無視できない。
開発者とAndroidユーザーへの影響
開発者には実測による監視が求められる。Android vitalsではプロセス状態やRAMクラス別のメモリ使用量とBitmap Memoryを確認できる。Firebase Crashlytics 20.1.0はOOMやMemory Limiterによる終了のデバッグ情報を強化し、ProfilingManagerでは実機からヒープダンプやプロファイルを収集できる。メモリリークや過剰な割り当てを早期に特定するための仕組みだ。
利用者にとっては、バックグラウンドアプリがRAMを独占して端末全体を重くするリスクが下がる。一方、最適化が不十分なアプリや極端にメモリを使うアプリは、以前より引っ掛かり、再読み込み、強制終了が起きやすくなる可能性がある。現在はAndroid 17搭載Pixelから始まり、今後数カ月で他社端末へ広がる見込みで、特にRAMの少ない旧型・低価格端末では最適化の重要性が増す。
