概述

Android系统的进程管理理念是希望应用进程能够尽量长时间的存活，提升用户体验。Android的应用进程在首次启动的时候会比较慢，因为第一次启动的时候包含了进程的创建以及Application等信息的初始化，这个过程会消耗一定的时间，所以应用在启动以后，不会轻易被杀死掉，以达到在下一次启动的时候加快速度。同样APP自己也会使用一些手段，希望自己长时间存活。设备的内存以及一些资源是有限的，不可能承载无限多的进程运行，当进程达到一定的数量，大量消耗设备内存后，手机设备性能就会下降，如果放任所有进程一直存活下去，设备内存很快就会消耗完毕。

所以系统需要杀死一些进程对内存进行回收，确保系统可以稳定的一直运行下去。但是哪些进程应该被杀掉呢？Android系统会根据进程中的组件状态来决定一个进程的优先级adj值，优先级最低的进程会最先被杀掉，依次类推，来确保系统正常运转。

AMS对进程的描述

Android 中AMS服务负责进程的创建和销毁，Android系统对用户屏蔽了进程的概念，用户在开发自己的应用的时候无需太关系进程相关的处理。

进程在AMS中由一个ProcessRecord来表示，该对象记录了一个进程的所有信息，但是ProcessRecord在AMS服务中只是代表一个进程，真正的应用进程运行在独立的进程中，主线程是ActivityThread。ProcessRecord的变量IApplicationThread thread用来关联真正的进程，IApplicationThread是一个binder类，当他不为空的时候，thread持有了Binder的代理端，而服务端实现在ActivityThread中。

Untitled Diagram (9).png

AMS可以通过IApplicationThread通知对应的进程做一些对应的操作。
ProcessRecord详情可参考ProcessRecord分析

AMS服务创建进程

既然AMS负责管理进程，那么AMS是怎么创建一个进程的呢？在什么场景下会创建新的进程呢？

进程的创建场景

启动Activity的时候，如果当前Activity的宿主进程尚未创建，则需要先创建对应的进程

ActivityStackSupervisor::startSpecificActivityLocked()

启动一个Service组件的时候，Service组件的宿主进程尚未创建，需要先创建对应的进程

ActiveServices::bringUpServiceLocked()

获取一个ContentProvider组件连接的时候，ContentProvider宿主进程尚未创建且ContentProvider组件必须运行在其宿主进程中，需要先创建对应的进程

ActivityManagerService::getContentProviderImpl()

如果发送一个广播的时候，发现接收该广播的Receiver是静态注册的广播，且注册该广播的进程尚未启动，则需要先创建对应的进程

BroadcastQueue::processNextBroadcast()

backup组件

ActivityManagerService::bindBackupAgent()

systemServer进程启动的时候，persistent进程会被启动

addAppLocked()

进程创建流程

从AMS的进程列表中查询对应的ProcessRecord信息
如果AMS进程列表中未找到对应的ProcessRecord信息，说明进程还未启动，需要创建新的进程
创建一个ProcessRecord来描述要创建进程的信息，并进程初始化，保存到AMS的ProcessRecord列表中，此时的ProcessRecord值保存了基本的信息，尚未和一个真正的进程进行关联
为新启动进程设置必须的参数
调用Process.start来启动一个新的进程
将参数通过socket发送给Zygote进程，Zygote进程fork出一个新的进程，返回新创建的进程pid
将进程的Pid保存到ProcessRecord对象的pid变量中. AMS端创建进程的逻辑就执行完成了。
Zygote fork出的新进程会执行ActivityThread.main方法，初始化新的进程，此时一个新的进程真正的运行起来了，同时也创建了一个IApplicationThread的服务端用于接收AMS的消息.
新进程调用AMS.attachApplicationLocked方法，将IApplicationThread的代理端发送给了AMS, AMS查找到对应的ProcessRecord对象，将Binder代理端保存到ProcessRecord的thread变量中，此时ProcessRecord对象和一个进程就关联起来了。

