Android 7.0 ActivityManagerService(9) 进程管理相关流程分析(3) computeOomAdjLocked

这一篇博客，我们来分析一下AMS进程管理流程中，负责计算进程oom_adj值的computeOomAdjLocked函数。

从难度上来讲，computeOomAdjLocked函数比updateOomAdjLocked函数简单，因为它的职责更明确和单一。
然而，由于Android定义的oom_adj种类庞杂，使得这个函数的分支很多，细节显得极其的繁琐。
因此从功利的角度来看，大家知道这个函数的用途和大概脉络即可。

不过对于一个框架工程师而言，阅读源码的耐心可能比写代码的能力更重要，因此我们还是耐着性子将代码看完。
“RTFSC”，毕竟大神是这么告诉我们的。

computeOomAdjLocked函数的代码很长，
因此在这篇博客中，我们还分段进行研究，然后试着进行总结。

一、computeOomAdjLocked Part-I

private final int computeOomAdjLocked(ProcessRecord app, int cachedAdj, ProcessRecord TOP_APP,
        boolean doingAll, long now) {
    //之前的博客中提到过，updateOomAdjLocked函数每次更新oom_adj时，都会分配一个序号
    //此处就是根据序号判断是否已经处理过命令
    if (mAdjSeq == app.adjSeq) {
        // This adjustment has already been computed.
        return app.curRawAdj;
    }

    //ProcessRecord对应的ActivityThread不存在了
    //修改其中的一些变量，此时的oom_adj为CACHED_APP_MAX_ADJ，
    //其意义我们在前一篇博客中已经提到过
    if (app.thread == null) {
        app.adjSeq = mAdjSeq;
        app.curSchedGroup = ProcessList.SCHED_GROUP_BACKGROUND;
        app.curProcState = ActivityManager.PROCESS_STATE_CACHED_EMPTY;
        return (app.curAdj=app.curRawAdj=ProcessList.CACHED_APP_MAX_ADJ);
    }

    //初始化一些变量
    //这些变量的具体用途，在篇博客中我们不关注
    //大家只用留意一下ProcessRecord的schedGroup、procState和oom_adj即可
    app.adjTypeCode = ActivityManager.RunningAppProcessInfo.REASON_UNKNOWN;
    app.adjSource = null;
    app.adjTarget = null;
    app.empty = false;
    app.cached = false;

    final int activitiesSize = app.activities.size();

    //这个判断没啥意义，ProcessRecord中只有初始化时为maxAdj赋值
    //maxAdj取值为UNKNOWN_ADJ，即最大的1001
    if (app.maxAdj <= ProcessList.FOREGROUND_APP_ADJ) {
        //这部分代码就是修改app的curSchedGroup，并将oom_adj设置为maxAdj
        //实际过程中，应该是不会执行的的
        ......................
    }

    //保存当前TOP Activity的状态
    final int PROCESS_STATE_CUR_TOP = mTopProcessState;
    ......................
}

以上代码就是computeOomAdjLocked函数的第一部分。
从代码不难看出，这部分内容的主要目的是：
1、根据参数及进程的状态，决定是否需要进行后续的计算；
2、初始化一些变量。

二、computeOomAdjLocked Part-II
在第二部分，computeOomAdjLocked开始干“正事儿”了：

.................
// Determine the importance of the process, starting with most
// important to least, and assign an appropriate OOM adjustment.
// 上面的这段注释为整个computeOomAdjLocked函数“代言”

int adj;
int schedGroup;
int procState;
boolean foregroundActivities = false;
BroadcastQueue queue;

