谈一谈Android内存优化那些事（一）内存分配与回收机制

今天我们来聊一聊Android 内存优化那些事，这篇文章本来很早就应该写了，但因为最近事情有点忙，所以这个就拖到了现在才开始，不过我觉得也不晚。

由于内容比较多，我从三个方面分为三篇对Android内存优化进行介绍：

Android内存分配与回收机制

Android常用的内存优化方法

Android内存分析与监控

文章不会涉及到native内存的优化，因为普通App开发中涉及的较少

Android内存分配与回收机制

想要优化Android内存，一些必备的基础知识是不能少的。所以在第一部分，我们先从Application Framework、Dalvik/Art、Linux内核三个部分由浅入深来讲解关于Androd内存相关的知识。

###1. Application Framework

首先来看下进程的优先级：

前台进程：用户当前操作所必需的进程。

可见进程：没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程。

服务进程：正在运行已使用 startService() 方法启动的服务。（后台播放音乐，网络下载数据）

后台进程：对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）

空进程：不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存，以缩短下次在其中运行组件所需的启动时间

进程生命周期：Android 系统将尽量长时间地保持应用进程，但为了新建进程或运行更重要的进程，最终需要移除旧进程来回收内存。为了确定保留或终止哪些进程，系统会根据进程中正在运行的组件以及这些组件的状态，将每个进程放入“重要性层次结构”中。必要时，系统会首先消除重要性最低的进程，然后是重要性略高的进程，来回收系统资源。（一般情况下前台进程就是与用户交互的进程了,如果连前台进程都需要回收那么此时系统几乎不可用了）。由此也衍生了很多进程保活的方法（提高优先级，互相唤醒，native保活等等），出现各种杀不死的进程的APP。

最后我们需要知道：Android中由ActivityManagerService 类集中管理所有进程的内存资源分配，我们可以查看其源码来具体分析实现过程。

2.Dalvik/Art 虚拟机

Android Dalvik Heap

简介：Android Dalvik Heap与原生Java一样，将堆的内存空间分为三个区域，Young Generation新生代，Old Generation年老代， Permanent Generation持久代。

对象分配过程：最近分配的对象会存放在新生代区域，新生代区域分为eden区（伊甸园，圣经中指上帝为亚当夏娃创造的生活乐园）、so区和s1区，s1和s0区也被称为from区和to区（合称Survivor区），他们是两块大小相等并且可以互换角色的空间，绝大多数情况下,对象首先分配在eden区，在一次新生代回收后，如果对象还存活会进入s0或者s1区，之后每一次gc，存活的对象年龄都会相应增加，当达到一定年龄则会进入老年代，最后累积一定时间再移动到持久代区域。系统会根据内存中不同的内存数据类型分别执行不同的gc操作。

问题：GC发生的时候，所有的线程都是会被暂停的。执行GC所占用的时间和它发生在哪一个Generation也有关系，新生代中的每次GC操作时间是最短的，年老代其次，持久代最长。GC时会导致线程暂停、界面卡顿的问题在Android Art中得到了优化。

Dalvik虚拟机执行模式

Dalvik垃圾回收过程：GC会去标记和查找所有可访问到的活动对象，这个时候整个程序的线程就会挂起，并且虚拟机内部的所有线程也会同时挂起(左下图) 。之所以要挂起所有线程是确保：所有程序没有进行任何变更，与此同时GC会隐藏所有处理过的对象，最终确保标记了所有需要回收的对象后，GC才会恢复所有线程，并释放空间。

大内存对象分配：当发现需要给一个较大的对象(蓝色方块)分配空间时，发现可用空间还是够的，但没有这么大的连续空间供新对象使用，这个时候就不得不进行一次GC回收（红色方块，右下图），为大对象腾出较大并且连续的空间。这就是我们在分配一个较大对象的时候非常容易引起丢帧和卡顿的原因之一，所以Android5.0以前大家都认为Android卡顿是因为Darvik虚拟机的效率低下导致的。

总结：Dalvik虚拟机的三个问题

GC时挂起所有线程
大而连续的空间紧张
内存碎片化严重

ART虚拟机的优化

GC过程：在ART中GC会要求程序在分配空间的时候标记自身的堆栈，这个过程非常短，不需要挂起所有程序的线程.这样就节约了很大一部分时间去查找活动对象。

大内存对象分配：ART里会有一个独立的LOS供Bitmap使用，从而提高了GC的管理效率和整体性能.

内存碎片化在ART里还会有一个moving collector来压缩活动对象(绿色方块)，使得内存空间更加紧凑。

总结 ：Google在ART里对GC做了非常大的优化(更高效的回收算法),使ART内存分配的效率提高了10倍，GC的效率提高了2-3倍（可见原来效率有多低），不过主要还是优化中断和阻塞的时间，频繁的GC还是会导致卡顿。

###3.Linux内核

Lowmemorykiller：ActivityManagerService中trimApplications() 函数中会执行一个叫做 updateOomAdjLocked() 的函数，updateOomAdjLocked 将针对每一个进程更新一个名为 adj 的变量，（用来表示发生内存不足时杀死进程的优先级顺序）并将其告知 Linux 内核，内核同样维护一个包含 adj 的数据结构（即进程表），并通过 lowmemorykiller 检查系统内存的使用情况，在内存不足时，遍历所有进程，选出低优先级的进程杀死，最终由内核去完成真正的内存回收。

Oom_killer ：如果上述各种方法都无法释放出足够的内存空间，那么当为新的进程分配内存时将发生 Out of Memory 异常，OOM_killer 将尽最后的努力杀掉一些进程来释放空间。Android 中的oom_killer同样会遍历进程，并计算所有进程的 badness 值，选择 badness 最大的那个进程将其杀掉。

Oom的条件：只要allocated + 新分配的内存 >= dalvik heap(堆内存) 最大值的时候就会发生OOM（Art运行环境的统计规则还是和dalvik保持一致）

4.内存不优化会导致哪些问题？

上面介绍了Android内存分配从应用层到Linux层的一些知识，所以我总结出上图内存会导致的一些问题，但是上图只是列出了一些常见情况，前后并没有绝对的因果关系，最后来说下内存抖动。

内存抖动：Memory Churn，内存抖动是因为在短时间内大量的对象被创建又马上被释放。瞬间产生大量的对象会严重占用内存区域，当达到阀值，剩余空间不够的时候，会触发GC从而导致刚产生的对象又很快被回收。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力，从而触发更多其他类型的GC。这个操作有可能会影响到帧率，并使得用户感知到性能问题。