20、低内存设备适配：Low Memory Killer机制、onTrimMemory回调、进程优先级、多级缓存策略
低内存设备适配，说白了就是让App在资源紧张的环境下还能体面地活着。我这些年做性能优化，最头疼的就是处理各种低端机的OOM和卡顿。你想想看，用户手机只有2GB内存，你的App一上来就申请几百兆，系统不杀你杀谁？
这一章，我们就来聊聊Android系统是怎么管理内存的，以及我们开发者该怎么配合系统，让App在低内存设备上也能流畅运行。
Low Memory Killer机制：系统最后的防线
Android系统里有个守护进程叫LMK（Low Memory Killer），它就像个冷酷的刽子手。当系统内存低于某个阈值时，LMK会按照进程的优先级，从低到高开始杀进程。
我遇到过不少开发者抱怨：「我的App怎么莫名其妙被杀了？」其实不是莫名其妙，是LMK在干活。系统要保证前台应用能流畅运行，牺牲后台进程是必然的。
LMK的杀进程策略基于一个关键概念——oom_adj。每个进程都有一个oom_adj值，范围从-17到15。值越小，优先级越高，越不容易被杀。
| 进程类型 | oom_adj值 | 被杀概率 |
|---|---|---|
| 前台进程（FOREGROUND_APP） | 0 | 极低 |
| 可见进程（VISIBLE_APP） | 1 | 低 |
| 服务进程（SERVICE_APP） | 2-5 | 中等 |
| 后台进程（HOME_APP / PREVIOUS_APP） | 6-7 | 高 |
| 内容提供者（CACHED_APP） | 8-15 | 极高 |
嗯，这里要注意：不同厂商的ROM可能会修改LMK的阈值。比如小米的MIUI就特别喜欢杀后台，oom_adj阈值调得特别激进。我曾在某款千元机上测试，App切到后台不到30秒就被杀了。
核心观点：LMK不是bug，是feature。我们要做的不是对抗它，而是理解它、适应它。
onTrimMemory回调：系统给你的最后通牒
系统在决定杀进程之前，会先给App一个机会——通过onTrimMemory()回调通知你。这个回调在Activity、Fragment、Service、Application、ContentProvider里都有。
我个人习惯在Application里统一处理这个回调，因为这样能全局感知内存压力。
public class MyApp extends Application implements ComponentCallbacks2 {
@Override
public void onTrimMemory(int level) {
super.onTrimMemory(level);
switch (level) {
case TRIM_MEMORY_RUNNING_MODERATE:
// 内存有点紧张，可以释放一些不重要的缓存
ImageCache.getInstance().trimToSize(50);
break;
case TRIM_MEMORY_RUNNING_LOW:
// 内存比较紧张，释放更多缓存
ImageCache.getInstance().clear();
break;
case TRIM_MEMORY_RUNNING_CRITICAL:
// 内存非常紧张，系统准备杀进程了
// 释放所有能释放的资源
releaseAllResources();
break;
case TRIM_MEMORY_UI_HIDDEN:
// 界面不可见，释放UI相关资源
// 比如大图、动画帧等
break;
case TRIM_MEMORY_BACKGROUND:
// 进入后台缓存列表，释放大量资源
break;
}
}
}我曾经在一个项目中，发现App在后台被杀的概率特别高。后来加了onTrimMemory回调，在收到TRIM_MEMORY_BACKGROUND时主动释放了所有图片缓存和数据库连接池，杀进程率从40%降到了5%。
避坑指南：onTrimMemory回调里不要做耗时操作，比如写文件、网络请求。系统在等你释放内存，你还在做IO操作，这不是添乱吗？
进程优先级：你的App值不值得活
Android系统把进程分成了五类优先级，从高到低分别是：
- 前台进程：用户正在交互的Activity，或者正在运行的前台Service
- 可见进程：Activity可见但不在前台（比如被对话框遮挡）
- 服务进程：正在运行的后台Service
- 后台进程：Activity不可见（onStop已调用）
- 空进程：没有任何组件在运行，纯粹为了缓存
你想想看，系统杀进程的顺序是从下往上的。空进程最先被杀，前台进程最后被杀。所以如果你的App想活得久一点，就得尽量让自己处于高优先级状态。
但这里有个陷阱：很多开发者为了让App不被杀，滥用前台Service。比如在后台播放音乐时，明明没有音乐在播，却还挂着前台Service。这种行为会被系统检测到，轻则降级，重则直接杀掉。
注意：Android 12开始，系统对前台Service的限制越来越严格。滥用前台Service不仅会被杀，还可能被用户举报。我建议只在真正需要的时候才使用前台Service，比如音乐播放、位置追踪等。
多级缓存策略：让App在低内存下优雅运行
低内存设备最怕什么？怕你一次性加载太多数据。所以我们需要一套多级缓存策略，让数据在不同层级之间流动。
我常用的缓存策略分三级：
- 一级缓存（内存缓存）：LruCache，大小控制在可用内存的1/8以内
- 二级缓存（磁盘缓存）：DiskLruCache，大小控制在10-50MB
- 三级缓存（网络）：按需加载，配合预加载策略
这里有个关键点：内存缓存的大小不是固定的，而是要根据当前可用内存动态调整。我习惯在onTrimMemory回调里动态调整LruCache的大小。
public class DynamicLruCache<K, V> extends LruCache<K, V> {
private final float maxPercent = 0.125f; // 最多占用1/8内存
public DynamicLruCache(Context context) {
super(calculateCacheSize(context));
}
private static int calculateCacheSize(Context context) {
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
int memoryClass = am.getMemoryClass(); // 单位MB
return (int) (memoryClass * 1024 * 1024 * 0.125f);
}
public void trimToSize(int percent) {
// 根据百分比调整缓存大小
int newMaxSize = (int) (maxSize() * percent / 100);
resize(newMaxSize);
}
}我曾在某款2GB内存的设备上测试，使用动态缓存策略后，App的OOM率从3%降到了0.1%。说白了，就是让缓存跟着系统内存走，系统紧张我就少占点，系统空闲我就多占点。
核心观点：多级缓存不是简单的「内存+磁盘+网络」，而是要配合系统的内存状态动态调整。你想想看，系统都开始杀进程了，你还占着几百兆缓存不放，这不是找死吗？
知识体系总览
下面这张图展示了低内存设备适配的核心逻辑：
从这张图可以看出，低内存设备适配不是单一的技术点，而是一个从系统到应用的完整链路。系统通过LMK和onTrimMemory给你信号，你通过进程优先级管理和多级缓存策略来响应。
最后说一句：低内存设备适配没有银弹。每个App的内存占用模式不同，你需要通过Profiler工具分析自己的App，找到内存占用的峰值和瓶颈，然后针对性地优化。我见过太多人上来就问「有没有通用的优化方案」，其实最好的方案就是理解原理，然后根据实际情况调整。
公众号:蓝海资料掘金营，微信deep3321