AMS服务查杀进程

杀死进程的方法有那些？

方法名称	方法描述	调用角色
System.exit(0)	退出虚拟机	应用
killProcessGroup(int uid, int pid)	杀死pid所在进程组内的所有进程	系统应用
killPids(int[] pids, String pReason, boolean secure)	只有系统UID可以调用，根据指定的pid信息计算一个worstType, 小于某一个adj的进程会被杀死，不能保证指定的pid进程一定被杀掉	系统
killUid(int appId, int userId, String reason)	杀死UID下所有的进程， system_server和native进程除外	系统应用
killApplication(String pkg, int appId, int userId, String reason)	只有系统Uid可以调用，强制杀死某一个应用	系统
killApplicationProcess(String processName, int uid)	系统uid才能调用，通过进程见调用通知进程自杀	系统
killAllBackgroundProcesses()	杀死所有优先级小于CACHE的进程，需要权限	系统
killBackgroundProcesses(final String packageName, int userId)	杀死指定Package下所有优先级小于Service的进程	系统
killProcessesBelowForeground(String reason)	杀死优先级小于FOREGROUND的进程	系统
killProcessesBelowAdj(int belowAdj, String reason)	杀死优先级小于指定值的进程	系统
killPackageDependents(String packageName, int userId)	杀死指定Package所有优先级小于FOREGROUND的进程	系统
killPackageProcessesLocked	杀死指定package下小于指定优先级的进程，非系统UID只能杀死自己进程	系统应用

以上方法提供了杀死进程的接口，用于应用或者系统主动杀死一些进程。这些进程会调用一些方法

handleAppDiedLocked() 进程被杀死后的善后处理
参考binderDied()过程分析
forceStopPackageLocked() 强制杀死对应进程

AMS自己会根据一些逻辑来杀死部分进程， App也会主动调用ActivityManager的接口来杀死指定进程，当进程侥幸逃脱AMS或者应用的屠刀后，就会被保存到内存中，此时这些进程就会交由LowMemoryKiller来监控了，这些进程的生死就转移到了LMK的手上.

LMK进程监控查杀

需要监控的进程，ProcessList会通过socket将他的进程id添加到lmkd的进程列表中，同时，如果进程被杀死了，则需要通ProcessList通过socket接口通过lmkd从列表中移除。这个列表就是lmkd监控的进程列表,详情参考LowMemoryKiller的实现

Android设备原始的adj阀值如图：

原始内存阀值

Android进程分为了6个等级，对应不同内存阀值，当lmkd监控的系统内存小于某一个阀值的时候，就会开始查杀小于或等于对应优先级的进程，当释放的内存达到最大阀值之后就停止查杀。

前台进程 FOREGROUND_APP_ADJ (0)

前台进程是指那些有组件正和用户进行交互的应用程序的进程，也称为Active进程。这些都是Android尝试通过回收其他应用程序来使其保持相应的进程。这些进程的数量非常少，只有等到最后关头才会终止这些进程，是用户最不希望终止的进程。例如：而当你运行浏览器这类应用时，它们的界面就会显示在前台，它们就属于前台进程，当你按home键回到主界面，他们就变成了后台程序。
如果一个进程满足以下任一条件，即视为前台进程：
（1）托管处于活动状态的Activity，也就是说，它们位于前台并对用户事件进行响应，此时的情形为响应了Activity中的onResume()生命周期方法，但没有响应onPause()。
（2）托管正在执行onReceive()方法处理事件程序的BroadcastReceiver。
（3）托管正在执行onStart()、onCreate()或onDestroy()事件处理程序的Service。
（4）托管正在运行且被标记为在前台运行的Service，即调用了该Service的startForeground()方法。
（5）托管某个Service，且该Service正绑定在用户正在交互的Activity的Service，即该Activity正处于活动状态。

可见进程 VISIBLE_APP_ADJ (100)