//若进程包含正在前台显示的Activity
if (app == TOP_APP) {
    // The last app on the list is the foreground app.
    adj = ProcessList.FOREGROUND_APP_ADJ;

    //单独的一种schedGroup
    schedGroup = ProcessList.SCHED_GROUP_TOP_APP;
    app.adjType = "top-activity";

    //当前处理的是包含前台Activity的进程时，才会将该值置为true
    foregroundActivities = true;
    procState = PROCESS_STATE_CUR_TOP;
} else if (app.instrumentationClass != null) {
    //处理正在进行测试的进程

    // Don't want to kill running instrumentation.
    adj = ProcessList.FOREGROUND_APP_ADJ;
    schedGroup = ProcessList.SCHED_GROUP_DEFAULT;

    app.adjType = "instrumentation";
    procState = ActivityManager.PROCESS_STATE_FOREGROUND_SERVICE;
} else if ((queue = isReceivingBroadcast(app)) != null) {
    //处理正在处理广播的进程

    // An app that is currently receiving a broadcast also
    // counts as being in the foreground for OOM killer purposes.
    // It's placed in a sched group based on the nature of the
    // broadcast as reflected by which queue it's active in.
    adj = ProcessList.FOREGROUND_APP_ADJ;

    //根据处理广播的Queue，决定调度策略
    schedGroup = (queue == mFgBroadcastQueue)
            ? ProcessList.SCHED_GROUP_DEFAULT : ProcessList.SCHED_GROUP_BACKGROUND;

    app.adjType = "broadcast";
    procState = ActivityManager.PROCESS_STATE_RECEIVER;
} else if (app.executingServices.size() > 0) {
    //处理Service正在运行的进程

    // An app that is currently executing a service callback also
    // counts as being in the foreground.
    adj = ProcessList.FOREGROUND_APP_ADJ;

    schedGroup = app.execServicesFg ?
            ProcessList.SCHED_GROUP_DEFAULT : ProcessList.SCHED_GROUP_BACKGROUND;

    procState = ActivityManager.PROCESS_STATE_SERVICE;
} else {
    //其它进程，在后续过程中再进一步处理
    // As far as we know the process is empty.  We may change our mind later.
    schedGroup = ProcessList.SCHED_GROUP_BACKGROUND;

    // At this point we don't actually know the adjustment.  Use the cached adj
    // value that the caller wants us to.
    // 先将adj临时赋值为cachedAdj，即参数传入的UNKNOW_ADJ
    adj = cachedAdj;
    procState = ActivityManager.PROCESS_STATE_CACHED_EMPTY;

    app.cached = true;
    app.empty = true;
    app.adjType = "cch-empty";
}
..................

以上代码可以看作是computeOomAdjLocked的第二部分，从这部分代码可以看出：
1、包含前台Activity的进程、运行测试类的进程、处理广播的进程及包含正在运行服务的进程，
其oom_adj均被赋值为FOREGROUND_APP_ADJ，即从LMK的角度来看，它们的重要性是一致的。
但这些进程的procState不同，于是从AMS主动回收内存的角度来看，它们的重要性不同。

此外，这些进程的schedGroup不同。
之前的博客分析过，Process.java中提供了接口，可以调用Linux提供的接口函数设置schedGroup，使得进程具有不同的调度策略。
从获取CPU资源的能力来看，SCHED_GROUP_TOP_APP应该强于SCHED_GROUP_DEFAULT，
最后才轮到SCHED_GROUP_BACKGROUND。

2、对于其它种类的进程，这部分代码先将它们的oom_adj设置为UNKNOW_ADJ，
proc_state置为PROCESS_STATE_CACHED_EMPTY，在后续流程中再作进一步处理。

三、computeOomAdjLocked Part-III
这一部分代码主要处理包含Activity，但是Activity不在前台的进程。

注意到这些进程包括之前提到的正在处理广播、服务或测试的进程，以及oom_adj暂时为UNKNOW_ADJ的进程。
不过只有UNKNOW_ADJ对应的进程，才有可能进行实际的更新。

