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的划分
所有启动了服务的进程，且该服务所在的进程没有显示过UI，且该服务未执行startForeground（执行后会变为perveptible服务）动作，那该进程则为A-Service与B-Service中的一种。然后根据这类服务进程所处于Lru进程表中的位置，前1/3点服务为A-Service，其余的则为B-Service。
4.perceptible的标准
perceptible名为可感知的进程，但并不是说能够感知到进程就一定表示该进程属于perveptible进程，比如播放音乐的进程活着状态栏上有通知的进程，虽然能够感知到进程的存在，但是不代表进程一定时perceptible类别的进程。决定该进程是否属于perceptible进程并未进程的可感知性，而是该进程的服务是否执行了startForeground动作。
使用命令可以打出进程所属service的状态信息：
以今日头条为例：
1 | dumpsys activity services com.ss.android.article.news |
1 | adb shell |
对于常驻Service，通常使用绑定托盘的方式使之成为前台service，这样的adj值会从5或者8变为2，一般是不会清理掉的。
常驻Service方案除了基本的sticky之外，可以参考github上优雅的常驻service.原理是通过设置相同的notification ID 设置前台service，stopInnerService后，原service会被认定为前台service，并且不会弹出通知栏。
注意： 该方案在Android 7.1 及以上版本会弹出通知栏，这个其实是goolge里的漏洞，在Android 7.1上已经修复。