没有任何前台组件、但仍然会影响用户在屏幕上所见内容的进程。如果一个进程满足以下任一条件，即视为可见进程：
（1）托管不在前台、但仍对用户可见的Activity（已调用其onPause（）方法）。例如：如果前台Acitivty启动了一个对话框，或者启动了一个非全屏，亦或是一个透明的Activity，允许在其后显示上一个Activity，则可能会发生这种情况，这类Activity不在前台运行，也不能对用户事件作出反应。
（2）托管绑定到可见Activity的Service
可见进程被视为是极其重要的进程，这类进程的数量也很少，只有在资源极度匮乏的环境下，为保证前台进程继续执行时才会终止。

可感知进程 PERCEPTIBLE_APP_ADJ (200)

用户可以感知到的进程，如后台播放音乐的进程

备份进程 BACKUP_APP_ADJ (300)

处于备份过程中的进程

CACHED_APP_MIN (900)

缓存进程ADJ最小值

CACHED_APP_MAX (906)

缓存进程ADJ的最大值

lmkd根据以上6个等级对进程进程查杀，只要内存阀值达到某个等级，小于该优先级等级的进程都属于查杀对象。

当进程被LMK杀死后，binder死亡通知会通知AMS, AMS执行handleAppDiedLocked来进程善后处理。清理该进程的信息，并将该进程从AMS中移除。
LMK对进程的查杀是依赖adj等级的，但是进程adj如何进行分配的？这就要看下AMS对进程adj的管理策略。

AMS对保存在内存中的进程管理策略

Android对进程管理是最大限度的将进程保留在内存中，在内存不够的时候杀死一些不重要的进程，如何决定哪些进程是不重要的，哪些进程是重要的，以及如何杀死进程，这个就是Android进程管理的策略。

优先级分类

ADJ取值	进程类别	含义
-1000	NATIVE_ADJ	native进程
-900	SYSTEM_ADJ	System_server进程
-800	PERSISTENT_PROC_ADJ	系统persistent进程
-700	PERSISTENT_SERVICE_ADJ	系统或者persistent进程绑定的进程
0	FOREGROUND_APP_ADJ	前台进程：和用户交互的进程，不到万不得已不能杀死
100	VISIBLE_APP_ADJ	可见进程：该进程的某个UI组件是可以被用户看见的，但是没有和用户进行交互，不能随便杀死，影响用户体验
200	PERCEPTIBLE_APP_ADJ	可感知进程：该进程的某个组件可以被用户感知到，如后台音乐播放
300	BACKUP_APP_ADJ	备份进程：不可轻易打断，否则容易引起不可修复的数据错误
400	HEAVY_WEIGHT_APP_ADJ	重量级进程
500	SERVICE_ADJ	服务进程
600	HOME_APP_ADJ	Lanucher进程
700	PREVIOUS_APP_ADJ	上一个访问的进程
800	SERVICE_B_ADJ	B list中的进程
900	CACHED_APP_MIN_ADJ	不可见进程adj最小值
906	CACHED_APP_MAX_ADJ	不可见进程adj最大值
1001	UNKNOWN_ADJ	错误的adj值

Android将进程的优先级分为以上几种，从表格中可以看出，值越小优先级越高，小于0的优先级的进程基本上不会被杀死的，这些都是系统的重要进程，杀死之后会影响到整个系统的运行。

进程的优先级是如何分配的呢？
Android的ProcessRecord中有adj变量，代表当前进程的优先级，每当系统中的进程组件发生变化，就会调整某个或者调整全部进程的adj优先级。

进程的LRU列表管理

在AMS服务中对于进程管理有一系列保存进程信息ProcessRecord的容器，其中mLruProcesses列表用于按照进程的最近的使用情况，对进程进行排序保存.

 final ArrayList mLruProcesses = new ArrayList();

AMS将mLruProcesses列表分成了三个区域，使用两个变量来记录三个区域的分割点