..................
// Examine all activities if not already foreground.
if (!foregroundActivities && activitiesSize > 0) {
    //之前分析updateOomAdjLocked的第一部分时，简单提到过rankTaskLayersIfNeeded函数
    //该函数会更新包含Activity的Task的rankLayer
    //按照显示层次从上到下，rankLayer逐渐增加，对应的最大值就是VISIBLE_APP_LAYER_MAX
    int minLayer = ProcessList.VISIBLE_APP_LAYER_MAX;

    //依次轮询进程中的Activity
    for (int j = 0; j < activitiesSize; j++) {
        final ActivityRecord r = app.activities.get(j);
        ...................
        //如果进程包含可见Activity，即该进程是个可见进程
        if (r.visible) {
            // App has a visible activity; only upgrade adjustment.
            if (adj > ProcessList.VISIBLE_APP_ADJ) {
                //adj大于VISIBLE_APP_ADJ时，才更新对应的adj
                //之前提到的正在处理广播、服务或测试的进程，adj为FOREGROUND，是小于VISIBLE_APP_ADJ
                //因此不会在此更新
                adj = ProcessList.VISIBLE_APP_ADJ;
                app.adjType = "visible";
            }

            if (procState > PROCESS_STATE_CUR_TOP) {
                //与oom_adj类似，在条件满足时，更新procState
                procState = PROCESS_STATE_CUR_TOP;
            }

            //正在处理广播、服务或测试的进程，如果它们的调度策略为BACKGROUND
            //但又包含了可见Activity时，调度策略变更为DEFAULT
            schedGroup = ProcessList.SCHED_GROUP_DEFAULT;

            app.cached = false;
            app.empty = false;
            foregroundActivities = true;

            if (r.task != null && minLayer > 0) {
                 final int layer = r.task.mLayerRank;
                 if (layer >= 0 && minLayer > layer) {
                     //更新ranklayer
                     minLayer = layer;
                 }
            }

            //发现可见Activity时，直接可以结束循环
            break;
        } else if (r.state == ActivityState.PAUSING || r.state == ActivityState.PAUSED) {
            //如果进程包含处于PAUSING或PAUSED状态的Activity时

            //将其oom_adj调整为“用户可察觉”的的等级，这个等级还是很高的
            if (adj > ProcessList.PERCEPTIBLE_APP_ADJ) {
                adj = ProcessList.PERCEPTIBLE_APP_ADJ;
                app.adjType = "pausing";
            }
            if (procState > PROCESS_STATE_CUR_TOP) {
                procState = PROCESS_STATE_CUR_TOP;
            }
            schedGroup = ProcessList.SCHED_GROUP_DEFAULT;
            app.cached = false;
            app.empty = false;
            foregroundActivities = true;

            //注意并不会break
        } else if (r.state == ActivityState.STOPPING) {
            //包含处于Stopping状态Activity的进程，其oom_adj也被置为PERCEPTIBLE_APP_ADJ

            if (adj > ProcessList.PERCEPTIBLE_APP_ADJ) {
                adj = ProcessList.PERCEPTIBLE_APP_ADJ;
                app.adjType = "stopping";
            }
            ................
            // 这种进程将被看作潜在的cached或empty进程
            if (!r.finishing) {
                if (procState > ActivityManager.PROCESS_STATE_LAST_ACTIVITY) {
                    procState = ActivityManager.PROCESS_STATE_LAST_ACTIVITY;
                }
            }
            app.cached = false;
            app.empty = false;
            foregroundActivities = true;
        } else {
            //只是含有cached-activity的进程，仅调整procState
            if (procState > ActivityManager.PROCESS_STATE_CACHED_ACTIVITY) {
                procState = ActivityManager.PROCESS_STATE_CACHED_ACTIVITY;
                app.adjType = "cch-act";
            }
        }

        if (adj == ProcessList.VISIBLE_APP_ADJ) {
            //不同可见进程的oom_adj有一定的差异，处在下层的oom_adj越大
            //即越老的Activity所在进程，重要性越低
            adj += minLayer;
        }
    }
}
..................

从上面的代码可以看出，computeOomAdjLocked的第三部分处理包含Activity的进程时，
进程最终的oom_adj将由其中最要的Activity决定。
即进程中存在可见Activity时，进程的oom_adj就为VISIBLE_APP_ADJ；
否则，若进程中存在处于PAUSING、PAUSED或STOPPING状态的Activity时，进程的oom_adj就为PERCEPTIBLE_APP_ADJ；
其余的进程仍是UNKNOW_ADJ。

四、computeOomAdjLocked Part-IV
computeOomAdjLocked的第四部分主要用于处理一些特殊的进程。

...............
if (adj > ProcessList.PERCEPTIBLE_APP_ADJ
        || procState > ActivityManager.PROCESS_STATE_FOREGROUND_SERVICE) {
    //进程包含前台服务或被强制在前台运行时
    //oom_adj被调整为PERCEPTIBLE_APP_ADJ，只是procState略有不同
    if (app.foregroundServices) {
        // The user is aware of this app, so make it visible.
        adj = ProcessList.PERCEPTIBLE_APP_ADJ;
        procState = ActivityManager.PROCESS_STATE_FOREGROUND_SERVICE;
        app.cached = false;
        app.adjType = "fg-service";
        schedGroup = ProcessList.SCHED_GROUP_DEFAULT;
    } else if (app.forcingToForeground != null) {
        // The user is aware of this app, so make it visible.
        adj = ProcessList.PERCEPTIBLE_APP_ADJ;
        procState = ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND;
        app.cached = false;
        app.adjType = "force-fg";
        app.adjSource = app.forcingToForeground;
        schedGroup = ProcessList.SCHED_GROUP_DEFAULT;
    }
}

