Android 17正在改变系统处理高内存占用应用的方式。Google首先在Pixel设备上引入应用级内存上限，目的是防止单个应用消耗过多RAM并拖慢整部手机。应用超过分配预算后，系统可以先降低其性能、把部分数据推入压缩内存；如果占用继续增长，Android还可以终止该进程。内存优化因此正从一般性的开发建议变成平台层面的实际约束。
Android 17开始为每个应用设定内存预算
Google强调，这不是一触及上限就立即关闭应用，而是逐级采取措施，在保护整机响应速度的同时给应用留下恢复空间。游戏、媒体工具以及需要长期在内存中保留大量数据的复杂应用会更直接地感受到这一变化。
应用超过RAM上限后会发生什么
当应用达到分配的内存上限时，Android可以强制把部分内存页转移到zRAM，也就是压缩后的RAM区域。这样可以暂时缓解物理内存压力，但压缩和解压需要额外CPU资源，因此在应用真正被关闭之前，用户就可能看到卡顿、停顿或响应变慢。
– 第一阶段 — zRAM交换：Android压缩内存页并移入zRAM，降低物理RAM压力，进程可以继续存在，但额外CPU开销可能带来明显变慢。
– 第二阶段 — 终止进程：如果应用继续增长并超过zRAM阈值，Android可以关闭该应用。开发者可通过ApplicationExitInfo检查相关退出，说明中可能出现“MemoryLimiter:AnonSwap”。
Google为何现在收紧内存管理
Google表示，硬件市场变化是推动这项政策的原因之一。随着内存价格上涨，一些新设备选择维持甚至降低物理内存容量，但用户仍要求应用保持快速流畅。Android因此需要更强的系统保护，避免一个优化不佳的进程影响整台设备。
这项政策也不会只停留在Pixel。Android 17先从Pixel开始，但Google表示未来一年会有更多厂商在4GB到16GB以上不同RAM配置的设备上采用应用级内存限制。开发者不能再把它当成Pixel独有的问题。
开发者与Android用户需要面对什么
Google建议开发者主动测量内存行为，而不是等用户投诉。Android vitals可查看不同进程状态和RAM等级下的内存与位图内存数据；Firebase Crashlytics 20.1.0增加了OOM和Memory Limiter终止的调试信息；ProfilingManager则可以从生产设备收集堆转储和内存分析资料，用于定位内存泄漏和过度分配。
对用户来说，好处是后台应用更难独占RAM并拖慢整部手机；代价则是优化不佳或内存需求极高的应用可能更容易卡顿、重新加载甚至关闭。目前限制从运行Android 17的Pixel开始，未来几个月预计会扩展到其他厂商，尤其在旧设备和低内存手机上，应用优化的重要性会进一步上升。
