Android性能优化之Java内存

1、内存泄漏的定义

Android是基于Java的，众所周知Java语言的内存管理是其一大特点，不用像C语言那样处理对象的内存分配到回收的全部过程。在Java中我们只需要简单地新建对象就可以了，Java垃圾回收器会负责回收释放对象内存。这么看的话，垃圾回收器会管理内存又怎么还会发生内存泄漏呢?

其实Java中的内存泄漏的定义是：对象不再被程序所使用，但是由于这些对象被引用着导致GC(GarbageCollector)不能回收它们。

下面这张图可以帮助我们更好地理解对象的状态，以及内存泄漏的情况

左边未引用的对象是会被GC回收的，右边被引用的对象不会被GC回收，但是未使用的对象中除了未引用的对象，还包括已被引用的一部分对象，那么内存泄漏久发生这部分已被引用但未使用的对象。

接下来还有一个疑问：未使用的对象被谁引用会让GC无法回收呢?

现在主流的程序语言的主流实现中，是通过可达性分析(ReachabilityAnalysis)来判断对象是否存活的。这个算法的基本思路是：通过一系列的称为“GCRoots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GCRoots没有任何引用链时，说明此对象不可用，可以被回收了。

可以作为GCRoots的对象包括下面几种：

·虚拟机栈中引用的对象，一般是当前在使用中局部变量

·方法区中类静态属性引用的对象，就是静态变量对应的对象

·方法区中常量引用的对象

·本地方法栈中JNI(即一般说的NaTIve方法)引用的对象

MAT分析内存泄漏的时候，也是查看对象到GCRoots的引用链，来定位泄漏代码的位置。

所以未使用的对象直接或间接地被GCRoots引用时会让GC无法回收，从而产生内存泄漏。

2、Android的内存管理

了解了Java的内存泄漏的起因，接下来大致了解Android中的内存管理机制。

Google在Android的官网上有这样一篇文章，初步介绍了Android是如何管理应用的进程与内存分配：http://developer.android.com/training/arTIcles/memory.html。Android系统的Dalvik虚拟机扮演了常规的内存垃圾自动回收的角色，Android系统没有为内存提供交换区，它使用paging与memory-mapping(mmapping)的机制来管理内存，下面简要概述一些Android系统中重要的内存管理基础概念。

分配与回收内存

每一个进程的Dalvikheap都反映了使用内存的占用范围。这就是通常逻辑意义上提到的DalvikHeapSize，它可以随着需要进行增长，但是增长行为会有一个系统为它设定的上限。

逻辑上讲的HeapSize和实际物理意义上使用的内存大小是不对等的，ProporTIonalSetSize(PSS)记录了应用程序自身占用以及和其他进程进行共享的内存。

Android系统并不会对Heap中空闲内存区域做碎片整理。系统仅仅会在新的内存分配之前判断Heap的尾端剩余空间是否足够，如果空间不够会触发gc操作，从而腾出更多空闲的内存空间。在Android的高级系统版本里面针对Heap空间有一个GeneraTIonalHeapMemory的模型，最近分配的对象会存放在YoungGeneration区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到OldGeneration，最后累积一定时间再移动到PermanentGeneration区域。系统会根据内存中不同的内存数据类型分别执行不同的gc操作。例如，刚分配到YoungGeneration区域的对象通常更容易被销毁回收，同时在YoungGeneration区域的gc操作速度会比OldGeneration区域的gc操作速度更快。如下图所示：

每一个Generation的内存区域都有固定的大小，随着新的对象陆续被分配到此区域，当这些对象总的大小快达到这一级别内存区域的阀值时，会触发GC的操作，以便腾出空间来存放其他新的对象。

通常情况下，GC发生的时候，所有的线程都是会被暂停的。执行GC所占用的时间和它发生在哪一个Generation也有关系，Young Generation中的每次GC操作时间是最短的，Old Generation其次，Permanent Generation最长。执行时间的长短也和当前Generation中的对象数量有关，遍历树结构查找20000个对象比起遍历50个对象自然是要慢很多的。

