Android 7.0 ActivityManagerService(9) 进程管理相关流程分析(3) computeOomAdjLocked
栏目：综合技术时间：2017-02-24 11:18:42
这1篇博客，我们来分析1下AMS进程管理流程中，负责计算进程oom_adj值的computeOomAdjLocked函数。
从难度上来说，computeOomAdjLocked函数比updateOomAdjLocked函数简单，由于它的职责更明确和单1。
但是，由于Android定义的oom_adj种类庞杂，使得这个函数的分支很多，细节显得极为的繁琐。
因此从功利的角度来看，大家知道这个函数的用处和大概脉络便可。
不过对1个框架工程师而言，浏览源码的耐心可能比写代码的能力更重要，因此我们还是耐着性子将代码看完。
“RTFSC”，毕竟大神是这么告知我们的。
computeOomAdjLocked函数的代码很长，
因此在这篇博客中，我们还分段进行研究，然后试着进行总结。
1、computeOomAdjLocked Part-I
private final int computeOomAdjLocked(ProcessRecord app, int cachedAdj, ProcessRecord TOP_APP,
boolean doingAll, long now) { //之前的博客中提到过，updateOomAdjLocked函数每次更新oom_adj时，都会分配1个序号 //此处就是根据序号判断是不是已处理过命令 if (mAdjSeq == app.adjSeq) { // This adjustment has already been computed. return app.curRawAdj;
} //ProcessRecord对应的ActivityThread不存在了 //修改其中的1些变量，此时的oom_adj为CACHED_APP_MAX_ADJ， //其意义我们在前1篇博客中已提到过 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);
} //初始化1些变量 //这些变量的具体用处，在篇博客中我们不关注 //大家只用留意1下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部份。
从代码不难看出，这部份内容的主要目的是：
1、根据参数及进程的状态，决定是不是需要进行后续的计算；
2、初始化1些变量。
2、computeOomAdjLocked Part-II
在第2部份，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; //单独的1种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 { //其它进程，在后续进程中再进1步处理 // 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的第2部份，从这部份代码可以看出：
1、包括前台Activity的进程、运行测试类的进程、处理广播的进程及包括正在运行服务的进程，
其oom_adj均被赋值为FOREGROUND_APP_ADJ，即从LMK的角度来看，它们的重要性是1致的。
但这些进程的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，在后续流程中再作进1步处理。
3、computeOomAdjLocked Part-III
这1部份代码主要处理包括Activity，但是Activity不在前台的进程。
注意到这些进程包括之条件到的正在处理广播、服务或测试的进程，和oom_adj暂时为UNKNOW_ADJ的进程。
不过只有UNKNOW_ADJ对应的进程，才有可能进行实际的更新。
.................. // Examine all activities if not already foreground. if (!foregroundActivities && activitiesSize > 0) { //之前分析updateOomAdjLocked的第1部份时，简单提到过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有1定的差异，处在下层的oom_adj越大 //即越老的Activity所在进程，重要性越低 adj += minLayer;
}
}
} ..................
从上面的代码可以看出，computeOomAdjLocked的第3部份处理包括Activity的进程时，
进程终究的oom_adj将由其中最要的Activity决定。
即进程中存在可见Activity时，进程的oom_adj就为VISIBLE_APP_ADJ；
否则，若进程中存在处于PAUSING、PAUSED或STOPPING状态的Activity时，进程的oom_adj就为PERCEPTIBLE_APP_ADJ；
其余的进程还是UNKNOW_ADJ。
4、computeOomAdjLocked Part-IV
computeOomAdjLocked的第4部份主要用于处理1些特殊的进程。
............... 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;
}
} //前台进程之前的1个进程 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处理1个进程时，依照重要性由高到底的顺序，
逐渐判断该进程是不是满足对应的条件。
虽然计算1个进程的oom_adj时，会经过上述所有的判断，但当1个进程已满足重要性较高的条件时，
后续的判断实际上不会更改它已取得的oom_adj。
上面4部份的逻辑基本上以下图所示：
大图链接
后续的处理逻辑，依然满足上述规则。
只是在斟酌含有Service和Provider的进程时，整体流程显得极为复杂，
融入上图的本钱太高，因此就不再画图了。
5、computeOomAdjLocked Part-V
computeOomAdjLocked的第5部份，主要是处理包括服务的进程。
这1部份代码写的比较繁琐，复杂度应当超过了前4部份的和，
因此我们进1步分段说明。
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的方式进1步调剂。
固然，若Service仅为Unbounded Service或Bounded Service中的1种时，
computeOomAdjLocked函数的第5部份，只会依照1种方式调剂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); //客户端可以通过1个Connection以不同的参数绑定Service //因此，1个Service可以对应多个Connection，1个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基本1致，若进程显示过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) { //进1步更具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基本很少用到，
因此个人怀疑这些代码都是些实验性质的代码。手机真正运行时，使用的频率可能其实不高。
从另外一个角度来看，这么设计仿佛也是公道的。
当1个进程中的Service被许多客户端需求时，确切应当给这个进程机会，提高自己的重要性。
不知道如此细粒度的处理，Google是如何进行测试，并得到有效结论的？虽不明，但觉厉啊。
6、computeOomAdjLocked Part-VI
computeOomAdjLocked的第6部份主要是处理含有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 {
//根据c
------分隔线----------------------------
上一篇 java 场景总结（一）
下一篇 顺丰上市了，王卫身价直追马云
------分隔线----------------------------