Android 性能优化：内存优化（理论篇）

内存作为App程序运行最重要的资源之一，需要运行过程中做到合理的资源分配与回收，不合理的内存占用轻则使得用户应用程序运行卡顿、ANR、黑屏，重则导致用户应用程序发生 OOM（out of memory）崩溃。喜马直播随着近些年的业务迭代功能不断完善玩法丰富，需要在各种机器资源上保持优秀的流畅性和稳定性，内存优化是必须要重视的环节。

从目前的内存水位和APM建设入手，梳理统计规则和项目真实内存水位，在代码和业务多方面熟悉和归因，搭配工具建设和使用为抓手，最后通过内存专项治理将应用的 OOM优化到合理水位。

限于篇幅和功能性，文章总共分为理论篇和实践篇两个部分。

写这篇文章动机，主要是工作中进行内存优化专项，便于将以往琐碎的内存知识和优化思路整合，所以有了这篇文章，感谢前人的经验。谨以此篇文章记录工作思路及基础知识，温故知新。

思维导图

内存基础知识

Android 最新系统都运行在ART虚拟机上，基于 Linux 内核实现，Linux的内存管理哲学是：Free memory is wasted memory。即内存没有得到充分利用就是在浪费内存。因此 Linux 希望尽可能多的使用内存，较少磁盘 IO 。Android 系统继承了 Linux 的优点，同样是尽最大限度使用原则。

与Linux不同的是 Android 侧重于可能多的缓存进程以提高应用启动和切换速度。即，Android系统会在内存中尽量的长时间的保持应用进程，直到系统分配内存不足时才会去根据进程优先级、内存代销等条件回收进程。这些保留在内存中的进程通常不会影响系统整体的运行速度，反而会在用户再次激活这些进程时，加快进程的启动速度。

在内存管理上，JVM拥有垃圾内存回收的机制，自身会在虚拟机层面自动分配和释放内存，因此不需要像使用C/C++一样在代码中分配和释放某一块内存。Android系统的内存管理原理基础就是JVM，通过new关键字来为对象分配内存，内存的释放由GC来回收。并且Android系统在内存管理上有一个 Generational Heap Memory模型，当内存达到某一个阈值时，系统会根据不同的规则自动释放可以释放的内存。即便有了内存管理机制，但是，如果不合理地使用内存，也会造成一系列的性能问题，比如 内存泄漏、内存抖动、短时间内分配大量的内存对象，接下来详细记录下Android内存管理模式及知识点。

Jvm内存分配模型

JVM 将整个内存划分为了几块：

1. 方法区：存储类信息、常量、静态变量等。（所有线程共享）
2. 虚拟机栈：存储局部变量表、操作数栈等。
3. 本地方法栈：不同于虚拟机栈为 Java 方法服务、它是为 Native 方法服务的。
4. 堆：内存最大的区域，每一个对象实际分配内存都是在堆上进行分配的，，而在虚拟机栈中分配的只是引用，这些引用会指向堆中真正存储的对象。此外，堆也是垃圾回收器（GC）所主要作用的区域，并且，内存泄漏也都是发生在这个区域。（所有线程共享）
5. 程序计数器：存储当前线程执行目标方法执行到了第几行。

Android内存分配

Android Runtime有两种虚拟机，Dalvik 和 ART，堆实际上就是一块匿名共享内存。Android虚拟机仅仅只是把它封装成一个 mSpace，由底层C库来管理，并且仍然使用libc提供的函数malloc和free来分配和释放内存。

大多数静态数据会被映射到一个共享的进程中。常见的静态数据包括Dalvik Code、app resources、so文件等等。Android通过显示分配共享内存区域（如Ashmem或者Gralloc）来实现动态RAM区域能够在不同进程之间共享的机制。例如，Window Surface在App和Screen Compositor之间使用共享的内存，Cursor Buffers在Content Provider和Clients之间共享内存。下面简单总结下我理解的堆结构：

Dalvik

Linear Alloc 、 Zygote Space 和 Alloc Space

ART

（重点汇总下）

• Zygote Space: 包含由 Zygote 进程预加载并在所有应用程序之间共享的对象。
• Allocation Space：用于存储应用程序在运行时创建的对象，主要的GC工作区域，为每个进程独自使用。
• Non-Moving Space：存储不需要移动的对象，如 ART 内部数据结构，和Dalvik中的Linear Alloc类似。
• Large Object Space ：用于存储大对象（通常大于 12KB）使用单独的分配策略和GC机制。
• Region Space ：用于新生代对象的分配和管理,是离散地址的集合，使用更高效的垃圾回收机制。
• Image Space：包含预编译的系统类和应用程序类，从预生成的映像文件中内存映射而来，在Zygote和其他应用程序进程之间共享，不参与GC。