//AMS的HeavyWeight进程单独处理
if (app == mHeavyWeightProcess) {
    if (adj > ProcessList.HEAVY_WEIGHT_APP_ADJ) {
        // We don't want to kill the current heavy-weight process.
        adj = ProcessList.HEAVY_WEIGHT_APP_ADJ;
        schedGroup = ProcessList.SCHED_GROUP_BACKGROUND;

        app.cached = false;
        app.adjType = "heavy";
    }

    if (procState > ActivityManager.PROCESS_STATE_HEAVY_WEIGHT) {
        procState = ActivityManager.PROCESS_STATE_HEAVY_WEIGHT;
    }
}

//home进程特殊处理
if (app == mHomeProcess) {
    if (adj > ProcessList.HOME_APP_ADJ) {
        // This process is hosting what we currently consider to be the
        // home app, so we don't want to let it go into the background.
        adj = ProcessList.HOME_APP_ADJ;
        schedGroup = ProcessList.SCHED_GROUP_BACKGROUND;

        app.cached = false;
        app.adjType = "home";
    }
    if (procState > ActivityManager.PROCESS_STATE_HOME) {
        procState = ActivityManager.PROCESS_STATE_HOME;
    }
}

//前台进程之前的一个进程
if (app == mPreviousProcess && app.activities.size() > 0) {
    if (adj > ProcessList.PREVIOUS_APP_ADJ) {
        // This was the previous process that showed UI to the user.
        // We want to try to keep it around more aggressively, to give
        // a good experience around switching between two apps.
        adj = ProcessList.PREVIOUS_APP_ADJ;
        schedGroup = ProcessList.SCHED_GROUP_BACKGROUND;
        app.cached = false;
        app.adjType = "previous";
    }
    if (procState > ActivityManager.PROCESS_STATE_LAST_ACTIVITY) {
        procState = ActivityManager.PROCESS_STATE_LAST_ACTIVITY;
    }
}

// By default, we use the computed adjustment.  It may be changed if
// there are applications dependent on our services or providers, but
// this gives us a baseline and makes sure we don't get into an
// infinite recursion.
app.adjSeq = mAdjSeq;
app.curRawAdj = adj;
app.hasStartedServices = false;

//处理正在进行backup工作的进程
if (mBackupTarget != null && app == mBackupTarget.app) {
    // If possible we want to avoid killing apps while they're being backed up
    if (adj > ProcessList.BACKUP_APP_ADJ) {
        ..............
        adj = ProcessList.BACKUP_APP_ADJ;
        if (procState > ActivityManager.PROCESS_STATE_IMPORTANT_BACKGROUND) {
            procState = ActivityManager.PROCESS_STATE_IMPORTANT_BACKGROUND;
        }
        app.adjType = "backup";
        app.cached = false;
    }
    if (procState > ActivityManager.PROCESS_STATE_BACKUP) {
        procState = ActivityManager.PROCESS_STATE_BACKUP;
    }
}
..................

至此，我们应该可以看出computeOomAdjLocked处理一个进程时，按照重要性由高到底的顺序，
逐步判断该进程是否满足对应的条件。
尽管计算一个进程的oom_adj时，会经过上述所有的判断，但当一个进程已经满足重要性较高的条件时，
后续的判断实际上不会更改它已经获得的oom_adj。

上面四部分的逻辑基本上如下图所示：

大图链接

后续的处理逻辑，仍然满足上述规则。
只是在考虑含有Service和Provider的进程时，整体流程显得极其复杂，
融入上图的成本太高，因此就不再画图了。

五、computeOomAdjLocked Part-V
computeOomAdjLocked的第五部分，主要是处理包含服务的进程。
这一部分代码写的比较繁琐，复杂度应该超过了前四部分的和，
因此我们进一步分段说明。

1、Unbounded Service的处理
当进程中包含Unbounded Service时，进程的oom_adj先按照Unbounded Service的处理方式进行调整。