为什么通常情况下，GC发生的时候，所有的线程都会被暂停?

因为每次GC的时候，需要先找到可作为GC Roots的对象，然后以此搜索引用链，这个过程需要在一致性的内存快照中进行。这个“一致性”表示在整个过程中不能出现对象引用关系不断变化的情况，所以需要暂停所有的执行线程。

限制应用的内存

为了整个Android系统的内存控制需要，Android系统为每一个应用程序都设置了一个硬性的Dalvik Heap Size最大限制阈值，这个阈值在不同的设备上会因为RAM大小不同而各有差异。如果你的应用占用内存空间已经接近这个阈值，此时再尝试分配内存的话，很容易引起OutOfMemoryError的错误。

ActivityManager.getMemoryClass()可以用来查询当前应用的Heap Size阈值，这个方法会返回一个整数，表明你的应用的Heap Size阈值是多少Mb(megabates)。

还有一个用adb命令查询的方法：

adb shell getprop dalvik.vm.heapgrowthlimit

3、案例

JOOX是IBG一个核心产品，2014年发布以来已经成为5个国家和地区排名第一的音乐App。东南亚是JOOX的主要发行地区，实际上这些地区还是有很多的低端机型，对App的进行内存优化势在必行。

上面介绍了Android系统内存分配和回收机制，同时也列举了常见的内存问题，但是当我们接到一个内存优化的任务时，我们应该从何开始?下面是一次内存优化的分享。

1. 首先是解决大部分内存泄露。

不管目前App内存占用怎样，理论上不需要的东西最好回收，避免浪费用户内存，减少OOM。实际上自JOOX接入LeakCanary后，每个版本都会做内存泄露检测，经过几个版本的迭代，JOOX已经修复了几十处内存泄露。

2. 通过MAT查看内存占用，优化占用内存较大的地方。

JOOX修复了一系列内存泄露后，内存占用还是居高不下，只能通过MAT查看到底是哪里占用了内存。关于MAT的使用，网上教程无数，简单推荐两篇MAT使用教程，MAT - Memory Analyzer Tool 使用进阶。

点击Android Studio这里可以dump当前的内存快照，因为直接通过Android Sutdio dump出来的hprof文件与标准hprof文件有些差异，我们需要手动进行转换，利用sdk目录/platform-tools/hprof-conv.exe可以直接进行转换，用法：hprof-conv 原文件.hprof 新文件.hprof。只需要输入原文件名还有目标文件名就可以进行转换，转换完就可以直接用MAT打开。

下面就是JOOX打开App，手动进行多次gc的hprof文件。

这里我们看的是Dominator Tree(即内存里占用内存最多的对象列表)。

Shallo Heap：对象本身占用内存的大小，不包含其引用的对象内存。

Retained Heap： Retained heap值的计算方式是将retained set中的所有对象大小叠加。或者说，由于X被释放，导致其它所有被释放对象(包括被递归释放的)所占的heap大小。

第一眼看去 居然有3个8M的对象，加起来就是24M啊 这到底是什么鬼?

我们通过List objects-》with incoming references查看(这里with incoming references表示查看谁引用了这个对象，with outgoing references表示这个对象引用了谁)

通过这个方式我们看到这三张图分别是闪屏，App主背景，App抽屉背景。

这里其实有两个问题：

这几张图原图实际都是1280x720，而在1080p手机上实测这几张图都缩放到了1920x1080

闪屏页面，其实这张图在闪屏显示过后应该可以回收，但是因为历史原因(和JOOX的退出机制有关)，这张图被常驻在后台，导致无谓的内存占用。

优化方式：我们通过将这三张图从xhdpi挪动到xxhdpi(当然这里需要看下图片显示效果有没很大的影响)，以及在闪屏显示过后回收闪屏图片。

优化结果：

从原来的8.29x3=24.87M 到 3.68x2=7.36M 优化了17M(有没一种万马奔腾的感觉。。可能有时费大力气优化很多代码也优化不了几百K，所以很多情况下内存优化时优化图片还是比较立竿见影的)。