mLruProcessServiceStart 表示从这个位置之后存放包含Service相关组件的进程信息
mLruProcessActivityStart 表示从这个位置之后存放包含Activity相关组件的进程信息

LRU列表

LRU列表中进程位置调整主要遵循的策略如下:

如果当前正在和用户交互的进程放在列表的尾部
如果包含Activity的进程，但是却不是Top进程的，放到尾部倒数第二位置
如果只包含Service的进程，放到Service部分的尾部
如果其他进程，则放到其他进程部分的尾部
调整完当前进程的位置后，还需要调整当前进程所依赖进程的优先级，比如依赖另一个进程的Service或者Provider，则不希望其进程被kill掉。调整依赖进程优先级的逻辑总体如下:

如果其他进程的位置被自己进程位置靠后，说明自己依赖进程优先级本身就是比自己进程高的，这时候不需要处理

如果依赖进程的是包含有Acitivity组件的，也不需要处理

如果依赖进程的位置比自己靠前，优先级被自己低，则要适当的将其位置往后调，因为越靠近LRU列表尾部的进程，说明该进程刚刚运行过，重要性比较高.

根据以上一系列逻辑之后，进程在LRU列表中的位置就调整完了，但是，不是要调整进程的优先级adj么？调整LRU做什么呢？LRU Cache中存放的进程是根据最近使用过的来排顺序的，越是最近使用的越是靠近列表尾部，当然分为三个区域的。LRU列表调整完成之后，adj调整的时候就会根据LRU列表尾部开始循环遍历计算进程的adj值, 最近使用的进程adj值会被先计算。

并不是所有的进程都会被计算adj值，保存到内存中，在内存中保存到进程是有限制的，比如系统会限制Cache类型的进程和Empty类型的进程每种最多保存16个，也就是最多32个. 超过32个之后的进程会被直接杀死。也就是说LRU列表中靠近底部的很久未使用的进程很可能会被AMS直接杀死，根本不会保存到内存中。

进程优先级计算

优先级 < 0的系统重要进程

NATIVE_ADJ(-1000)：是由init进程fork出来的Native进程，并不受system管控；

SYSTEM_ADJ(-900)：是指system_server进程；

PERSISTENT_PROC_ADJ(-800): 是指在AndroidManifest.xml中申明android:persistent=”true”的系统(即带有FLAG_SYSTEM标记)进程，persistent进程一般情况并不会被杀，即便被杀或者发生Crash系统会立即重新拉起该进程。

PERSISTENT_SERVICE_ADJ(-700)：是由startIsolatedProcess()方式启动的进程，或者是由system_server或者persistent进程所绑定(并且带有BIND_ABOVE_CLIENT或者BIND_IMPORTANT)的服务进程

以上进程都是系统重要进程，其adj优先级是在启动的时候就设置好，无需重新计算其优先级。

FOREGROUND_APP_ADJ (0) 前台进程

1：满足以下任一条件的进程都属于FOREGROUND_APP_ADJ(0)优先级：
正处于resumed状态的Activity
正执行一个生命周期回调的Service（比如执行onCreate,onStartCommand,onDestroy等）
正执行onReceive()的BroadcastReceiver
通过startInstrumentation()启动的进程
场景2：当客户端进程activity里面调用bindService()方法时flags带有BIND_ADJUST_WITH_ACTIVITY参数，并且该activity处于可见状态，则当前服务进程也属于前台进程，源码如下：
场景3: 对于provider进程，还有以下两个条件能成为前台进程：
当Provider的客户端进程ADJ<=FOREGROUND_APP_ADJ时，则Provider进程ADJ等于FOREGROUND_APP_ADJ
当Provider有外部(非框架)进程依赖，也就是调用了getContentProviderExternal()方法，则ADJ至少等于FOREGROUND_APP_ADJ

VISIBLE_APP_ADJ (100) 可见进程

