OOM问题原理解析（一）：adj内存管理机制

*本文主要介绍Android的lowmemorykiller的oom_adj的相关概念，以及根据一些案例来阐述了解oom_adj对于做Android应用开发的重要意义。*

*一、lowmeorykiller中进程的分类以及各类进程的adj值*

​ *在Android的lowmemroykiller机制中，会对于所有进程进行分类，对于每一类别的进程会有其oom_adj值的取值范围，oom_adj值越高则代表进程越不重要，在系统执行低杀操作时，会从oom_adj值越高的开始杀。********系统lowmemeorykiller机制下对于进程的级别的以变量的形式定义在framework/base/core/java/com/android/server/am/ProcessList.java类中，可总结成下表：*

*再补充介绍一下：*

*1.AMS角度对于进程的分级*

*上表带分级只是从lowmemroykiller角度来分的，时用于lowmemeorykiller执行杀进程操作，但是从android的系统管理角度看，即是从AMS执行相关逻辑时，又有一套自己的分级机制，当然这两套机制也有着很多互通的点。AMS角度的级别划分以变量的形式定义在framework/base/core/java/android/app/ActivityManager.java类中，以PROCESS_STATE开头的变量。*

*2.没有stopService其内含activity的后台进程*

​ *这类进程从lowmemorykiller角度是划分为cached，因为如果这类进程往往占有较大的内存，这类含有activity的后台进程往往占有较大内存，所以即使这类进程包含了Service，lowmemorykiller的机制也会更加倾向于优先杀死这类进程。*

​ *但是一般启动了服务的进程往往是希望服务在后台能够执行某些任务，这样看是不希望这些服务因为进程被杀而过早的被终止的，那如何调和这种矛盾呢？正确的做法是，对于期望较长时间留在后台的服务，应该将服务运行在单独的进程里，即是UI进程与Servie进程分离，这样期望长时间留在后台的Serivce会存在与一个被lmk分类为Service 进程的服务而获得较小的Adj值，而占有大量内存的UI进程则会分类为Cached进程，能够在需要的时候更快地被回收。*

​ *还有一点，这类进程虽然被lmk划分为cached进程，但是从ams角度是被划分为PROCESS_STATE_SERVICE这个类别的，即视为服务进程，在ams相关流程中也是以服务进程来执行相关逻辑的，此外在使用dumpsys meminfo查看所有进程时，这类进程也是被列在B service这个类别的。*

*3.A-Service与B-Service的划分*

​