Android(安卓)ActivityManagerService(AMS)的进程管理
Android ActivityManagerService(AMS)的进程管理
标签: androidAMS进程管理内存管理app 2016-07-06 17:20 1201人阅读 评论(2) 收藏 举报 分类: Android升华之路之系统篇(6)版权声明:本文为博主原创文章,未经博主允许不得转载。
目录(?)[+]
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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
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 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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
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; } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
这里的逻辑很简单,主要就是根据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(); }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
我们看到,如果是一个独立的进程的话,那么首先app肯定就直接赋值为null,接下来我们会调用newProcessRecordLocked新建一个ProcessRecord对象,这个方法的具体处理因为和我们AMS的进程管理不是特别相关,我们就不分析了,感兴趣的读者可以自行分析。新建了一个ProcessRecord对象之后的操作就是最重要的操作了:
updateLruProcessLocked(app, false, null);updateOomAdjLocked();
- 1
- 2
这两步操作设计AMS管理进程的核心工作,我们稍后详细分析,我们先接下来的逻辑,接下来的逻辑中最重要的就是调用startProcessLocked方法实际启动一个进程:
startProcessLocked(app, "added application", app.processName, abiOverride, null /* entryPoint */, null /* entryPointArgs */);
- 1
- 2
在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); }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
首先需要记录一下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); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
我们看到,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); }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
再获得启动开始时间之后,当app的pid大于0并且pid不是本进程PID的话,就要把当前pid的进程从mPidsSelfLocked列表中移除,防止重复,因为后面我们还要加入;然后就是移除PROC_START_TIMEOUT_MSG消息,这个消息是AMS用来控制app启动时间的,如果启动超时了就发出效果消息,下面我们会设置这个消息,现在需要取消之前设置的消息,防止干扰。
接下来的逻辑:
mProcessesOnHold.remove(app);
- 1
这里是将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 mProcessesOnHold = new ArrayList();
- 1
- 2
- 3
- 4
- 5
- 6
接下来就要更新cpu使用统计信息:
updateCpuStats();
- 1
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(); } } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
我们发现它的逻辑很简单,首先是判断当前时间是不是和上次检查时间相差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);
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
上面代码中最核心的代码就是调用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); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
这里的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); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
这个消息是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;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
首先需要判断当前这个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;
- 1
- 2
- 3
- 4
- 5
这里的注释写的很清楚了。在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;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
就如同注释解释的那样,第一个变量总是指向列表中位置最高的带有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 mLruProcesses = new ArrayList();
- 1
- 2
- 3
- 4
- 5
我们看到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;
- 1
- 2
- 3
- 4
- 5
首先我们看到这里定义一个变量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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
这里的代码中注释写的很清楚,这里的意思就是,如果当前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; } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
上面的代码意图我的注释中已经写清楚了,基本逻辑也很简单。下面我们继续分析代码:
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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
这部分的代码主要就是要排除persistent app,这部分app不会被杀死,永远在运行,因此没有必要针对这样的app进程进行LRU排序。
if (lrui >= 0) { if (lrui < mLruProcessActivityStart) { mLruProcessActivityStart--; } if (lrui < mLruProcessServiceStart) { mLruProcessServiceStart--; } mLruProcesses.remove(lrui); }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
这部分代码逻辑也很简单,首先判断一下我们需要更新的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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
上面的代码展示了当某个应用的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++; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
到这里我们的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); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
这里的微调分为两种情况,第一是将和本进程的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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
我们前面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;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
这里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();
- 1
- 2
- 3
- 4
- 5
- 6
这里是一些变量的初始化,比较重要的是这里首先获得了位于前台的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;
- 1
- 2
它的长度是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(); }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
接下来就是将mActiveUids中的每一个UidRecord对象中的curProcState都重置为PROCESS_STATE_CACHED_EMPTY:
reset@UidRecord.java
public void reset() { curProcState = ActivityManager.PROCESS_STATE_CACHED_EMPTY; }
- 1
- 2
- 3
UidRecord是用来表示一个uid启动的进程记录,而AMS中的mActiveUids是一个SparseArray,存储了每一个uid的对应的最新运行的进程,我们看下mActiveUids定义就知道了:
/** * Track all uids that have actively running processes. */ final SparseArray mActiveUids = new SparseArray<>();
- 1
- 2
- 3
- 4
这里的注释说的很清楚了。返回到updateOomAdjLocked中,我们把mActiveUids每一个UidRecord的当前进程状态reset为PROCESS_STATE_CACHED_EMPTY,是因为我们下面需要给他一个合适的值。
我们继续查看updateOomAdjLocked接下来的代码:
mAdjSeq++; mNewNumServiceProcs = 0; mNewNumAServiceProcs = 0;
- 1
- 2
- 3
首先更新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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
上面的代码就是获得系统有关后台进程数目的限制设置,系统中后台进程总数目不能超过mProcessLimit个,这个变量的初始值是:
int mProcessLimit = ProcessList.MAX_CACHED_APPS;
- 1
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;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
我们看到了,初始值系统中的所有后台进程,也就是空进程和cache进程的总和不能超过32个。但是,用户可以设置这个值,在settings的开发者选项中可以设置,如下图:
用户可以点击上图中的“后台进程限制”来设置对应的值。
不过一般情况下,这个值都是32.现在我们就以32为值来分析一下代码,我们看到上面的代码中最终会走到最后一个分支,这个分支中针对emptyProcessLimit和cachedProcessLimit分别赋值,emptyProcessLimit的值是通过ProcessList的computeEmptyProcessLimit获取的:
computeEmptyProcessLimit@ProcessList.java
public static int computeEmptyProcessLimit(int totalProcessLimit) { return totalProcessLimit/2; }
- 1
- 2
- 3
我们看到这里的操作很简单,直接把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;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
这段代码首先计算了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++; } }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
上面代码中我的注释将这段程序的基本逻辑描述了,这里就不再赘述。这里需要额外说明一下,我们上面通过调用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; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
这里的操作分两种情况:如果hasAboveClient为true和false。hasAboveClient定义如下:
boolean hasAboveClient; // Bound using BIND_ABOVE_CLIENT, so want to be lower
- 1
这里的注释和上面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;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
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;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
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;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
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);}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
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;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
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;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
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;}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
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; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
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; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
这里所谓的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; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
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; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
所谓的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; }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
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。
更多相关文章
- Android高手进阶教程(十一)--Android(安卓)通用获取Ip的方法(判
- CardView 添加背景图片、改变颜色、水波纹效果的方法
- 浅谈Android系统进程间通信(IPC)机制Binder中的Server和Client获得
- Android视图加载到窗口的过程分析
- 将 cglib 动态代理思想带入 Android(安卓)开发
- 在Android(安卓)中使用KSOAP2调用WebService(一)
- Android之android:launchMode
- 浅谈Java中Collections.sort对List排序的两种方法
- Python list sort方法的具体使用