当ActivityRecord的visible=true，也就是Activity可见的进程。
可见进程VISIBLE_APP_ADJ(100)跟PERCEPTIBLE_APP_ADJ(200)可感知进程之间有99个槽，用于细化可见进程的adj值.

调用rankTaskLayersIfNeed对TaskRecord进行排序，按照TaskRecord对VisibleApp进行细化

ActivityStack.png

PERCEPTIBLE_APP_ADJ(200) 可感知进程

foregroundServices非空：前台服务进程，执行startForegroundService()方法
app.forcingToImportant非空：执行setProcessImportant()方法，比如Toast弹出过程。
hasOverlayUi非空：非activity的UI位于屏幕最顶层，比如显示类型TYPE_APPLICATION_OVERLAY的窗口

BACKUP_APP_ADJ(300) 备份进程

执行bindBackupAgent()过程，设置mBackupTarget值；
执行clearPendingBackup()或unbindBackupAgent()过程，置空mBackupTarget值；

HEAVY_WEIGHT_APP_ADJ(400) 重量级进程

realStartActivityLocked()过程，当应用的privateFlags标识PRIVATE_FLAG_CANT_SAVE_STATE，设置mHeavyWeightProcess值；
finishHeavyWeightApp(), 置空mHeavyWeightProcess值

SERVICE_ADJ(500) 服务进程

没有启动过Activity，并且30分钟之内活跃过的服务进程

HOME_APP_ADJ(600) Launcher进程

当类型为ACTIVITY_TYPE_HOME的应用启动后会设置mHomeProcess，比如桌面APP。

PREVIOUS_APP_ADJ(700) 上一个活动的进程

用户上一个使用的包含UI的进程，为了给用户在两个APP之间更好的切换体验，将上一个进程ADJ设置到PREVIOUS_APP_ADJ的档次。当activityStoppedLocked()过程会更新上一个应用

当provider进程，上一次使用时间不超过20S的情况下，优先级不低于PREVIOUS_APP_ADJ

SERVICE_B_ADJ(800) B类服务进程

A类Service占比过高：当A类Service个数 > Service总数的1/3时，则加入到B类Service。
内存紧张&&A类Service占用内存较高：当系统内存紧张级别(mLastMemoryLevel)高于ADJ_MEM_FACTOR_NORMAL，且该应用所占内存lastPss大于或等于CACHED_APP_MAX_ADJ级别所对应的内存阈值的1/3

以上内存参考解读Android进程优先级ADJ算法, 该文章分析更加详细

Cached和Empty进程 (900 ~ 906)
Android默认对cached进程和Empty进程有最大数量限制为32个，Cached进程和Empty进程默认上限分别都是16个。

Untitled Diagram-2.png

系统将900 ～ 906 这几个adj的值分成6个卡槽，分别用来放缓存进程和空进程
分别计算当前共有多少个空进程和缓存进程，分别平均放到对应的卡槽中，每个卡槽中可能会放多个进程. 每种类型的进程超过16个之后就直接kill掉，不再为其分配adj有lmk监控了.

进程优先级设置

ProcessList.setOomAdj(app.pid, app.uid, app.curAdj);

其他调整

Android进程优先级ADJ的每一个ADJ级别往往都有多种场景，使用adjType完美地区分相同ADJ下的不同场景；不同ADJ进程所对应的schedGroup不同，从而分配的CPU资源也不同，schedGroup大体分为TOP(T)、前台(F)、后台(B)； ADJ跟AMS中的procState有着紧密的联系。

adj：通过调整oom_score_adj来影响进程寿命(Lowmemorykiller杀进程策略)；
schedGroup：影响进程的CPU资源调度与分配；
procState：从进程所包含的四大组件运行状态来评估进程状态，影响framework的内存控制策略。比如控制缓存进程和空进程个数上限依赖于procState，再比如控制APP执行handleLowMemory()的触发时机等。

Android进程管理总结

目录

概述