嘿，兄弟们，今天咱们聊点儿“Android OomAdjuster是怎么搞事情”的。

先说实话，这玩意儿kan起来挺玄乎的。

其实它就是系统里负责给每个进程打分的那位老大哥。

分数越低，进程越不容易被踢。

你要是想让自己的App在内存紧张时还Neng活着，就得懂它背后的逻辑。

先别慌，我跟你解释得通俗一点。

系统里有个叫ActivityManagerService的服务，负责管理所有App进程。

AMS里藏了个叫OomAdjuster的小模块。

它负责算出每个进程的oom_adj和procState。

这俩值一起决定了LMK挑谁下马。

oom_adj数字越小优先级越高。

procState描述进程当前在干嘛，比如前台Activity、前台服务、后台缓存之类。

schedGroupCPU调度组，决定CPU资源分配权重。

别以为只有你打开App才会算分，这事儿可细碎得hen。

ACTION_ACTIVITY_RESUMED——Activity切到前台，这时候会走updateOomAdjLocked

ACTION_START_SERVICE——启动服务，会走OOM_ADJ_REASON_START_SERVICE

BIND_SERVICE——绑定服务，同理会走BIND_SERVICE

BROADCAST_RECEIVER——广播收到了也会触发一次计算。

// 简化版调用链
realStartActivityLocked
    → mService.updateOomAdjLocked
        → OomAdjuster.updateOomAdjLocked
            → updateOomAdjLSP
                → performUpdateOomAdjLSP
                    → computeOomAdjLSP
                        → applyOomAdjLSP
                            → ProcessList.setOomAdj

这一步先抢到全局锁mProcLock。

接着把当前时间戳和Zui新的mAdjSeq记下来。

LSP = Low‑Side‑Process，也就是遍历所有活跃进程列表。

LSP里会把每个进程包装成ProcessRecord。

if  == null) {
    state.setCurProcState;
    state.setCurAdj;
    return false;
}

if  {
    adj = FOREGROUND_APP_ADJ;
    procState = PROCESS_STATE_TOP;
    schedGroup = SCHED_GROUP_TOP_APP;
    state.setAdjType;
}

if ) {
    if ) {
        adj = PERCEPTIBLE_APP_ADJ;
        procState = PROCESS_STATE_FOREGROUND_SERVICE;
        capability |= PROCESS_CAPABILITY_BFSL; // Neng后台启动
        state.setAdjType;
    } else {
        // 短时FGS，仅5分钟有效
        adj = PERCEPTIBLE_MEDIUM_APP_ADJ;
        procState = PROCESS_STATE_FOREGROUND_SERVICE;
        state.setAdjType;
    }
}

for ) {
    for  {
        ProcessRecord client = conn.client;
        if  {
            computeOomAdjLSP(client, cachedAdj, topApp,
                doingAll, now, cycleReEval, true);
        }
        int clientAdj = client.mState.getCurRawAdj;
        if  {
            // 把客户端Zui高等级拉上来
            adj = Math.max;
            state.setAdjType;
        }
    }
}

// 简化版循环检测与重算
int retryCycles = false;
int cycleCount = 0;
while  {
    retryCycles = false;
    for  {
        if ) {
            // 重置序号，让它重新进入计算队列
            p.mState.decAdjSeq;
            p.mState.decCompletedAdjSeq;
        }
    }
    // 再跑一次遍历
    for  {
        if ) {
            if ) {
                retryCycles = true;
            }
        }
    }
}

• /proc//oom_score_adj： 内核读取这个文件来判断该进程在OOM场景下的排队顺序；我们通过UserManagerService#setProcessOOMScore把新值塞进去。

• schedGroup： 调度组决定CPU时间片大小；系统调用sched_setaffinity/sched_setscheduler把进程放入TOP_GROUP/DEFAULT_GROUP/RESTRICTED等不同桶子里。

• binderNeng力： 比如BFSLNeng力，会影响是否Neng在屏幕关掉后继续跑前台服务；这块信息保存在AmsConfig.processCapabilities.

• Zui后一步：把所有状态标记为Yi完成，geng新全局计数，让下一轮计算有依据。

