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

​ *但是一般启动了服务的进程往往是希望服务在后台能够执行某些任务，这样看是不希望这些服务因为进程被杀而过早的被终止的，那如何调和这种矛盾呢？正确的做法是，对于期望较长时间留在后台的服务，应该将服务运行在单独的进程里，即是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动作。*

*二、如何查询应用的adj级别*

*1.dumpsys meminfo*

​ *使用dumpsys meminfo命令时，会列出当前系统的所有进程，不同进程放入不同的分类，对应的分类名基本与lmk的分类一致。有一点不同的就是，退到后台启动了服务且显示过UI的进程，在dumpsys meminfo命令中会归为b service一类，但从lmk角度分配的oom_adj值为9~16的范围，属于cached一类*

*2.cat /proc/[PID]/oom_adj: 使用该命令会直接显示出对应进程号的adj值*

*三、未控制好oom_adj的案例