同样方式我们发现对于一些默认图，实际要求的显示要求并不高(图片相对简单，同时大部分情况下图片加载会成功)，比如下面这张banner的背景图：

优化前1.6M左右，优化后700K左右。

同时我们也发现了默认图片一个其他问题，因为历史原因，我们使用的图片加载库，设置默认图片的接口是需要一个bitmap，导致我们原来几乎每个adapter都用BitmapFactory decode了一个bitmap，对同一张默认图片，不但没有复用，还保存了多份，不仅会造成内存浪费，而且导致滑动偶尔会卡顿。这里我们也对默认图片使用全局的bitmap缓存池，App全局只要使用同一张bitmap，都复用了同一份。

另外对于从MAT里看到的图片，有时候因为看不到在项目里面对应的ID，会比较难确认到底是哪一张图，这里stackoverflow上有一种方法，直接用原始数据通过GIM还原这张图片。

这里其实也看到JOOX比较吃亏一个地方，JOOX不少地方都是使用比较复杂的图片，同时有些地方还需要模糊，动画这些都是比较耗内存的操作，Material Design出来后，很多App都遵循MD设计进行改版，通常默认背景，默认图片一般都是纯色，不仅App看起来比较明亮轻快，实际上也省了很多的内存，对此，JOOX后面对低端机型做了对应的优化。

3. 我们也对Bugly上的OOM进行了分析，发现其实有些OOM是可以避免的。

下面这个crash就是上面提到的在LsitView的adapter里不停创建bitmap，这个地方是我们的首页banner位，理论上App一打开就会缓存这张默认背景图片了，而实际在使用过一段时间后，才因为为了解码这张背景图而OOM， 改为用全局缓存解决。

下面这个就是传说中的内存抖动

实际代码如下，因为打Log而进行了字符串拼接，一旦这个函数被比较频繁地调用，那么就很有可能会发生内存抖动。这里我们新版本已经改为使用stringbuilder进行优化。

还有一些比较奇怪的情况，这里是我们扫描歌曲文件头的时候发生的，有些文件头居然有几百M大，导致一次申请了过大的内存，直接OOM，这里暂时也无法修复，直接catch住out of memory error。

4. 同时我们对一些逻辑代码进行调整，比如我们的App主页的第三个tab(Live tab)进行了数据延迟加载，和定时回收。

这里因为这个页面除了有大图还有轮播banner，实际强引用的图片会有多张，如果这个时候切到其他页面进行听歌等行为，这个页面一直在后台缓存，实际是很浪费耗内存的，同时为优化体验，我们又不能直接通过设置主页的viewpager的缓存页数，因为这样经常都会回收，导致影响体验，所以我们在页面不可见后过一段时间，清理掉adapter数据(只是清空adapter里的数据，实际从网络加载回来的数据还在，这里只是为了去掉界面对图片的引用)，当页面再次显示时再用已经加载的数据显示，即减少了很多情况下图片的引用，也不影响体验。

5. 最后我们也遇到一个比较奇葩的问题，在我们的Bugly上报上有这样一条上报

我们在stackoverflow上看到了相关的讨论，大致意思是有些情况下比如息屏，或者一些省电模式下，频繁地调System.gc()可能会因为内核状态切换超时的异常。这个问题貌似没有比较好的解决方法，只能是优化内存，尽量减少手动调用System.gc()

优化结果

我们通过启动App后，切换到我的音乐界面，停留1分钟，多次gc后，获取App内存占用

优化前：

优化后：

多次试验结果都差不多，这里只截取了其中一次，有28M的优化效果。

当然不同的场景内存占用不同，同时上面试验结果是通过多次手动触发gc稳定后的结果。对于使用其他第三方工具不手动gc的情况下，试验结果可能会差异比较大。

对于上面提到的JOOX里各种图片背景等问题，我们做了动态的优化，对不同的机型进行优化，对特别低端的机型设置为纯色背景等方式，最终优化效果如下：

平均内存降低41M。

本次总结主要还是从图片方面下手，还有一点逻辑优化，已经基本达到优化目标。