Android中的AMS的职责是比较多的，其中一个比较重要的职责就是app进程的管理，比如我们调用startActivity方法启动一个activity的时候，可能对应的那个进程没有启动，因此需要启动那个进程，而且对于这个进程还要有一些必要的管理过程，比如将它放到LRU（least recently used）列表中去等。本文就AMS的进程管理基本逻辑和过程做一个简要的分析，以帮助大家弄清楚AMS的进程管理。
Android的应用进程是什么？
这里我们讲的是android的应用进程，并不是native层的进程，这里需要知道。在android中，进程（Process）的概念是被弱化的，我们知道在传统的系统中进程是静态程序执行的载体，程序的代码段，数据等信息全部都是在进程的管理之中的，而且进程中的多个组件都是在一个进程中的，并且他们的生命周期都是和进程息息相关的。但是在android中，进程只不过是一系列运行组件的容器而已，这些组件可以运行在不同的进程之中，也就是说某个app中的某个组件可以运行在本地进程之中，也可以运行在另外一个进程中；说白了，也就是说android的app中的组件只是一个静态的程序级别的概念，真正运行的时候这些组件可能“各立山头”，互补相关；要做到这一点也很容易，只要在AndroidManifest中的相应组件指定android:process属性就可以了。同时，不同的app中的不同组件也可以运行在一个进程中，可以通过在AndroidManifest指定相应的进程名称就可以了。
虽然在android的开发中，不再强调进程的概念，但是进程毕竟是实际存在于android系统中，只是它和我们认识到的传统进程不太一样，所以我们的AMS还是需要对进程进行管理的。AMS对于进程的管理主要体现在两个方面：第一是动态调整进程再mLruProcess中的位置，第二就是调整进程的oom_adj的值，这两项都和系统的内存自动回收有关系，当系统的内存不足时，系统主要根据oom_adj的值来选择杀死一些进程以释放内存，这个值越大表示进程越容易被杀死。
AMS启动进程流程
在Android ActivityManagerService（AMS）的启动分析一文中我们提到了AMS是调用addAppLocked方法来启动一个进程的，这个方法实现如下：
final ProcessRecord addAppLocked(ApplicationInfo info, boolean isolated,
String abiOverride) {
ProcessRecord app;
// isolated表示当前需要启动的app是不是一个独立的进程，如果是独立的话那就重新
// 创建一个ProcessRecord，如果不是的话那就从正在运行的进程列表中找。
if (!isolated) {
app = getProcessRecordLocked(info.processName, info.uid, true);
} else {
app = null;
}
// 这是一个独立的进程或者在正在运行的列表中没有找到相应的记录
if (app == null) {
// 新建一个ProcessRecord对象
app = newProcessRecordLocked(info, null, isolated, 0);
// 更新lru列表和oom_adj值，下面我们会重点分析这里
updateLruProcessLocked(app, false, null);
updateOomAdjLocked();
}
// This package really, really can not be stopped.
// 这里将当前的app包设置为启动状态，这样这个app就可以接受系统的隐式intent了
try {
AppGlobals.getPackageManager().setPackageStoppedState(
info.packageName, false, UserHandle.getUserId(app.uid));
} catch (RemoteException e) {
} catch (IllegalArgumentException e) {
Slog.w(TAG, "Failed trying to unstop package "
+ info.packageName + ": " + e);
}
// 如果app中带有persistent标记的话，那个对新建的app对象做相应的标记
if ((info.flags & PERSISTENT_MASK) == PERSISTENT_MASK) {
app.persistent = true;
// 这个值下面我们分析oom_adj中会说明
app.maxAdj = ProcessList.PERSISTENT_PROC_ADJ;
}
// 如果app中的thread（就是主线程）为空的话
if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) {
mPersistentStartingProcesses.add(app);
// 实际启动app进程
startProcessLocked(app, "added application", app.processName, abiOverride,
null /* entryPoint */, null /* entryPointArgs */);
}
return app;
}addAppLocked方法会根据参数isolated来决定这个进程是不是一个独立的进程，如果是那就创建一个新的ProcessRecord对象，如果不是的话，那就调用getProcessRecordLocked方法在当前运行的进程列表中查找进程，我们看下这个方法的定义：
getProcessRecordLocked@ActivityManagerService.java
final ProcessRecord getProcessRecordLocked(String processName, int uid, boolean keepIfLarge) {
// 如果是一个系统级别的UID，也就是说这个app是由于system用户启动的进程
if (uid == Process.SYSTEM_UID) {
// The system gets to run in any process. If there are multiple
// processes with the same uid, just pick the first (this
// should never happen).
// 上面英文注释说的很明白，如果有多个system uid的进程的话，那就取第一个
SparseArray<ProcessRecord> procs = mProcessNames.getMap().get(processName);
if (procs == null) return null;
final int procCount = procs.size();
for (int i = 0; i < procCount; i++) {
final int procUid = procs.keyAt(i);
// 如果这是一个合理的app进程，或者uid不是要求的uid的话，那就跳过。
// 原因下面的英文注释说的很清楚。
if (UserHandle.isApp(procUid) || !UserHandle.isSameUser(procUid, uid)) {
// Don't use an app process or different user process for system component.
continue;
}
return procs.valueAt(i);
}
}
// 如果不是系统uid的话，就会执行到这里。首先从mProcessNames查找正在运行的进程记录
ProcessRecord proc = mProcessNames.get(processName, uid);
// 上面这个分支永远不会执行，这是一个用户测试的分支。
if (false && proc != null && !keepIfLarge
&& proc.setProcState >= ActivityManager.PROCESS_STATE_CACHED_EMPTY
&& proc.lastCachedPss >= 4000) {
// Turn this condition on to cause killing to happen regularly, for testing.
if (proc.baseProcessTracker != null) {
proc.baseProcessTracker.reportCachedKill(proc.pkgList, proc.lastCachedPss);
}
proc.kill(Long.toString(proc.lastCachedPss) + "k from cached", true);
// 一般会走这个分支，但是由于我们的addAppLocked传递进来的keepIfLarge是true，因此这个分支也不会走。
} else if (proc != null && !keepIfLarge
&& mLastMemoryLevel > ProcessStats.ADJ_MEM_FACTOR_NORMAL
&& proc.setProcState >= ActivityManager.PROCESS_STATE_CACHED_EMPTY) {
if (DEBUG_PSS) Slog.d(TAG_PSS, "May not keep " + proc + ": pss=" + proc.lastCachedPss);
if (proc.lastCachedPss >= mProcessList.getCachedRestoreThresholdKb()) {
if (proc.baseProcessTracker != null) {
proc.baseProcessTracker.reportCachedKill(proc.pkgList, proc.lastCachedPss);
}
proc.kill(Long.toString(proc.lastCachedPss) + "k from cached", true);
}
}
// 直接就将找到的记录对象返回。
return proc;
}getProcessRecordLocked方法的逻辑是比较简单的，他分为两部分：uid是system uid和uid是普通uid两种情况。具体的逻辑上面的注释已经解释，这里就不赘述。需要补充的是，上面如果我们的uid是system uid的话那么会使用UserHandle.isApp来判断这是不是一个app进程，他的实现如下：
isApp@UserHandle.java
/** @hide */
public static boolean isApp(int uid) {
if (uid > 0) {
final int appId = getAppId(uid);
return appId >= Process.FIRST_APPLICATION_UID && appId <= Process.LAST_APPLICATION_UID;
} else {
return false;
}
}这里的逻辑很简单，主要就是根据uid获得app的id，然后如果app id是在Process.FIRST_APPLICATION_UID和Process.LAST_APPLICATION_UID之间（这是正常app id应该处于的范围）的话，那就是一个合理的app进程。
现在我们回到addAppLocked方法，我们刚才分析了如果不是独立进程的情况的逻辑，总结来说就是通过getProcessRecordLocked查找当前系统中正在运行的进程记录，并且把这个记录保存下来。现在我们看一下如果请求的是一个独立的进程的话（这也是最常见的情形），处理的方式是什么样的：
addAppLocked@ActivityManagerService.java
final ProcessRecord addAppLocked(ApplicationInfo info, boolean isolated,
String abiOverride) {
ProcessRecord app;
if (!isolated) {
app = getProcessRecordLocked(info.processName, info.uid, true);
} else {
app = null;
}
if (app == null) {
app = newProcessRecordLocked(info, null, isolated, 0);
updateLruProcessLocked(app, false, null);
updateOomAdjLocked();
}我们看到，如果是一个独立的进程的话，那么首先app肯定就直接赋值为null，接下来我们会调用newProcessRecordLocked新建一个ProcessRecord对象，这个方法的具体处理因为和我们AMS的进程管理不是特别相关，我们就不分析了，感兴趣的读者可以自行分析。新建了一个ProcessRecord对象之后的操作就是最重要的操作了：
updateLruProcessLocked(app, false, null);
updateOomAdjLocked();这两步操作设计AMS管理进程的核心工作，我们稍后详细分析，我们先接下来的逻辑，接下来的逻辑中最重要的就是调用startProcessLocked方法实际启动一个进程：
startProcessLocked(app, "added application", app.processName, abiOverride,
null /* entryPoint */, null /* entryPointArgs */);在AMS中startProcessLocked方法实现了多态，但是根据这里的参数我们可以确定我们调用的方法是哪一个。startProcessLocked方法比较长，这里我们分部来分析：
startProcessLocked@ActivityManagerService.java
private final void startProcessLocked(ProcessRecord app, String hostingType,
String hostingNameStr, String abiOverride, String entryPoint, String[] entryPointArgs) {
long startTime = SystemClock.elapsedRealtime();
if (app.pid > 0 && app.pid != MY_PID) {
checkTime(startTime, "startProcess: removing from pids map");
synchronized (mPidsSelfLocked) {
mPidsSelfLocked.remove(app.pid);
mHandler.removeMessages(PROC_START_TIMEOUT_MSG, app);
}
checkTime(startTime, "startProcess: done removing from pids map");
app.setPid(0);
}首先需要记录一下app的启动时间，这个数据是给checkTime方法使用的，checkTime方法的定义如下：
checkTime@ActivityManagerService.java
private void checkTime(long startTime, String where) {
long now = SystemClock.elapsedRealtime();
if ((now-startTime) > 1000) {
// If we are taking more than a second, log about it.
Slog.w(TAG, "Slow operation: " + (now-startTime) + "ms so far, now at " + where);
}
}我们看到，checkTime的逻辑很简单，主要就是看看当前的时间和传递进来的时间是不是相差1000ms，如果相差1s的话那就需要打下log，这部分的逻辑就是这样。我们继续startProcessLocked的分析：
if (app.pid > 0 && app.pid != MY_PID) {
checkTime(startTime, "startProcess: removing from pids map");
synchronized (mPidsSelfLocked) {
mPidsSelfLocked.remove(app.pid);
mHandler.removeMessages(PROC_START_TIMEOUT_MSG, app);
}
checkTime(startTime, "startProcess: done removing from pids map");
app.setPid(0);
}再获得启动开始时间之后，当app的pid大于0并且pid不是本进程PID的话，就要把当前pid的进程从mPidsSelfLocked列表中移除，防止重复，因为后面我们还要加入；然后就是移除PROC_START_TIMEOUT_MSG消息，这个消息是AMS用来控制app启动时间的，如果启动超时了就发出效果消息，下面我们会设置这个消息，现在需要取消之前设置的消息，防止干扰。
接下来的逻辑：
mProcessesOnHold.remove(app);这里是将app进程从mProcessesOnHold列表中清除，这个列表是什么呢？这个列表是系统中在AMS没有启动之前请求启动的app，这些app当时没有启动，被hold了，当AMS启动完成的时候需要将他们启动；现在如果我们启动的app就在这个列表中的， 那么自然需要将它移除，防止重复启动。我们可以从mProcessesOnHold的定义的地方看到这一点：
/**
* List of records for processes that someone had tried to start before the
* system was ready. We don't start them at that point, but ensure they
* are started by the time booting is complete.
*/
final ArrayList<ProcessRecord> mProcessesOnHold = new ArrayList<ProcessRecord>();接下来就要更新cpu使用统计信息：
updateCpuStats();cpu统计使用信息也是AMS的一个重要的任务，这个任务就是通过启动一个独立的线程去获得cpu的使用情况，我们看一下updateCpuStats的实现：
void updateCpuStats() {
final long now = SystemClock.uptimeMillis();
if (mLastCpuTime.get() >= now - MONITOR_CPU_MIN_TIME) {
return;
}
if (mProcessCpuMutexFree.compareAndSet(true, false)) {
synchronized (mProcessCpuThread) {
mProcessCpuThread.notify();
}
}
}我们发现它的逻辑很简单，首先是判断当前时间是不是和上次检查时间相差MONITOR_CPU_MIN_TIME（5s）以上，如果是就继续，如果不是就返回，因为不能过于平凡做这件事情，它比较耗电。工作的方式就是唤醒mProcessCpuThread去采集cpu的信息。这个线程的实现我们这里先不分析，这块和我们的进程管理相关不是很密切，我后面的文章会详细分析这块的内容。在startProcessLocked的接下来的逻辑中，主要就是app启动的一些参数设置，条件检查等操作，这里我们直接略过，我们直接看实际进程启动的部分：
// Start the process. It will either succeed and return a result containing
// the PID of the new process, or else throw a RuntimeException.
boolean isActivityProcess = (entryPoint == null);
if (entryPoint == null) entryPoint = "android.app.ActivityThread";
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "Start proc: " +
app.processName);
checkTime(startTime, "startProcess: asking zygote to start proc");
// 实际启动了一个进程
Process.ProcessStartResult startResult = Process.start(entryPoint,
app.processName, uid, uid, gids, debugFlags, mountExternal,
app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
app.info.dataDir, entryPointArgs);
checkTime(startTime, "startProcess: returned from zygote!");
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);上面代码中最核心的代码就是调用Process.start静态方法部分，这个调用会通过socket和zygote建立链接请求，fork新进程，我们看一下start方法实现：
public static final ProcessStartResult start(final String processClass,
final String niceName,
int uid, int gid, int[] gids,
int debugFlags, int mountExternal,
int targetSdkVersion,
String seInfo,
String abi,
String instructionSet,
String appDataDir,
String[] zygoteArgs) {
try {
return startViaZygote(processClass, niceName, uid, gid, gids,
debugFlags, mountExternal, targetSdkVersion, seInfo,
abi, instructionSet, appDataDir, zygoteArgs);
} catch (ZygoteStartFailedEx ex) {
Log.e(LOG_TAG,
"Starting VM process through Zygote failed");
throw new RuntimeException(
"Starting VM process through Zygote failed", ex);
}
}这里的startViaZygote方法会和zygote建立链接并且创建进程，这里我们就不详细分析zygote部分的fork逻辑了。我们再次回到startProcessLocked方法中分析剩下的逻辑，刚才我们上面的请求zygote的部分是一个异步请求，会立即返回，当时实际进程启动需要多长的时间是不确定的，但是我们不能无限制等待，需要有一个启动超时机制，在startProcessLocked接下来的逻辑中就启动了一个延迟消息：
synchronized (mPidsSelfLocked) {
this.mPidsSelfLocked.put(startResult.pid, app);
if (isActivityProcess) {
Message msg = mHandler.obtainMessage(PROC_START_TIMEOUT_MSG);
msg.obj = app;
mHandler.sendMessageDelayed(msg, startResult.usingWrapper
? PROC_START_TIMEOUT_WITH_WRAPPER : PROC_START_TIMEOUT);
}
}这个消息是PROC_START_TIMEOUT_MSG用于通知应用启动超时了，由mHandler负责处理。并且超时的阀值是根据当前启动的进程是不是一个wrapper进程来决定的，如果是wrapper进程的话那超时就是PROC_START_TIMEOUT_WITH_WRAPPER（1200s），如果不是则PROC_START_TIMEOUT（10s），正常情况下都是后者，wrapper进程使用场景较少。为了弄清楚假如发生了启动超时，系统怎么处理，我们还需要看一下mHandler对这个消息的处理：
mHandler@ActivityManagerService.java
case PROC_START_TIMEOUT_MSG: {
if (mDidDexOpt) {
mDidDexOpt = false;
Message nmsg = mHandler.obtainMessage(PROC_START_TIMEOUT_MSG);
nmsg.obj = msg.obj;
mHandler.sendMessageDelayed(nmsg, PROC_START_TIMEOUT);
return;
}
ProcessRecord app = (ProcessRecord)msg.obj;
synchronized (ActivityManagerService.this) {
processStartTimedOutLocked(app);
}
} break;首先需要判断当前这个app是不处在dex优化过程中，如果是处在dex优化过程中的话，那么app的启动时间很长可以理解，因为实际的启动需要等到dex优化完毕才能进行，这个时候就直接再等PROC_START_TIMEOUT（10s）之后再检查。我们看下mDidDexOpt的定义就知道了：
/**
* This is set if we had to do a delayed dexopt of an app before launching
* it, to increase the ANR timeouts in that case.
*/
boolean mDidDexOpt;这里的注释写的很清楚了。在mHandler中如果不是在dex优化中的话，那么就要调用processStartTimedOutLocked方法来处理启动超时的数据和资源回收的操作了，并且需要停止当前这个任务，同时以ANR的方式通知用户，这部分的逻辑这里就不详述了。
到现在位置我们弄明白了android是怎么启动一个app进程的了，主要就是通过addAppLocked方法实现，这个方法会调用startProcessLocked方法实现，而这个方法很长，主要就是一些app进程启动数据和参数检查和设置，最后就是调用Process类的静态方法start方法和zygote建立链接fork进程。了解了AMS怎么启动一个进程之后，我们接下来分析一下AMS怎么管理进程的。
AMS的进程管理之LRU管理
前面我们在分析app进程的启动流程的时候，我们看到系统调用updateLruProcessLocked和updateOomAdjLocked来调控设置进程，其实在AMS中有很多地方都会调用到他们。我们首先来看下updateLruProcessLocked方法，这个方法用来调整某个进程在mLruProcesses列表中的位置，mLruProcesses是最近使用进程列表的意思。每当进程中的activity或者service等组件发生变化的时候，就意味着相应的进程发生了活动，因此调用这个方法将该进程调整到尽可能高的位置，同时还要更新关联进程的位置。在mLruProcesses这个列表中，最近运行的进程是从前往后排列的，也就是说越是处于前端的这个进程就越是最近使用的，同时需要注意的是拥有activity的进程的位置总是高于只有service的进程，因为activity可以和用户发生实际的交互，而后台的service是不可以的。
还要需要说明的是，在分析LRU管理机制之前，我们需要关注以下两个变量：
/** * Where in mLruProcesses that the processes hosting activities start. */
int mLruProcessActivityStart = 0;
/** * Where in mLruProcesses that the processes hosting services start. * This is after (lower index) than mLruProcessesActivityStart. */
int mLruProcessServiceStart = 0;就如同注释解释的那样，第一个变量总是指向列表中位置最高的带有activity进程和没有activity只有service的进程，并且mLruProcessServiceStart总是在mLruProcessActivityStart的后面。还需要注意的是mLruProcesses的定义：
/** * List of running applications, sorted by recent usage. * The first entry in the list is the least recently used. */
final ArrayList<ProcessRecord> mLruProcesses = new ArrayList<ProcessRecord>();我们看到mLruProcesses只是一个ArrayList，在mLruProcesses中，某个成员的index越大，就表示这个app越是最近使用的，这一点在后面的分析中很重要。
接下来我们看一下updateLruProcessLocked的实现，这个方法比较长，我们分段来分析这个方法的实现：
final void updateLruProcessLocked(ProcessRecord app, boolean activityChange,
ProcessRecord client) {
final boolean hasActivity = app.activities.size() > 0 || app.hasClientActivities
|| app.treatLikeActivity;
final boolean hasService = false; // not impl yet. app.services.size() > 0;首先我们看到这里定义一个变量hasActivity用来表示某个app中是否包含activity组件，以下三种情况都可以看做是有activity组件的：app本身确实包含activity组件；app本身有service，并且有另外一个含有activity的app链接到此app的service上；该app启动serivce的时候带有标记BIND_TREAT_LIKE_ACTIVITY。接下来的变量hasService只是定义了，但是没有实际的实现，从后面的注释我们也能看出这一点（Google的代码还是有待开发的，有很多功能还是没有完善的，android系统源码中有很多这样的代码），所以我们后面分析的时候和这个变量相关的代码可以直接跳过。接下来的代码如下：
if (!activityChange && hasActivity) {
// The process has activities, so we are only allowing activity-based adjustments
// to move it. It should be kept in the front of the list with other
// processes that have activities, and we don't want those to change their
// order except due to activity operations.
return;
}这里的代码中注释写的很清楚，这里的意思就是，如果当前app中有activity组件，并且不是activity发生了改变（启动或者销毁等），那就直接返回，因为这个时候没有必要更新LRU。
我们继续看下面的代码：
// 这是系统中的一个计数器，记录本方法被调用了多少次，也就是LRU更新了多少次。
mLruSeq++;
// 记录更新时间
final long now = SystemClock.uptimeMillis();
app.lastActivityTime = now;
// First a quick reject: if the app is already at the position we will
// put it, then there is nothing to do.
// 上面英文注释写的很清楚，就是查看我们要插入的app是不是已经在mLruProcesses顶端了，如果是就不用插入了。
if (hasActivity) {
// 有activity的情况
final int N = mLruProcesses.size();
if (N > 0 && mLruProcesses.get(N-1) == app) {
if (DEBUG_LRU) Slog.d(TAG_LRU, "Not moving, already top activity: " + app);
return;
}
} else {
// 没有activity情况，可以暂时理解为有service的情况（真正有service的判定暂时没有实现呢！！）
if (mLruProcessServiceStart > 0
&& mLruProcesses.get(mLruProcessServiceStart-1) == app) {
if (DEBUG_LRU) Slog.d(TAG_LRU, "Not moving, already top other: " + app);
return;
}
}上面的代码意图我的注释中已经写清楚了，基本逻辑也很简单。下面我们继续分析代码：
int lrui = mLruProcesses.lastIndexOf(app);
if (app.persistent && lrui >= 0) {
// We don't care about the position of persistent processes, as long as
// they are in the list.
if (DEBUG_LRU) Slog.d(TAG_LRU, "Not moving, persistent: " + app);
return;
}这部分的代码主要就是要排除persistent app，这部分app不会被杀死，永远在运行，因此没有必要针对这样的app进程进行LRU排序。
if (lrui >= 0) {
if (lrui < mLruProcessActivityStart) {
mLruProcessActivityStart--;
}
if (lrui < mLruProcessServiceStart) {
mLruProcessServiceStart--;
}
mLruProcesses.remove(lrui);
}这部分代码逻辑也很简单，首先判断一下我们需要更新的app所在的index，如果小于mLruProcessActivityStart，那么mLruProcessActivityStart需要减1，同理如果小于mLruProcessServiceStart，那么mLruProcessServiceStart也需要减1，这两个变量的含义上面已经解释，这里操作因为我们下面即将remove掉这个app进程记录（我们要把它放到合适的地方去），所以这里都要减1.
接下来的代码就是主要操作代码了，分为3种情况操作：有activity的，有service的（没有实现，我们略过），其他的（暂时可以理解为有service的）。我们首先看一下有activity的情况：
// 这个变量指向我们操作app进程记录的下一个index
int nextIndex;
if (hasActivity) {
final int N = mLruProcesses.size();
// 这个分支表示目前app没有activity，并且链接到它的service中的app有activity，这里就把这个app添加到mLruProcesses的第二位，因为第一位必须是实际包含activity的app进程
if (app.activities.size() == 0 && mLruProcessActivityStart < (N - 1)) {
// Process doesn't have activities, but has clients with
// activities... move it up, but one below the top (the top
// should always have a real activity).
if (DEBUG_LRU) Slog.d(TAG_LRU,
"Adding to second-top of LRU activity list: " + app);
mLruProcesses.add(N - 1, app);
// To keep it from spamming the LRU list (by making a bunch of clients),
// we will push down any other entries owned by the app.
// 为了防止某个app中的service绑定了一群client从而导致LRU中顶部大部分都是这些client，这里需要将这些client往下移动，以防止某些app通过和某个app的service绑定从而提升自己在LRU中位置。
final int uid = app.info.uid;
for (int i = N - 2; i > mLruProcessActivityStart; i--) {
ProcessRecord subProc = mLruProcesses.get(i);
if (subProc.info.uid == uid) {
// We want to push this one down the list. If the process after
// it is for the same uid, however, don't do so, because we don't
// want them internally to be re-ordered.
if (mLruProcesses.get(i - 1).info.uid != uid) {
if (DEBUG_LRU) Slog.d(TAG_LRU,
"Pushing uid " + uid + " swapping at " + i + ": "
+ mLruProcesses.get(i) + " : " + mLruProcesses.get(i - 1));
ProcessRecord tmp = mLruProcesses.get(i);
mLruProcesses.set(i, mLruProcesses.get(i - 1));
mLruProcesses.set(i - 1, tmp);
i--;
}
} else {
// A gap, we can stop here.
break;
}
}
// 如果进程有activity，就把它放到顶端（很多情况下都是走这个逻辑）
} else {
// Process has activities, put it at the very tipsy-top.
if (DEBUG_LRU) Slog.d(TAG_LRU, "Adding to top of LRU activity list: " + app);
mLruProcesses.add(app);
}
nextIndex = mLruProcessServiceStart;
}上面的代码展示了当某个应用的hasActivity为true的时候的逻辑，上面的注释说的很清楚，这里不再赘述，只是读者需要仔细理解一下这里的代码，才能理解其中的含义。我们继续看接下来的代码：
// 这个分支不会执行，因为hasService判定没有实现，总是为false
else if (hasService) {
// Process has services, put it at the top of the service list.
if (DEBUG_LRU) Slog.d(TAG_LRU, "Adding to top of LRU service list: " + app);
mLruProcesses.add(mLruProcessActivityStart, app);
nextIndex = mLruProcessServiceStart;
mLruProcessActivityStart++;
// 一般就是走这个分支了，目前可以理解为有service的情况
} else {
// Process not otherwise of interest, it goes to the top of the non-service area.
// 我们直接定义index为mLruProcessServiceStart，因为此时的位置最高只能是mLruProcessServiceStart这个位置
int index = mLruProcessServiceStart;
// 一般情况下client都是null
if (client != null) {
// If there is a client, don't allow the process to be moved up higher
// in the list than that client.
int clientIndex = mLruProcesses.lastIndexOf(client);
if (DEBUG_LRU && clientIndex < 0) Slog.d(TAG_LRU, "Unknown client " + client
+ " when updating " + app);
if (clientIndex <= lrui) {
// Don't allow the client index restriction to push it down farther in the
// list than it already is.
clientIndex = lrui;
}
if (clientIndex >= 0 && index > clientIndex) {
index = clientIndex;
}
}
if (DEBUG_LRU) Slog.d(TAG_LRU, "Adding at " + index + " of LRU list: " + app);
// 将app进程记录对象插入到index位置
mLruProcesses.add(index, app);
nextIndex = index-1;
mLruProcessActivityStart++;
mLruProcessServiceStart++;
}到这里我们的LRU基本就更新完毕，下面的代码对这个列表还需要进行一定的微调：
// If the app is currently using a content provider or service,
// bump those processes as well.
for (int j=app.connections.size()-1; j>=0; j--) {
ConnectionRecord cr = app.connections.valueAt(j);
if (cr.binding != null && !cr.serviceDead && cr.binding.service != null
&& cr.binding.service.app != null
&& cr.binding.service.app.lruSeq != mLruSeq
&& !cr.binding.service.app.persistent) {
nextIndex = updateLruProcessInternalLocked(cr.binding.service.app, now, nextIndex,
"service connection", cr, app);
}
}
for (int j=app.conProviders.size()-1; j>=0; j--) {
ContentProviderRecord cpr = app.conProviders.get(j).provider;
if (cpr.proc != null && cpr.proc.lruSeq != mLruSeq && !cpr.proc.persistent) {
nextIndex = updateLruProcessInternalLocked(cpr.proc, now, nextIndex,
"provider reference", cpr, app);
}
}这里的微调分为两种情况，第一是将和本进程的service关联的client进程的位置调整到本进程之后，第二是将和本进程ContentProvider关联的client进程位置调整到本进程之后。调整的方式都是使用updateLruProcessInternalLocked方法，我们看一下updateLruProcessInternalLocked方法的定义：
updateLruProcessInternalLocked@ActivityManagerService.java
private int updateLruProcessInternalLocked(ProcessRecord app, long now, int index,
String what, Object obj, ProcessRecord srcApp) {
app.lastActivityTime = now;
// 如果有activity，不做调整，因为不属于这个调整范围
if (app.activities.size() > 0) {
// Don't want to touch dependent processes that are hosting activities.
return index;
}
int lrui = mLruProcesses.lastIndexOf(app);
// 如果进程不在mLruProcesses中就返回
if (lrui < 0) {
Slog.wtf(TAG, "Adding dependent process " + app + " not on LRU list: "
+ what + " " + obj + " from " + srcApp);
return index;
}
// 如果目前进程的位置高于需要调整的位置，那么不做调整，返回
if (lrui >= index) {
// Don't want to cause this to move dependent processes *back* in the
// list as if they were less frequently used.
return index;
}
// 如果目前进程的位置比mLruProcessActivityStart还要高，无需调整
if (lrui >= mLruProcessActivityStart) {
// Don't want to touch dependent processes that are hosting activities.
return index;
}
// 把app调整到index-1的位置
mLruProcesses.remove(lrui);
if (index > 0) {
index--;
}
if (DEBUG_LRU) Slog.d(TAG_LRU, "Moving dep from " + lrui + " to " + index
+ " in LRU list: " + app);
mLruProcesses.add(index, app);
// 返回目前进程的位置
return index;
}我们前面mLruProcessActivityStart调用这个方法的时候传递的index参数都是nextIndex，也就是说需要把新插入的进程记录的下一个进行微调，最高就是放到mLruProcessServiceStart的位置。
到这里我们就基本分析完了LRU的更新过程，现在我们总结一下它的流程:updateLruProcessLocked方法中调整进程很重要的一个依据就是进程有没有活动的activity，除了进程本身存在activity对象外，如果和进程中运行的serivice相关联的客户进程中有activity也算是本进程拥有activity。如果一个进程拥有activity的话，那么把这个进程放到列表的最高位置，否则只会把它放到没有activity的前面。调整某个进程的位置之后，还有调整和该进程的关联进程的位置，进程的关联进程有两种类型：绑定本进程servrice的进程和链接了本进程的ContentProvider的进程。同时，如果这些进程本身是有activity的话，那么就不调整，需要调整的是那些没有activity的进程，在updateLruProcessInternalLocked方法中会做这种调整。
AMS的进程管理之oom_adj管理
在介绍AMS的进程oom_adj管理之前，我们先了解一下什么是oom_adj。我们知道android运行的设备一般都是内存资源比较有限的嵌入式移动设备，在这些设备上的内存资源是十分宝贵的，因此我们需要妥善的使用和管理，总的来说就是：在合适的时候，将必要的内存资源释放出来。传统的linux的做法就是将不需要的进程直接杀死，为重要的进程运行腾出“空”来。但是问题来了，你根据什么来决定是否杀死一个进程呢？或者说你怎么知道某个进程是可以杀死的？仿照linux的做法，我们可以给每一个进程标记一个优先级，但是android中的进程和linux中的进程又不太一样了，进程之间可以通过binder绑定，如果杀死绑定的一端，另一端也可能会出问题。那么android是怎么做的呢，android引入了oom_adj这个东西，所谓的oom_adj就是out of memory adjustment中文叫做内存溢出调节器，这么翻译有点生硬，说的简单点这个东西就是一个用来标记某个app进程的重要性，这个值越小说明它越重要，越大就越有可能在必要的时候被“干掉”。
下面我们先看一下android中都定义了那些oom_adj的值，这些值定义在/frameworks/base/services/core/java/com/android/server/am/ProcessList.java中：
// OOM adjustments for processes in various states:
// Adjustment used in certain places where we don't know it yet.
// (Generally this is something that is going to be cached, but we
// don't know the exact value in the cached range to assign yet.)
static final int UNKNOWN_ADJ = 16;
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
static final int CACHED_APP_MAX_ADJ = 15;
static final int CACHED_APP_MIN_ADJ = 9;
// The B list of SERVICE_ADJ -- these are the old and decrepit
// services that aren't as shiny and interesting as the ones in the A list.
static final int SERVICE_B_ADJ = 8;
// This is the process of the previous application that the user was in.
// This process is kept above other things, because it is very common to
// switch back to the previous app. This is important both for recent
// task switch (toggling between the two top recent apps) as well as normal
// UI flow such as clicking on a URI in the e-mail app to view in the browser,
// and then pressing back to return to e-mail.
static final int PREVIOUS_APP_ADJ = 7;
// This is a process holding the home application -- we want to try
// avoiding killing it, even if it would normally be in the background,
// because the user interacts with it so much.
static final int HOME_APP_ADJ = 6;
// This is a process holding an application service -- killing it will not
// have much of an impact as far as the user is concerned.
static final int SERVICE_ADJ = 5;
// This is a process with a heavy-weight application. It is in the
// background, but we want to try to avoid killing it. Value set in
// system/rootdir/init.rc on startup.
static final int HEAVY_WEIGHT_APP_ADJ = 4;
// This is a process currently hosting a backup operation. Killing it
// is not entirely fatal but is generally a bad idea.
static final int BACKUP_APP_ADJ = 3;
// This is a process only hosting components that are perceptible to the
// user, and we really want to avoid killing them, but they are not
// immediately visible. An example is background music playback.
static final int PERCEPTIBLE_APP_ADJ = 2;
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
static final int VISIBLE_APP_ADJ = 1;
// This is the process running the current foreground app. We'd really
// rather not kill it!
static final int FOREGROUND_APP_ADJ = 0;
// This is a process that the system or a persistent process has bound to,
// and indicated it is important.
static final int PERSISTENT_SERVICE_ADJ = -11;
// This is a system persistent process, such as telephony. Definitely
// don't want to kill it, but doing so is not completely fatal.
static final int PERSISTENT_PROC_ADJ = -12;
// The system process runs at the default adjustment.
static final int SYSTEM_ADJ = -16;
// Special code for native processes that are not being managed by the system (so
// don't have an oom adj assigned by the system).
static final int NATIVE_ADJ = -17;这里google的注释说的很清楚，我就不多废话，但是有几个值是比较重要的：
FOREGROUND_APP_ADJ：这表示进程有一个正在和用户交互的界面，这个千万不能杀死，除非万不得已。
VISIBLE_APP_ADJ：这个表示进程中的某个UI组件是可以被用户看见的，但是并没有和用户发生交互，比如一个被dialog挡住部分的activity，这个进程也是尽量不能杀死的，因为用户是可以看见它的，杀死的话会影响用户的体验。
PERCEPTIBLE_APP_ADJ：正如注释里面说的那样，这个adj表示进程中的某个组件可以被用户感知到，比如说一个正在播放音乐的进程。
BACKUP_APP_ADJ：当前进程正在执行一个备份的操作，这个操作最好不要打断，否则会出现不可修复的数据错误。
CACHED_APP_MIN_ADJ：这是cache进程的最小的adj的值
CACHED_APP_MAX_ADJ：cache进程的最大adj的值
这里我们提到一个cache进程概念，那么什么是cache进程呢？我们在解释这个之前，先看一下android中的进程生命周期吧。在android中不仅UI组件有生命周期，我们的进程也是有生命周期的，关于android生命周期google有说明的文档：
https://developer.android.com/guide/components/processes-and-threads.html
这里我只是重点解释一下google的文档，这个文档中解释了在android中的进程的5种生命周期：
1. Foreground process
原文解释：
意思是说，只要某个进程有处于前台的组件在运行，只要满足上面的5个条件就算是前台进程。
2. Visible process
可见进程的表面意思就是这个进程中的组件用户是可以看到的，很多情况下确实如此，但是还有另外一种情况，那就是它的service绑定到了一个运行于前台的activity或这UI组件。
3. Service process
服务进程就是指一个拥有后台运行service的进程，这个进程在后台为用户和设备的交互提供运行支撑。
4. Background process
后台进程就是指，一个带有activity的进程，但是这个activity已经放到后台了，onStop方法已经被回调了；这个时候用户已经看不见这个activity了，所以这个进程对用户的体验是没有直接影响的。因此，在某些需要内存的时候，我们可以将这个进程杀死。一般而言我们的系统中有很多后台进程，比如我们我们运行了一个没有service的app，然后我们按下home键回到桌面，那么这个进程就是后台进程了。
5. Empty process
空近程，顾名思义，就是进程中什么组件都没有了，当Background process中的后台activity被destroy的时候他就变成了空进程。空进程是所有进程中优先级最低的，是最可能被杀死的进程。
回到我们刚才说的cache进程，所谓的cache进程就是上面说的Background process。当我们的进程没有任何后台的时候，如果它退出了前台，android系统是不会立即将它杀死的。因为，用户很可能还会在不就的将来再次回到这个应用中，这个时候如果我们把它cache起来了，下次用户再次启动这个进程的时候速度就快了，这对于用户体验是很重要的；另外，这些cache进程确实占用了内存，如果我们需要内存的时候，就首先杀死这些cache进程。举个形象点的例子，android中的所有的进程就像监狱中的犯人，而cache进程就是那些被判死刑，但是缓期执行的犯人。
理解了什么是cache进程之后，我们开始分析AMS是怎么管理oom_adj的。所谓的oom_adj的管理就是为每一个进程设置一个合理的oom_adj值。在AMS中，oom_adj值的设置是通过updateOomAdjLocked方法完成，这个方法比较长，我们分段来分析：
updateOomAdjLocked@ActivityManagerService.java
final void updateOomAdjLocked() {
final ActivityRecord TOP_ACT = resumedAppLocked();
final ProcessRecord TOP_APP = TOP_ACT != null ? TOP_ACT.app : null;
final long now = SystemClock.uptimeMillis();
final long oldTime = now - ProcessList.MAX_EMPTY_TIME;
final int N = mLruProcesses.size();这里是一些变量的初始化，比较重要的是这里首先获得了位于前台的activity所在的进程，通过resumedAppLocked方法获得，resumedAppLocked会通过ActivityStackSupervisor.java中的resumedAppLocked来获取，这部分涉及AMS的activity的管理，我们先不分析，后面我们分析AMS的activity的管理的时候我们再说明这一块。这里还要注意的是oldTime，oldTime是用当前时间减去MAX_EMPTY_TIME获得的，MAX_EMPTY_TIME的定义如下：
// We allow empty processes to stick around for at most 30 minutes.
static final long MAX_EMPTY_TIME = 30*60*1000;它的长度是30min，从上面的注释我们也可以看到，所有的空进程的保留时间都是30min，30min后就会杀死它，后面我们会看到这个操作。
我们继续updateOomAdjLocked的分析：
// Reset state in all uid records.
for (int i=mActiveUids.size()-1; i>=0; i--) {
final UidRecord uidRec = mActiveUids.valueAt(i);
if (false && DEBUG_UID_OBSERVERS) Slog.i(TAG_UID_OBSERVERS,
"Starting update of " + uidRec);
uidRec.reset();
}接下来就是将mActiveUids中的每一个UidRecord对象中的curProcState都重置为PROCESS_STATE_CACHED_EMPTY：
reset@UidRecord.java
public void reset() {
curProcState = ActivityManager.PROCESS_STATE_CACHED_EMPTY;
}UidRecord是用来表示一个uid启动的进程记录，而AMS中的mActiveUids是一个SparseArray，存储了每一个uid的对应的最新运行的进程，我们看下mActiveUids定义就知道了：
/** * Track all uids that have actively running processes. */
final SparseArray<UidRecord> mActiveUids = new SparseArray<>();这里的注释说的很清楚了。返回到updateOomAdjLocked中，我们把mActiveUids每一个UidRecord的当前进程状态reset为PROCESS_STATE_CACHED_EMPTY，是因为我们下面需要给他一个合适的值。
我们继续查看updateOomAdjLocked接下来的代码：
mAdjSeq++; mNewNumServiceProcs = 0; mNewNumAServiceProcs = 0;首先更新oom_adj更新计数，然后将和service process有关的两个变量赋值为0，后面的代码会操作这个变量，我们到时候再讲解。
接下来，就是获得系统后台进程限制的情况了：
// 表示后台可以运行的空进程数量
final int emptyProcessLimit;
// 表示后台可以运行的缓存进程的数量
final int cachedProcessLimit;
// mProcessLimit变量表示系统中一共可以有多少个后台进程（empty + cache）
if (mProcessLimit <= 0) {
emptyProcessLimit = cachedProcessLimit = 0;
} else if (mProcessLimit == 1) {
emptyProcessLimit = 1;
cachedProcessLimit = 0;
} else {
emptyProcessLimit = ProcessList.computeEmptyProcessLimit(mProcessLimit);
cachedProcessLimit = mProcessLimit - emptyProcessLimit;
}上面的代码就是获得系统有关后台进程数目的限制设置，系统中后台进程总数目不能超过mProcessLimit个，这个变量的初始值是：
int mProcessLimit = ProcessList.MAX_CACHED_APPS;MAX_CACHED_APPS定义如下：
// The maximum number of cached processes we will keep around before killing them.
// NOTE: this constant is *only* a control to not let us go too crazy with
// keeping around processes on devices with large amounts of RAM. For devices that
// are tighter on RAM, the out of memory killer is responsible for killing background
// processes as RAM is needed, and we should *never* be relying on this limit to
// kill them. Also note that this limit only applies to cached background processes;
// we have no limit on the number of service, visible, foreground, or other such
// processes and the number of those processes does not count against the cached
// process limit.
static final int MAX_CACHED_APPS = 32;我们看到了，初始值系统中的所有后台进程，也就是空进程和cache进程的总和不能超过32个。但是，用户可以设置这个值，在settings的开发者选项中可以设置，如下图：
用户可以点击上图中的“后台进程限制”来设置对应的值。
不过一般情况下，这个值都是32.现在我们就以32为值来分析一下代码，我们看到上面的代码中最终会走到最后一个分支，这个分支中针对emptyProcessLimit和cachedProcessLimit分别赋值，emptyProcessLimit的值是通过ProcessList的computeEmptyProcessLimit获取的：
computeEmptyProcessLimit@ProcessList.java
public static int computeEmptyProcessLimit(int totalProcessLimit) {
return totalProcessLimit/2;
}我们看到这里的操作很简单，直接把mProcessLimit除以2，然后返回。这里除以2的意思就是空进程和cache进程数目对半分，各为16个。
我们继续看接下来的代码：
// Let's determine how many processes we have running vs.
// how many slots we have for background processes; we may want
// to put multiple processes in a slot of there are enough of
// them.
int numSlots = (ProcessList.CACHED_APP_MAX_ADJ
- ProcessList.CACHED_APP_MIN_ADJ + 1) / 2;
int numEmptyProcs = N - mNumNonCachedProcs - mNumCachedHiddenProcs;
if (numEmptyProcs > cachedProcessLimit) {
// If there are more empty processes than our limit on cached
// processes, then use the cached process limit for the factor.
// This ensures that the really old empty processes get pushed
// down to the bottom, so if we are running low on memory we will
// have a better chance at keeping around more cached processes
// instead of a gazillion empty processes.
numEmptyProcs = cachedProcessLimit;
}
int emptyFactor = numEmptyProcs/numSlots;
if (emptyFactor < 1) emptyFactor = 1;
int cachedFactor = (mNumCachedHiddenProcs > 0 ? mNumCachedHiddenProcs : 1)/numSlots;
if (cachedFactor < 1) cachedFactor = 1;
int stepCached = 0;
int stepEmpty = 0;
int numCached = 0;
int numEmpty = 0;
int numTrimming = 0;
mNumNonCachedProcs = 0;
mNumCachedHiddenProcs = 0;这段代码首先计算了cache进程的slot数目，结果是（15-9+1）/2=3，然后是计算了空进程的数目，直接用mLruProcesses总数目减去mNumNonCachedProcs（非cache进程，正常进程）和mNumCachedHiddenProcs（cache进程）得到。然后就是emptyFactor（每个slot的empty的进程数）和cachedFactor（每个slot的cache进程数）的计算，方法是对应的总数目除以slot数目。这些变量有什么意义呢？下面的代码给了我们答案：
// First update the OOM adjustment for each of the
// application processes based on their current state.
// 获得cache adj值
int curCachedAdj = ProcessList.CACHED_APP_MIN_ADJ;
int nextCachedAdj = curCachedAdj+1;
int curEmptyAdj = ProcessList.CACHED_APP_MIN_ADJ;
int nextEmptyAdj = curEmptyAdj+2;
// 从mLruProcesses的顶部，循环操作
for (int i=N-1; i>=0; i--) {
ProcessRecord app = mLruProcesses.get(i);
// 如果这个app进程没有被AMS杀死并且主线程不为空（已经运行）的话，就执行下面操作
if (!app.killedByAm && app.thread != null) {
app.procStateChanged = false;
// 通过computeOomAdjLocked计算app进程的oom_adj值，这是一个重要操作，下面我们详细分析
computeOomAdjLocked(app, ProcessList.UNKNOWN_ADJ, TOP_APP, true, now);
// If we haven't yet assigned the final cached adj
// to the process, do that now.
// 如上面的注释，如果我们还没有设置oom_adj值的话，换句话说，那就是我们经过computeOomAdjLocked计算之后我们的oom_adj的值还是比UNKNOWN_ADJ要大，说明这个进程是cache进程或者空进程
if (app.curAdj >= ProcessList.UNKNOWN_ADJ) {
switch (app.curProcState) {
// 以下两个case说明是cache进程
case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY:
case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY_CLIENT:
// This process is a cached process holding activities...
// assign it the next cached value for that type, and then
// step that cached level.
app.curRawAdj = curCachedAdj;
// 通过modifyRawOomAdj调整当前app进程的oom_adj的值
app.curAdj = app.modifyRawOomAdj(curCachedAdj);
if (DEBUG_LRU && false) Slog.d(TAG_LRU, "Assigning activity LRU #" + i
+ " adj: " + app.curAdj + " (curCachedAdj=" + curCachedAdj
+ ")");
// 没有达到最大值CACHED_APP_MAX_ADJ
if (curCachedAdj != nextCachedAdj) {
stepCached++;
// 如果当前slot中的cache进程数大于前面算出的cachedFactor的话就要进入下一个slot，这么做的目的就是使得从CACHED_APP_MIN_ADJ到CACHED_APP_MAX_ADJ之间的cache进程数目分配均匀，否则就会出现很多优先级相差很多的cache进程拥有相近的oom_adj的值，这样的结果是不合理的。
if (stepCached >= cachedFactor) {
stepCached = 0;
curCachedAdj = nextCachedAdj;
nextCachedAdj += 2;
if (nextCachedAdj > ProcessList.CACHED_APP_MAX_ADJ) {
nextCachedAdj = ProcessList.CACHED_APP_MAX_ADJ;
}
}
}
break;
// 这个case就是empty进程了，处理的逻辑和上面的cache进程是一样的
default:
// For everything else, assign next empty cached process
// level and bump that up. Note that this means that
// long-running services that have dropped down to the
// cached level will be treated as empty (since their process
// state is still as a service), which is what we want.
app.curRawAdj = curEmptyAdj;
app.curAdj = app.modifyRawOomAdj(curEmptyAdj);
if (DEBUG_LRU && false) Slog.d(TAG_LRU, "Assigning empty LRU #" + i
+ " adj: " + app.curAdj + " (curEmptyAdj=" + curEmptyAdj
+ ")");
if (curEmptyAdj != nextEmptyAdj) {
stepEmpty++;
if (stepEmpty >= emptyFactor) {
stepEmpty = 0;
curEmptyAdj = nextEmptyAdj;
nextEmptyAdj += 2;
if (nextEmptyAdj > ProcessList.CACHED_APP_MAX_ADJ) {
nextEmptyAdj = ProcessList.CACHED_APP_MAX_ADJ;
}
}
}
break;
}
}
// 应用更新oom_adj后的数据，主要就是更新进程的各种oom_adj的值
applyOomAdjLocked(app, true, now);
// Count the number of process types.
// 统计各种类型进程的数目
switch (app.curProcState) {
case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY:
case ActivityManager.PROCESS_STATE_CACHED_ACTIVITY_CLIENT:
mNumCachedHiddenProcs++;
numCached++;
if (numCached > cachedProcessLimit) {
app.kill("cached #" + numCached, true);
}
break;
case ActivityManager.PROCESS_STATE_CACHED_EMPTY:
if (numEmpty > ProcessList.TRIM_EMPTY_APPS
&& app.lastActivityTime < oldTime) {
app.kill("empty for "
+ ((oldTime + ProcessList.MAX_EMPTY_TIME - app.lastActivityTime)
/ 1000) + "s", true);
} else {
numEmpty++;
if (numEmpty > emptyProcessLimit) {
app.kill("empty #" + numEmpty, true);
}
}
break;
default:
mNumNonCachedProcs++;
break;
}
// 下面的注释写的很清楚，意思就是如果这个app进程是独立的，并且这个app中没有任何的service，那么这个进程就没有存在的必要的，直接杀死。
if (app.isolated && app.services.size() <= 0) {
// If this is an isolated process, and there are no
// services running in it, then the process is no longer
// needed. We agressively kill these because we can by
// definition not re-use the same process again, and it is
// good to avoid having whatever code was running in them
// left sitting around after no longer needed.
app.kill("isolated not needed", true);
} else {
// Keeping this process, update its uid.
// 否则就保留这个进程
final UidRecord uidRec = app.uidRecord;
if (uidRec != null && uidRec.curProcState > app.curProcState) {
uidRec.curProcState = app.curProcState;
}
}
// 如果这个app进程的重要级别比home的级别低的话，那么就增加trim计数，这个计数在后面清除多余app进程时会用到。
if (app.curProcState >= ActivityManager.PROCESS_STATE_HOME
&& !app.killedByAm) {
numTrimming++;
}
}
}上面代码中我的注释将这段程序的基本逻辑描述了，这里就不再赘述。这里需要额外说明一下，我们上面通过调用modifyRawOomAdj方法调整对应app进程的oom_adj值，我们下面看一下是怎么调整的：
modifyRawOomAdj@ProcessRecord.java
int modifyRawOomAdj(int adj) {
if (hasAboveClient) {
// If this process has bound to any services with BIND_ABOVE_CLIENT,
// then we need to drop its adjustment to be lower than the service's
// in order to honor the request. We want to drop it by one adjustment
// level... but there is special meaning applied to various levels so
// we will skip some of them.
if (adj < ProcessList.FOREGROUND_APP_ADJ) {
// System process will not get dropped, ever
} else if (adj < ProcessList.VISIBLE_APP_ADJ) {
adj = ProcessList.VISIBLE_APP_ADJ;
} else if (adj < ProcessList.PERCEPTIBLE_APP_ADJ) {
adj = ProcessList.PERCEPTIBLE_APP_ADJ;
} else if (adj < ProcessList.CACHED_APP_MIN_ADJ) {
adj = ProcessList.CACHED_APP_MIN_ADJ;
} else if (adj < ProcessList.CACHED_APP_MAX_ADJ) {
adj++;
}
}
return adj;
}这里的操作分两种情况：如果hasAboveClient为true和false。hasAboveClient定义如下：
boolean hasAboveClient; // Bound using BIND_ABOVE_CLIENT, so want to be lower这里的注释和上面modifyRawOomAdj中的注释解释的很清楚了，意思就是说如果本进程使用BIND_ABOVE_CLIENT标记绑定某个service的话，我们需要做出一定调整，调整的方式整体都是降低优先级，根据我们上面传递进来的参数我们知道这里应该走最后一个分支，也就是说将adj的值加1，为什么是这样呢？我们看下api文档中对BIND_ABOVE_CLIENT的解释：
google的解释很清楚了，这里的意思就是说client使用BIND_ABOVE_CLIENT绑定service的话，那么client的优先级是比service要低的，虽然android系统并不会保证一定是这样。正是因为这个，上面我们的代码才将adj的值增加处理。现在我们再总结一下上面代码的逻辑，主要就是从mLruProcesses中的最顶端（index最大的）开始挨个计算oom_adj的值，然后针对计算后的值进行一定的调整，就这样。
上面我们看了oom_adj的修改机制，接下来的代码就是将mLruProcesses列表中的进程占用的内存trim一下，主要通过调用ApplicationThread的scheduleTrimMemory来实现，这个方法最终会调用到WindowManagerService的trimMemory方法要求app进程释放多余的内存，此处会回调app中Application对象的onTrimMemory方法通知app。这部分的代码和我们的oom_adj相关不是很大，因此，这部分的代码读者可以自行分析。
上面我们分析updateOomAdjLocked的时候，我们发现updateOomAdjLocked是通过调用computeOomAdjLocked方法来计算oom_adj的，那么computeOomAdjLocked究竟是怎么计算的呢？下面我们来分析一下，由于这个方法非常长（其实google应该缩短这个方法，将其拆分成几个独立的方法，这样代码的可读性更好），这里我就针对重点代码片段分析一下，大家主要理解其主要意图即可：
1). 如果是当前进程的话（TOP_APP），即包含了当前显示的activity的进程，则将他们的oom_adj设置为FOREGROUND_APP_ADJ：
if (app == TOP_APP) {
// The last app on the list is the foreground app.
adj = ProcessList.FOREGROUND_APP_ADJ;
schedGroup = Process.THREAD_GROUP_DEFAULT;
app.adjType = "top-activity";
foregroundActivities = true;
procState = PROCESS_STATE_TOP;
}2). 如果进程有instrumentation实例，说明这个app正在测试当中，这个时候它的adj应该是一个前台adj，保证尽量不被杀死：
if (app.instrumentationClass != null) {
// Don't want to kill running instrumentation.
adj = ProcessList.FOREGROUND_APP_ADJ;
schedGroup = Process.THREAD_GROUP_DEFAULT;
app.adjType = "instrumentation";
procState = ActivityManager.PROCESS_STATE_FOREGROUND_SERVICE;
}3). 如果进程注册了广播接受器，则把它的oom_adj设置为前台adj：
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;
schedGroup = (queue == mFgBroadcastQueue)
? Process.THREAD_GROUP_DEFAULT : Process.THREAD_GROUP_BG_NONINTERACTIVE;
app.adjType = "broadcast";
procState = ActivityManager.PROCESS_STATE_RECEIVER;
}4). 如果进程中有正在运行的service，则把它的oom_adj设置为前台adj：
if (app.executingServices.size() > 0) {
// An app that is currently executing a service callback also
// counts as being in the foreground.
adj = ProcessList.FOREGROUND_APP_ADJ;
schedGroup = app.execServicesFg ?
Process.THREAD_GROUP_DEFAULT : Process.THREAD_GROUP_BG_NONINTERACTIVE;
app.adjType = "exec-service";
procState = ActivityManager.PROCESS_STATE_SERVICE;
//Slog.i(TAG, "EXEC " + (app.execServicesFg ? "FG" : "BG") + ": " + app);
}5). 其他的进程就先设置oom_adj为cachedAdj，在updateOomAdjLocked中我们传递的参数是UNKNOWN_ADJ。
上面的几个步骤只是计算了进程了oom_adj的一个初始值，接下来的代码还有针对这个值继续调整，但是调整的原则就是向下调整，只有判断出进程的oom_adj的值可以更低的时候才会去改变它。
6). 如果进程有可见的activity的话，那么将它的adj设置为VISIBLE_APP_ADJ：
if (r.visible) {
// App has a visible activity; only upgrade adjustment.
if (adj > ProcessList.VISIBLE_APP_ADJ) {
adj = ProcessList.VISIBLE_APP_ADJ;
app.adjType = "visible";
}
if (procState > PROCESS_STATE_TOP) {
procState = PROCESS_STATE_TOP;
}
schedGroup = Process.THREAD_GROUP_DEFAULT;
app.cached = false;
app.empty = false;
foregroundActivities = true;
break;
}7). 如果进程的activity处于暂停或者正在暂停的情况下，adj调整为PERCEPTIBLE_APP_ADJ：
if (r.state == ActivityState.PAUSING || r.state == ActivityState.PAUSED) {
if (adj > ProcessList.PERCEPTIBLE_APP_ADJ) {
adj = ProcessList.PERCEPTIBLE_APP_ADJ;
app.adjType = "pausing";
}
if (procState > PROCESS_STATE_TOP) {
procState = PROCESS_STATE_TOP;
}
schedGroup = Process.THREAD_GROUP_DEFAULT;
app.cached = false;
app.empty = false;
foregroundActivities = true;
}8）. 如果进程的activity正在处于停止状态的话，那么adj设置为PERCEPTIBLE_APP_ADJ：
if (r.state == ActivityState.STOPPING) {
if (adj > ProcessList.PERCEPTIBLE_APP_ADJ) {
adj = ProcessList.PERCEPTIBLE_APP_ADJ;
app.adjType = "stopping";
}
// For the process state, we will at this point consider the
// process to be cached. It will be cached either as an activity
// or empty depending on whether the activity is finishing. We do
// this so that we can treat the process as cached for purposes of
// memory trimming (determing current memory level, trim command to
// send to process) since there can be an arbitrary number of stopping
// processes and they should soon all go into the cached state.
if (!r.finishing) {
if (procState > ActivityManager.PROCESS_STATE_LAST_ACTIVITY) {
procState = ActivityManager.PROCESS_STATE_LAST_ACTIVITY;
}
}
app.cached = false;
app.empty = false;
foregroundActivities = true;
}9）. 如果adj大于了PERCEPTIBLE_APP_ADJ但是进程中有设置为前台运行的service或者app被设置为前台运行，那么adj设置为PERCEPTIBLE_APP_ADJ：
if (adj > ProcessList.PERCEPTIBLE_APP_ADJ) {
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 = Process.THREAD_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 = Process.THREAD_GROUP_DEFAULT;
}
}10）. 如果进程是heavy weight进程的话，将它的adj调整为：HEAVY_WEIGHT_APP_ADJ：
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 = Process.THREAD_GROUP_BG_NONINTERACTIVE;
app.cached = false;
app.adjType = "heavy";
}
if (procState > ActivityManager.PROCESS_STATE_HEAVY_WEIGHT) {
procState = ActivityManager.PROCESS_STATE_HEAVY_WEIGHT;
}
}这里所谓的heavy weight进程就是我们传统的进程，一般的进程都是heavy weight进程，和heavy weight相对的还有light weight，这个就是指的thread。关于heavy weight进程和light weight进程差别详情请看这个博客（老外写的）：
http://www.wideskills.com/android/intrprocess-communication/threads-in-android
11）. 如果当前app进程是home进程，那么我们将它的adj设置为HOME_APP_ADJ：
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 = Process.THREAD_GROUP_BG_NONINTERACTIVE;
app.cached = false;
app.adjType = "home";
}
if (procState > ActivityManager.PROCESS_STATE_HOME) {
procState = ActivityManager.PROCESS_STATE_HOME;
}
}12）. 如果这个进程是Previous进程，并且它有activity的话，那么我们将它的adj设置为PREVIOUS_APP_ADJ：
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 = Process.THREAD_GROUP_BG_NONINTERACTIVE;
app.cached = false;
app.adjType = "previous";
}
if (procState > ActivityManager.PROCESS_STATE_LAST_ACTIVITY) {
procState = ActivityManager.PROCESS_STATE_LAST_ACTIVITY;
}
}所谓的previous进程就是当前activity的前一个activity所在的进程，这个进程需要比较高的优先级，因为用户很有可能会再次回到这个进程中。
13）. 如果进程正在备份的话，那么将它的adj设置为BACKUP_APP_ADJ:
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) {
if (DEBUG_BACKUP) Slog.v(TAG_BACKUP, "oom BACKUP_APP_ADJ for " + app);
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;
}
}14). 接下来开始处理进程中含有service组件的情况，针对每个service，分两种情况处理：
a. 如果进程的service是显式启动的（service对象的startRequested为true），而且进程还拥有activity，则将它的adj值设置为SERVICE_ADJ
b. 重新计算和service链接的其他的进程的adj值，如果service的链接标记中包含了BIND_ABOVE_CLIENT的话，那么将当前进程的adj设置为客户端的adj值；如果标记中包含了BIND_NOT_VISIBLE则将进程的adj设置为PERCEPTIBLE_APP_ADJ；否则就设置为VISIBLE_APP_ADJ
（这部分代码太长就不贴出来了，就在上面代码的下面）
15）. 接下来考虑进程中包含ContentProvider的情况，对该进程中的每个provider对象，进行如下处理：
a. 首先计算和ContentProvider链接的client进程的oom_adj值，如果当前的oom_adj值大于client的值，那么就将当前进程的adj设置为和client一样的值。这表示当前进程的重要性至少和client一样的。
b. 如果ContentProvider对象有一个应用进程和它链接，将当前进程的oom_adj调整为FOREGROUND_APP_ADJ
15）. 如果当前进程的adj大于了这个进程可以拥有的最大的adj（maxAdj）的话，那么就调整为maxAdj
总结
这里我们大概梳理一下AMS中的进程和oom_adj的管理流程，这是AMS所有的工作中比较重要的，这个是下面理解AMS的activity管理流程基础，希望本文可以帮助大家更好地理解AMS。