Android系统的第一个虚拟机由Zygote进程创建并且只有一个Zygote Space。但是当Zygote进程在fork第一个应用程序进程之前，会将已经使用的那部分堆内存划分为一部分，还没有使用的堆内存划分为另一部分，也就是Allocation Space。但无论是应用程序进程，还是Zygote进程，当他们需要分配对象时，都是在各自的Allocation Space堆上进行。

单进程内存上限

Android 系统的 Java虚拟机会对单个进程使用的最大内存做限制，该属性值定义在/system/build.prop文件中，厂商一般会根据设备自身内存大小来设定这个值，不同的设备分配给APP的最大可用内存是不相同的。进程启动时，系统会先为APP分配一定的内存空间，当分配的内存快要耗尽时，系统会再次为App 分配更多的内存，但是每个APP都有内存使用上限，一旦进程分配了最大可用内存后，内存依然不足则会直接抛出OOM异常，终止程序的运行。可以通过调用 getMemoryClass() 向系统查询此数值。此方法返回一个整数，表示应用堆的可用兆字节数。

内存垃圾回收

当进程使用内存达到设定的阈值时，就会触发虚拟机的GC机制，虽然新一代的ART对于通过分代垃圾回收和高效的内存分配机制，ART 能够更加高效地使用内存，减少内存碎片和内存泄漏等方面的优化，但是GC的时候，还是会导致 STW （Stop The World），所以为了提升程序性能，有必要进行内存优化。下边列举一下Java的内存回收算法。

标记清除算法

标记清除算法是一种垃圾回收算法，用于管理动态分配的内存。它的主要思想是，遍历整个堆，标记所有被引用的对象，当某个对象不再被程序所引用时，它就可以被认为是“垃圾”，并被回收以便后续的内存分配。 优缺点：自动管理动态分配的内存，但是清除后可能导致大量的内存碎片，降低堆利用率。

复制算法 ：

复制算法是一种将内存分为两个区域的算法，其中一个区域用于存储活动对象，另一个区域用于存储不再使用的对象。 优缺点：运行效率高，但是浪费一半空间，代价较高。

标记整理算法 ：

标记整理算法是标记清除算法和复制算法的结合，其工作原理是先标记出不再使用的对象，再整理内存使得活动对象的内存分配连续，优缺点：解决了标记清除算法导致的内存碎片问题，但是也产生了一些问题，由于进行了两次扫描，增加了时间开销。 相较其他垃圾回收算法，速度较慢，不适合新生代场景，并且标记整理算法的效率也受内存使用情况影响，效率不稳定等问题。

分代收集算法 ：

分代回收算法是一种将内存分为几个代的算法，并对每个代进行不同的回收策略，这里就需要借一张图了，一图胜千言

新创建的对象 , 放在年轻代内存块中 , 开始时放在 Eden 区域 , 当 Eden 区域存满后 , 会将存活的对象转移到 From 区域 和 To 区域，对象每经过一次 GC 垃圾回收 , 其年龄就会加 1 ; 当年龄到达虚拟机设置的阈值之后 , 就会被放入老年代内存块中 ，持久代内存区域，主要存放着类加载器加载的Class和常量池等对象。

• 年轻代内存区域的垃圾回收器 : Minor GC （Serial，ParNew 和 Parallel Scavenge）
• 老年代内存区域的垃圾回收器 : Major GC （CMS ,Serial Old和 Parallel Old）
• 整个内存区域的垃圾回收器 : Full GC

持久代内存区域的内存不回收 ;年轻代内存区域与老年代内存区域的垃圾回收机制不同的。

Serial ParNew都是 使用的复制算法，主要在年轻代中收集要回收的内存，但是Serial是单线程串行，而ParNew则是多线程运行。

CMS Concurrent Mark Sweep ，并发标记清除收集器，采用标记清除算法，gc过程，用户线程仅做最短停顿，具体流程如下：

• 初始标记 : 标记与 GC Roots 有引用链的对象 ; 该操作速度快 , 该步骤需要暂停用户线程。
• 并发标记 : GC Roots 追踪,从初始标记结果集合中标记出存活对象,不能保证所有的存活对象都被标记 ; 该步骤与应用程序并发执行。
• 重新标记 : 上一步并发标记 GC 线程与用户程序并发期间的标记有部分变化 , 修正这部分标记信息之后暂停用户线程 开始标记，该暂停操作要比初始标记步骤暂停时间长。
• 并发清除 : 回收所有 GC Roots 不可达对象

