android oom killer 进程回收机制

转自：http://book.51cto.com/art/201109/291363.htm

10.2.2  Android与Linux的配合

关于内存回收的时机，Android官方文档提出，Activity所占用的内存在一般情况下不会被回收，只有在系统内存不够用的时候才会回收，并且回收时会有一个潜规则。大致情况是前台Activity最后回收，其次是包含前台的Service或者Provider，再次是后台Activity，最后是后台空进程。而这种机制就意味着AmS需要和Linux操作系统有个约定，因为"系统内存是否够用"属于Linux内核的内存管理控制的事情，AmS是无法预知的。

你可能会想，AmS是运行在Java环境中的，当Java进行内存分配时，如果发生Out Of Memory不就知道系统内存低了吗？事实并非如此，这有两个原因：

尽管AmS运行在Java环境里，但是应用程序和AmS运行在两个独立的Java虚拟机中，应用程序申请内存并不会通知AmS，所以AmS无法感知应用程序申请内存的状况，除非每次应用程序申请内存并发生Out Of Memory时通知AmS，但实际却没有。

Java虚拟机运行时都有各自独立的内存空间，应用程序A发生Out Of Memory并不意味着应用程序B也会发生Out Of Memory，很有可能仅仅是A程序用光了自己内存的上限，而系统内存却还是有的。

以上说明，单纯的AmS是无法获知系统内存是否低的。

那么，什么是"系统内存低"或者"系统内存不够用"呢？从Android底层的Linux来讲，由于其并未采用磁盘虚拟内存机制，所以应用程序能够使用的内存大小完全取决于实际物理内存的大小，所以，"内存低"的含义就是实际物理内存已经被用得所剩无几了。而这又是如何与AmS联系到一起的呢？如图10-19所示。

图10-19  Android中内存OOM机制示意图

在Android中运行了一个OOM 进程，即Out Of Memory。该进程启动时会首先向Linux内核中把自己注册为一个OOM Killer，即当Linux内核的内存管理模块检测到系统内存低的时候就会通知已经注册的OOM进程，然后这些OOM Killer就可以根据各种规则进行内存释放了，当然也可以什么都不做。

Android中的OOM Killer进程是仅仅适用于Android应用程序的，该进程在运行时，AmS需要把每一个应用程序的oom_adj值告知给Killer。这个值的范围在－16到15，值越低，说明越重要，这个值类似于Linux系统中的进程nice值，只是在标准的Linux中，有其自己的一套Killer机制。

当发生内存低的条件时，Linux内核管理模块通知OOM Killer，Killer则根据AmS所告知的优先级，强制退出优先级低的应用进程。

以上就是Android和Linux关于内存管理的配合，分析完相关代码可知，OOM Killer是一种可选的方案，对于OEM厂商来讲，完全可以不支持OOM，只有在不支持的情况下，Android才会采用之前所声称的"潜规则"优先退出后台的Activity。这个结论很重要，因为在现在主流的Android平台中都包含了OOM Killer模块，这就意味着AmS仅仅是根据应用进程前后台的关系给其分配一个oom_adj值，剩下的就是oom_killer要干的事情了。