adb shell cat /proc/$/oomscoreadj
adb shell dumpsys activity oom
adb shell ps -eo PID,NAME,OOM_ADJ | grep com.example.app

adb logcat -s OOM_ADJ


打开调试日志 
// frameworks/base/services/core/java/com/android/server/am/ActivityManagerDebugConfig.java
static final boolean DEBUGOOMADJ = true;
static final boolean DEBUGOOMADJ_REASON = true;


打开后你会kan到类似下面的log：

I/OOM_ADJ: Set 12345 com.example.app adj -100 type top-activity
I/OOM_ADJ_REASON: Reason=ACTIVITY pid=12345 uid=10086

常见坑点快速定位 

• **频繁被杀**：检查是否缺少前台Service绑定或BIND_AUTO_CREATE标记；没有的话系统会把adj直接推到CACHED_MAX。
• **短时FGS失效**：Ru果你的service在5分钟后被系统降级，那说明没有正确声明`android:foregroundServiceType`或未持久化通知。
• **Provider导致高优先级**：某些ContentProvider被大量客户端绑定，会把提供者提升到FOREGROUND_APP_ADJ；反之，Ru果提供者没活跃，则可Neng被降到CACHED层面。 
• **循环依赖卡死**：极端情况下多层绑定形成闭环会触发循环检测；若发现日志里一直打印`containsCycle`，就要审查业务中是否出现互相绑定的情况。 
• **Screen Off导致降级**：屏幕关闭后TOP App会被降到`PROCESS_STATE_CUR_TOP`并且adj仍保持FOREGROUND，但调度组切到BACKGROUND_GROUP，以免耗电。 

五、实战案例——保活小技巧
C好吧，我跟你说个真实案例：
C某公司Zuo了一个即时通讯APP，上线后用户反馈后台消息收不到，于是他们想硬撑住进程不被LMK踢掉。
C他们尝试在Manifest里加了`android:persistent=true`以及`android:process=\"com.xxx.service\"`来提升adj，却忘了加前台Service通知栏图标！结果呢？系统仍然把它当普通后台服务处理，adj飙到CACHED_MAX，一天几次崩溃日志刷屏！哈哈哈，那叫一个尴尬~.
C后来改成真正意义上的前台Service：

• 在service中调用`startForeground`； 
• 在Notification里声明对应的`sound`, `vibration`, `importance=IMPORTANCE_HIGH`； 
• 在AndroidManifest中添加 `` 。 

C这样一来当用户收到新消息时即使系统内存紧张，也只会把其它缓存进程先踢掉，而自己的service稳稳地保持在 `PERCEPTIBLE_APP_ADJ` 区间，不容易被砍掉。说实话，这招真的hen管用，不过请务必遵守Google Play政策，否则可Neng被审查封号~.
六、—别让 OOM Adj 成你的噩梦！ 
Amd啊，你kan完这些是不是感觉自己Yi经掌握了Android内部那套“抢占式内存管理”秘笈？其实只要记住几个关键词就够了：

•Toppest Priority → FOREGROUND_APP_ADJ / PROCESS_STATE_TOP — 永远不会轻易被杀 
•SERVICE 链路 → PERCEPTIBLE_*_ADJ — 绑定关系Neng提升优先级 
•CACHE → CACHED_MAX / CACHED_EMPTY — Zui容易挂掉 
•CYCLE 检测 → containsCycle — 防止无限递归 
•SCHED GROUP → TOP / DEFAULT / RESTRICTED — CPU资源也要配合调整 
\end{ul>

Ehh，我啰嗦了一大堆，你现在知道怎么kan日志、怎么调优，还Neng在代码里给自己的关键组件加上合适的标记，让它们稳稳地躲过LMK的大刀阔斧了吗？咱就是说有时候只要改动几行代码，就Neng让用户体验飞起~.
Dude，Ru果还有哪里卡住或者想深挖源码细节，随时来找我聊聊呗！哈哈，我这边还有好多奇怪bug和奇葩caseKe以一起拆解～.

© 2026 Android内部揭秘·友情分享
如需进一步学习，请自行搜索官方源码或社区讨论。