CMS的优点是，并发收集，低停顿。有一个明显缺点就是因为采用了“标记-清除”算法，最后会出现大量碎片，有可能会出现在某一个时刻，当有大对象生成，不得不进行一次Full GC来解决这个问题。为了解决该问题CMS有一个参数-XX:UseCmsCompactAtFullCollection来解决因为空间不足进行Full GC。这个参数默认开启，用于在CMS收集器顶不住要进行Full GC是开启内存碎片合并整理的过程，内存整理过程是无法并发的，因此就会耗时。同时还有一个参数是-XX:CMSFullGCsBeforeCompaction,这个参数是用于执行多次不压缩的GC后，跟着来一次压缩的(默认是0,表示每次进入Full GC都进行碎片整理)。

G1收集器

Garbage-First收集器：并行和并发，分代收集。 G1和其他收集器不同的是，其他收集器收集范围都是整个新生代和老年代，而G1不再是这样。使用G1收集器的时候，Java堆分为多个大小相等的区域(Region),虽然也保留了新生代和老年代的概念，但是不再是物理隔离了，他们都是一部分Region的集合(这些Region不一定是连续的)。G1保留了Eden和Survivor的比例也是8：1：1。

ZGC

JDK11引入的ZGC收集器，在物理和逻辑上已经没有新/老年代的概念了，会分为一个个page，当进行GC操作时候会对page进行压缩，因此没有碎片问题，只能在64位linux上使用。

• 可以达到10ms以内的停顿要求
• 支持TB级别的内存
• 堆内存变大后停顿时间还是在10ms以内

Java 引用类型

既然上边列举了主要的回收算法，这里简单带过一下引用类型，也是内存优化过程中，经常使用到的知识点：

• 强引用 ：强引用是 Java 中最常见的引用类型，当对象具有强引用时，它永远不会被垃圾回收。只有在程序结束或者手动将对象设置为 null 时，才会释放强引用，像常用的 new 方式。
• 软引用 ：当 Java 堆内存不足时，软引用可能会被回收，以腾出内存空间。如果内存充足，则软引用可以继续存在，使用SoftReference创建，gc的时候可能并不会释放软引用持有对象。
• 弱引用 ：在垃圾回收器线程扫描它所管辖的内存区域的过程中，发现具有弱引用的对象，不管当前内存空间是否足够，都会回收它的内存。
• 虚引用 ： 只能用于跟踪即将对被引用对象进行的收集。虚拟机必须与ReferenceQueue类联合使用。因为它能够充当通知机制。

内存优化的必要性

经过上述基础知识的分析，我们认识到内存在手机侧的宝贵和重要性，安卓系统对每个应用程序都有一定的内存限制，当应用程序的内存超过了上限，就会出现 OOM，造成App的异常退出。

因此，要改善系统的运行效率、改善用户体验、降低系统资源占用、延长电池寿命、降低系统故障的危险。Android通过内存优化，可以减少系统内存使用 提高应用后台运行存活率，让系统更加流畅，秒开率更高，减少系统GC次数，减少页面卡顿率，降低内存泄漏率，从而提高App的整体体验和功耗优化。

内存优化思路及SOP

数据收集及水位分析

关于性能或功耗方面的优化问题，都要先做到摸清大盘数据，特别是我这种新的公司，新的APM系统的，一定要摸清APM上报原理和逻辑，并且输出自己的文档，好记性不如烂笔头。

查看内存泄露、内存溢出和线程超标等方面的数据后，动手改代码前要确定好优化后的目标水位是多少，定好里程碑，及时同步领导，避免大方向错误。

借助工具排查问题

在线上大盘水位摸清之后，比如我们是基于Koom进行了魔改，就可以将上报的内存泄露问题统一汇总并解决，但是内存的水位偏高和内存抖动问题，就需要借助本地检测工具进行排查。下篇具体汇总下，通过工具查看问题。 比如图片使用方面，可以使用 Hook native bitmap （新版本都是用Native内存，暂不考虑 8.0 之前的版本情况了）检测图片在退出页面后，是否清理完成。

问题优化

针对不同类型问题需要使用不同的方式，比如内存抖动问题，存在一些大对象或者过多小对象的情况，可能存在频繁创建对象等问题。如果存在内存泄露等问题，则需要根据堆栈调用链，排查那些代码存在纰漏。针对问题优化后，做好兜底策略，并后续关注新版本是否有新的上报。

长效治理策略

问题如果解决后，可以将常见的内存泄露问题进行汇总，在排查问题过程中，使用到的工具及操作流程进行整理，汇总成内存优化SOP，可以在组内进行技术分享，提高团队的内存优化意识。

关于长期卡口，可以尝试在Git Hook的办法，针对提交的代码进行监控，如果出现内存泄露的写法阻止代码提交，并展示警告信息。

参考文章

Android性能优化之内存优化 - JsonChao

分代收集算法

深入探索 Android 内存优化（炼狱级别-上）

深入探索 Android 内存优化（炼狱级别-下）