.................
//依次处理进程中的每一个Service
for (int is = app.services.size()-1;
    is >= 0 && (adj > ProcessList.FOREGROUND_APP_ADJ
            || schedGroup == ProcessList.SCHED_GROUP_BACKGROUND
            || procState > ActivityManager.PROCESS_STATE_TOP);
    is--) {
    ServiceRecord s = app.services.valueAt(is);

    //Service被已Unbounded Service的方式启动过
    if (s.startRequested) {
        app.hasStartedServices = true;

        //调整procState
        if (procState > ActivityManager.PROCESS_STATE_SERVICE) {
            procState = ActivityManager.PROCESS_STATE_SERVICE;
        }

        if (app.hasShownUi && app != mHomeProcess) {
            // If this process has shown some UI, let it immediately
            // go to the LRU list because it may be pretty heavy with
            // UI stuff.  We'll tag it with a label just to help
            // debug and understand what is going on.
            // 仅有含有服务且显示过UI的进程，由于其占用内存可能较多，因此需要尽早回收
            // 故此处不调整其oom_adj
            if (adj > ProcessList.SERVICE_ADJ) {
                app.adjType = "cch-started-ui-services";
            }
        } else {
            if (now < (s.lastActivity + ActiveServices.MAX_SERVICE_INACTIVITY)) {
                //MAX_SERVICE_INACTIVITY为activity启动service后，系统最多保留Service的时间

                // This service has seen some activity within
                // recent memory, so we will keep its process ahead
                // of the background processes.

                //此时进程的oom_adj就可以被调整为后台服务对应的SERVICE_ADJ
                //adj大于500的进程均会受此判断的影响
                if (adj > ProcessList.SERVICE_ADJ) {
                    adj = ProcessList.SERVICE_ADJ;
                    app.adjType = "started-services";
                    app.cached = false;
                }
            }

            //处理Service存在超时的情况，可见超时时也不会调整oom_adj
            // If we have let the service slide into the background
            // state, still have some text describing what it is doing
            // even though the service no longer has an impact.
            if (adj > ProcessList.SERVICE_ADJ) {
                app.adjType = "cch-started-services";
            }
        }
    }
.................

从上面的代码可以看出，当进程中含有Unbounded Service时，
如果进程之前没有启动过UI，且Unbounded Service存活的时间没有超时，
进程的oom_ad才能被调整为SERVICE_ADJ；否则进程的oom_adj仍然是UNKNOW_ADJ或其它大于500的值。

2、Bounded Service的处理
这部分代码紧接着上述流程。
即进程将先按照Unbounded Service的方式调整oom_adj，
然后再按照Bounded Service的方式进一步调整。

当然，若Service仅为Unbounded Service或Bounded Service中的一种时，
computeOomAdjLocked函数的第五部分，只会按照一种方式调整oom_adj。

Bounded Service的处理方式，远比Unbounded Service复杂，依赖于客户端的oom_adj和绑定服务时使用的flag。

....................
    //如果该Service还被客户端Bounded，即是Bounded Service时
    for (int conni = s.connections.size()-1;
            conni >= 0 && (adj > ProcessList.FOREGROUND_APP_ADJ
                    || schedGroup == ProcessList.SCHED_GROUP_BACKGROUND
                    || procState > ActivityManager.PROCESS_STATE_TOP);
            conni--) {
        ArrayList<ConnectionRecord> clist = s.connections.valueAt(conni);

        //客户端可以通过一个Connection以不同的参数绑定Service
        //因此，一个Service可以对应多个Connection，一个Connection又对应多个ConnectionRecord
        //这里依次处理每一个ConnectionRecord
        for (int i = 0;
                i < clist.size() && (adj > ProcessList.FOREGROUND_APP_ADJ
                        || schedGroup == ProcessList.SCHED_GROUP_BACKGROUND
                        || procState > ActivityManager.PROCESS_STATE_TOP);
                i++) {
            ConnectionRecord cr = clist.get(i);

            if (cr.binding.client == app) {
                // Binding to ourself is not interesting.
                continue;
            }

            //当BIND_WAIVE_PRIORITY为1时，客户端就不会影响服务端
            //if中的流程就可以略去；否则，客户端就会影响服务端
            if ((cr.flags&Context.BIND_WAIVE_PRIORITY) == 0) {
                ProcessRecord client = cr.binding.client;

                //计算出客户端进程的oom_adj
                //由此可看出Android oom_adj的计算多么麻烦
                //要是客户端进程中，又有个服务进程被绑定，那么将再计算其客户端进程的oom_adj？！
                int clientAdj = computeOomAdjLocked(client, cachedAdj,
                        TOP_APP, doingAll, now);

                int clientProcState = client.curProcState;
                if (clientProcState >= ActivityManager.PROCESS_STATE_CACHED_ACTIVITY) {
                    // If the other app is cached for any reason, for purposes here
                    // we are going to consider it empty.  The specific cached state
                    // doesn't propagate except under certain conditions.
                    clientProcState = ActivityManager.PROCESS_STATE_CACHED_EMPTY;
                }

                String adjType = null;

                //BIND_ALLOW_OOM_MANAGEMENT置为1时，先按照通常的处理方式，调整服务端进程的adjType
                if ((cr.flags&Context.BIND_ALLOW_OOM_MANAGEMENT) != 0) {
                    //与前面分析Unbounded Service基本一致，若进程显示过UI或Service超时
                    //会将clientAdj修改为当前进程的adj，即不需要考虑客户端进程了
                    if (app.hasShownUi && app != mHomeProcess) {
                        if (adj > clientAdj) {
                            adjType = "cch-bound-ui-services";
                        }
                        app.cached = false;
                        clientAdj = adj;
                        clientProcState = procState;
                    } else {
                        if (now >= (s.lastActivity
                                + ActiveServices.MAX_SERVICE_INACTIVITY)) {
                            if (adj > clientAdj) {
                                adjType = "cch-bound-services";
                            }
                            clientAdj = adj;
                        }
                    }
                }

                //根据情况，按照clientAdj调整当前进程的adj
                if (adj > clientAdj) {
                    // If this process has recently shown UI, and
                    // the process that is binding to it is less
                    // important than being visible, then we don't
                    // care about the binding as much as we care
                    // about letting this process get into the LRU
                    // list to be killed and restarted if needed for
                    // memory.
                    // 上面的注释很清楚
                    if (app.hasShownUi && app != mHomeProcess
                            && clientAdj > ProcessList.PERCEPTIBLE_APP_ADJ) {
                        adjType = "cch-bound-ui-services";
                    } else {
                        //以下的流程表明，client和flag将同时影响Service进程的adj

                        if ((cr.flags&(Context.BIND_ABOVE_CLIENT
                                |Context.BIND_IMPORTANT)) != 0) {
                            //从这里再次可以看出，Service重要性小于等于Client
                            adj = clientAdj >= ProcessList.PERSISTENT_SERVICE_ADJ
                                    ? clientAdj : ProcessList.PERSISTENT_SERVICE_ADJ;

                        //BIND_NOT_VISIBLE表示不将服务端当作visible进程看待
                        //于是，即使客户端的adj小于PERCEPTIBLE_APP_ADJ，service也只能取到PERCEPTIBLE_APP_ADJ
                        } else if ((cr.flags&Context.BIND_NOT_VISIBLE) != 0
                                && clientAdj < ProcessList.PERCEPTIBLE_APP_ADJ
                                && adj > ProcessList.PERCEPTIBLE_APP_ADJ) {
                            adj = ProcessList.PERCEPTIBLE_APP_ADJ;
                        } else if (clientAdj >= ProcessList.PERCEPTIBLE_APP_ADJ) {
                            adj = clientAdj;
                        } else {
                            if (adj > ProcessList.VISIBLE_APP_ADJ) {
                                adj = Math.max(clientAdj, ProcessList.VISIBLE_APP_ADJ);
                            }
                        }

                        if (!client.cached) {
                            app.cached = false;
                        }
                        adjType = "service";
                    }
                }

                if ((cr.flags&Context.BIND_NOT_FOREGROUND) == 0) {
                    //进一步更具client调整当前进程的procState、schedGroup等
                    ...................
                } else {
                    ...................
                }
                .................
                if (procState > clientProcState) {
                    procState = clientProcState;
                }
                //其它参数的赋值
                .................
            } 

            if ((cr.flags&Context.BIND_TREAT_LIKE_ACTIVITY) != 0) {
                app.treatLikeActivity = true;
            }

            //取出ConnectionRecord所在的Activity
            final ActivityRecord a = cr.activity;

            //BIND_ADJUST_WITH_ACTIVITY值为1时，表示服务端可以根据客户端Activity的oom_adj作出相应的调整
            if ((cr.flags&Context.BIND_ADJUST_WITH_ACTIVITY) != 0) {
                if (a != null && adj > ProcessList.FOREGROUND_APP_ADJ &&
                        (a.visible || a.state == ActivityState.RESUMED ||
                                a.state == ActivityState.PAUSING)) {
                //BIND_ADJUST_WITH_ACTIVITY置为1，且绑定的activity可见或在前台时，
                //Service进程的oom_adj可以变为FOREGROUND_APP_ADJ
                adj = ProcessList.FOREGROUND_APP_ADJ;

                //BIND_NOT_FOREGROUND为0时，才准许调整Service进程的调度优先级
                if ((cr.flags&Context.BIND_NOT_FOREGROUND) == 0) {
                    if ((cr.flags&Context.BIND_IMPORTANT) != 0) {
                        schedGroup = ProcessList.SCHED_GROUP_TOP_APP;
                    } else {
                        schedGroup = ProcessList.SCHED_GROUP_DEFAULT;
                    }
                }

                //改变其它参数
                app.cached = false;
                app.adjType = "service";
                app.adjTypeCode = ActivityManager.RunningAppProcessInfo
                        .REASON_SERVICE_IN_USE;
                app.adjSource = a;
                app.adjSourceProcState = procState;
                app.adjTarget = s.name;
            }
        }
    }
}
....................

以上就是计算含有Service的进程的oom_adj的全部过程。
从代码来看当进程仅含有Unbounded Service时，整个计算过程比较单纯，只要进程没有显示过UI，且Service的存在没有超时时，
进程的oom_adj就被调整为SERVICE_ADJ。
当进程含有的是Bounded Service时，整个计算的复杂度就飙升了，
它将考虑到Bound时使用的flag及客户端的情况，综合调整进程的oom_adj。

不过正因为Bounded Service的处理流程依赖于大量的flag，而这些flag基本很少用到，
因此个人怀疑这些代码都是些实验性质的代码。手机真正运行时，使用的频率可能并不高。

从另一个角度来看，这么设计似乎也是合理的。
当一个进程中的Service被许多客户端需求时，确实应该给这个进程机会，提高自己的重要性。
不知道如此细粒度的处理，Google是如何进行测试，并得到有效结论的？虽不明，但觉厉啊。

六、computeOomAdjLocked Part-VI
computeOomAdjLocked的第六部分主要是处理含有ContentProvider的进程。
由于ContentProvider也有客户端，因此同样需要根据客户端进程调整当前进程的oom_adj。

....................
//依次处理进程中的ContentProvider
for (int provi = app.pubProviders.size()-1;
                provi >= 0 && (adj > ProcessList.FOREGROUND_APP_ADJ
                        || schedGroup == ProcessList.SCHED_GROUP_BACKGROUND
                        || procState > ActivityManager.PROCESS_STATE_TOP);
                provi--) {
    ContentProviderRecord cpr = app.pubProviders.valueAt(provi);

    //依次处理ContentProvider的客户端
    for (int i = cpr.connections.size()-1;
            i >= 0 && (adj > ProcessList.FOREGROUND_APP_ADJ
                    || schedGroup == ProcessList.SCHED_GROUP_BACKGROUND
                    || procState > ActivityManager.PROCESS_STATE_TOP);
            i--) {
        ContentProviderConnection conn = cpr.connections.get(i);

        ProcessRecord client = conn.client;
        if (client == app) {
            // Being our own client is not interesting.
            continue;
        }

        //计算客户端的oom_adj
        int clientAdj = computeOomAdjLocked(client, cachedAdj, TOP_APP, doingAll, now);
        int clientProcState = client.curProcState;
        if (clientProcState >= ActivityManager.PROCESS_STATE_CACHED_ACTIVITY) {
            // If the other app is cached for any reason, for purposes here
            // we are going to consider it empty.
            clientProcState = ActivityManager.PROCESS_STATE_CACHED_EMPTY;
        }

        //与Unbounded Service的处理基本类似
        if (adj > clientAdj) {
            if (app.hasShownUi && app != mHomeProcess
                    && clientAdj > ProcessList.PERCEPTIBLE_APP_ADJ) {
                app.adjType = "cch-ui-provider";
            } else {
                //根据clientAdj，调整当前进程的adj
                adj = clientAdj > ProcessList.FOREGROUND_APP_ADJ
                        ? clientAdj : ProcessList.FOREGROUND_APP_ADJ;
                        app.adjType = "provider";
            }

            //调整其它变量
            app.cached &= client.cached;
            app.adjTypeCode = ActivityManager.RunningAppProcessInfo
                    .REASON_PROVIDER_IN_USE;
            app.adjSource = client;
            app.adjSourceProcState = clientProcState;
            app.adjTarget = cpr.name;
        }

        //进一步调整调度策略和procState
        ....................

        //特殊情况的处理
        // If the provider has external (non-framework) process
        // dependencies, ensure that its adjustment is at least
        // FOREGROUND_APP_ADJ.
        if (cpr.hasExternalProcessHandles()) {
            if (adj > ProcessList.FOREGROUND_APP_ADJ) {
                adj = ProcessList.FOREGROUND_APP_ADJ;
                schedGroup = ProcessList.SCHED_GROUP_DEFAULT;
                app.cached = false;
                app.adjType = "provider";
                app.adjTarget = cpr.name;
            }
            if (procState > ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND) {
                procState = ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND;
            }
        }
    }
}

//如果进程之前运行过ContentProvider，同时ContentProvider的存活时间没有超时
//那么进程的adj可以变为PREVIOUS_APP_ADJ
if (app.lastProviderTime > 0 && (app.lastProviderTime+CONTENT_PROVIDER_RETAIN_TIME) > now) {
    if (adj > ProcessList.PREVIOUS_APP_ADJ) {
        adj = ProcessList.PREVIOUS_APP_ADJ;
        schedGroup = ProcessList.SCHED_GROUP_BACKGROUND;

        app.cached = false;
        app.adjType = "provider";
    }
    if (procState > ActivityManager.PROCESS_STATE_LAST_ACTIVITY) {
        procState = ActivityManager.PROCESS_STATE_LAST_ACTIVITY;
    }
}
....................

从代码来看，处理含有ContentProvider的进程时，相对比较简单。
基本上与处理含有Unbounded Service的进程一致，只是最后增加了一些特殊情况的处理。

七、computeOomAdjLocked Part-VII
现在我们来看看computeOomAdjLocked函数的最后一部分。

//根据进程信息，进一步调整procState
...................

//对Service进程做一些特殊处理
if (adj == ProcessList.SERVICE_ADJ) {
    if (doingAll) {
        //每次updateOomAdj时，将mNewNumAServiceProcs置为0
        //然后LRU list中，从后往前数，前1/3的service进程就是AService
        //其余的就是bService
        //mNumServiceProcs为上一次update时，service进程的数量
        app.serviceb = mNewNumAServiceProcs > (mNumServiceProcs/3);

        //记录这一次update后，service进程的数量
        //update完毕后，该值将赋给mNumServiceProcs
        mNewNumServiceProcs++;
        .............
        if (!app.serviceb) {
            // This service isn't far enough down on the LRU list to
            // normally be a B service, but if we are low on RAM and it
            // is large we want to force it down since we would prefer to
            // keep launcher over it.
            // 如果不是bService，但内存回收等级过高，也被视为bService
            if (mLastMemoryLevel > ProcessStats.ADJ_MEM_FACTOR_NORMAL
                    && app.lastPss >= mProcessList.getCachedRestoreThresholdKb()) {
                app.serviceHighRam = true;
                app.serviceb = true;
                ................
            } else {
                //LRU中后1/3的Service，都是AService
                mNewNumAServiceProcs++;
                ............
            }
        } else {
            app.serviceHighRam = false;
        }
    }
    //将bService的oom_adj调整为SERVICE_B_ADJ
    if (app.serviceb) {
        adj = ProcessList.SERVICE_B_ADJ;
    }
}

//计算完毕
app.curRawAdj = adj;

.............
//if基本没有用，maxAdj已经是最大的UNKNOW_ADJ
if (adj > app.maxAdj) {
    adj = app.maxAdj;
    if (app.maxAdj <= ProcessList.PERCEPTIBLE_APP_ADJ) {
        schedGroup = ProcessList.SCHED_GROUP_DEFAULT;
    }
}

//最后做一些记录和调整
.............

return app.curRawAdj;

从上面的代码可以看出，computeOomAdjLocked 的最后一部分主要是针对Service进程作一些处理。
LRU表从后往前，比较重要的Service进程是AService，不太重要的就是bService。

同时，判断的依据与前一次记录的Service进程总数有关。
即若前一次Service进程数量大，本次Service进程数变少了，那么本次AService的比例将变大；
同样若前一次Service进程数量小，本次Service进程数量变多了，那么本次BService的比例将变大。
这也算是一种动态自适应吧。

八、总结
computeOomAdjLocked函数基本上就介绍到这里了。
其实该函数的原理还是依据进程中运行的组件以及进程的种类，来计算相应的oom_adj。
基本过程还是比较容易看懂，就是处理Bounded Service时，需要同时考虑客户端和绑定时使用的flag，
使得整个代码显得很繁琐。