产品解决方案安全专区定价 WeTest生态支持与服务关于WeTest

Android 内存暴减的秘密？！

开发测试干货 2018-01-04 19:54 63506

企鹅FM 内存优化二期总结~

WeTest 导读

在我这样减少了26.5M Java内存！一文中内存优化一期已经告一段落，主要做的事情是，造了几个分析内存问题的轮子，定位进程各种类型内存占用情况，分析了线程创建OOM的原因。当然最重要的是，优化了一波进程静息态的内存占用（减少26M+）。而二期则是在一期的基础之上，推进已发现问题的SDK解决问题，最终要的是要优化进程的动态Java内存占用！

通常来说不管是做什么性能优化，逃不出性能优化3步曲：

1. 找到性能瓶颈

2. 分析优化方案

3. 执行优化

上述三步看似第三步最能决定优化结果，而事实上，从笔者的几次性能优化经历来看，找到瓶颈确占据了绝对的影响力！

● 能否找到瓶颈意味着优化做不做的下去。

● 找到的瓶颈性能越差意味着优化效果越明显。

● 找到的瓶颈越多同样意味着优化效果越好。

一

如何找瓶颈所在

在分析方法上，主要：

● 分析代码逻辑，检查有问题的逻辑，对其进行相关优化。

● 模拟用户操作在内存占用较高的时候dump内存，使用MAT分析

● 然后是分析HeapDump的方法

1. 看 DominatorTree，确定占用内存最多的实例

2. 通过 GC root辅助分析内存占用的来源

3. 通过 RetainHeapSize 量化的分析内存占用

动态内存优化比静态要更难，其难点在于动态二字之上。动态不仅是的查找瓶颈变得困难，也使得对比优化成果不显而易见。而不同的环境、操作路径、设备、使用习惯等各个因素都有可能导致内存占用的不同。可能的情况是：找到的性能瓶颈和用户实际操作的方式不同，导致不能解决外网的OOM。因此直接获取手机用户的真实数据则是最行之有效的一种方式。

因此辅助采取了另一种方式, 收集真实的用户数据。

● 在手机发生OOM的时候dump内存，上传到后台，以便后续分析

措施1：可以优化现有代码逻辑，针对内存占用过多/不合理的场景进行优化。这是主场景。

措施2：主要分析外网用户的使用习惯下，发生OOM的场景。比较容易发现bug类问题导致瞬间内存占用过多的场景。

二

找到哪些瓶颈

找到的瓶颈问题很多，稍微按照分类梳理一下：

1. 加载进内存，实际上没用到（还没用到）的数据

1）PullToRefreshListView 的 Loading 和 Empty View lazyLoad，这是下拉刷新的组件，其下拉刷新有一个帧动画，图片较多，占用较多内存。

2）Minibar PlayListView。每个页面都会有一个Minibar，但是不一定Minibar都会打开播放列表。

3）AsyncImageView 的默认图和失败图以Drawble的形式直接加载进内存的。

2. UI 相关数据，未及时释放

1）24 小时直播间数据，只在节目切换的时候才有用

2）弹幕，只在播放页展示弹幕的时候才有用

3）播放页 TransitionBackgroundManager 大图内存占用问题。这个一个大图，为了做渐变动画。

3. 数据结构不合理，占用内存过多

1）播放历史最多记录600个节目信息，每一个ShowInfo占用内存多达22K（通过MAT查看RetainHeap）

2）下载管理会在内存中存储用户下载的节目信息，歌词，专辑信息，分别占用内存 12K, 0-10K, 12K。并且这里没有数量限制。

4. 图片占用内存过多

1）在应用主页操作一下，发现图片（Bitmap）占用的内存很多

2）高斯模糊图片。

5. bug类导致内存占用过多

播放历史应为代码逻辑bug，导致没有控制记录数量上限。于是用户听的节目越多内存占用就越大。这里的问题主要通过OOM上报发现，占用内存最多的一次上报，仅播放历史记录就占内存50M之多。

上述 1-4 点通过措施1主动检查内存发现。而第5点则是在分析了OOM上报“意外”发现的，如果是通过措施1的方式，几乎不可能知道这么多OOM竟然是因为这个问题引起的。

三

怎么优化瓶颈

找到问题之后，剩下的就是比较好做的了，只需顺藤摸瓜，各个击破！

1、懒加载（LazyLoad）

针对上面的1.1， 1.2，都可以做LazyLoad，真正需要下拉刷新/展示播放列表的时候再创建相关实例。

1.4 则可以在动画结束之后清理掉相关Bitmap

1.3 会复杂一点。图片加载组件可以提供default图，在图片加载过程中临时展示；以及faild图，在图片加载失败之后展示。这两个图在AsyncImageView中都是直接引用住图片（Drawable）的。事实上绝大多数场景都会显示成功的图片。因此这里的修改方式是：
AsyncImageView的 default/fail 图片不再引用 drawable，而是引用资源ID，在需要的时候再由ImageLoader加载进内存，同时这些图片将有ImageCache统一管理，并占用内存LRU空间（之前是由Resource管理）。

这里去掉了几个大图的内存占用。内存占用在几M级别。

2. 及时释放

上面 2.1 中的24小时直播间的数据会一直在内存中，即使用户当前没有在听24小时直播间。这个显然是不合理的。

修改的做法是业务数据缓存的DB中，在需要用到的时候从DB中查询出来

2.2 的弹幕则是纯粹的UI相关数据，在播放页退出之后即可释放了。

2.3 是为了动画准备的一张大图，为了做一个炫酷的动画效果。事实上，在动画结束之后，就可以释放了。这个图片占用的内存和手机分辨徐率相关，分辨率（严格来说是density）越高的手机，图片尺寸越大。在主流手机上1080p约1M。

这里分别减少了 287K + 512K + 1M

3. 优化数据结构

3.1 和 3.2 都会存储节目信息，而节目信息相关的jce结构都比较大，通过MAT，可以看到 Show:12K, Album:10K, 一个ShowInfo同时包含了上面两种数据结构。

最合理的方式应该是：

1. 数据存储在DB

2. 在需要数据的时候通过一次db查询，拿到具体的数据。

但是因为现有代码都是从内存中查询，接口是同步的方式，全部改异步的成本会比较大，这里我们的时间成本和测试自由都有限。

综合上面MAT分析的结果，有个思路：

内存中存储节目信息（ShowMeta）最少的内存，例如: 节目名，节目id，专辑id 之类的信息。而真正的Show和Album结构存在DB中。

这样内存中的数据可以尽量的少，同时大部分已有接口还可以保持同步调用的方式。

此外，从用户的角度出发，假设一个重度用户下载了1000个节目，那么每一个ShowMeta占用的内存都会被放大1000倍，因此载极限的优化ShowMeta都不为过。

这里做了两件事：

1. 删字段，把ShowMeta中的非必要字段删掉。
比如其中的url字段，实际只用来通过hash生成文件名，我们完全可以用showId代替。而一个url长度可达500Byte，1000个ShowMeta的话，这里就能节省500K内存了！

再比如：dowanloadTaskId字段，是存储下载任务的id的，在节目下载完成后，该字段即失去意义，因此可以删除之。

2. intern 这里是参考了 String.intern 的思路。不同的ShowMeta可能会有相同的字段，或者说字段中有相同的部分。

比如同一个专辑中的ShowMeta其albumId字段都会是相同的，我们只需要保留一份albumId，其他ShowMeta都可以用同一个实例。（内存优化一期对ShowList做了同样的改造）

再比如：ShowMeta中会存储下载文件的全路径，而事实上所有节目都会存储在同一个文件目录中，因此这里把文件路径拆成目录+文件名来存储，而路径采用 intern 的方式，保证了内存中只会有一份。

优化前

优化后

最直观的看变化是内存占用从 14272B 到 120B。仔细看会发现 ShowRecordMeta 的retainHeap 不等于各字段内存占用之和，这是因为上面提到的 String intern 的作用，相同字段被复用了，因此这里的retainheap不准确，通过RecordDataManager/countof(records) 计算，平均每一个record 14800/60 = 247B，减少98%。

这里的修改结果：
播放历史 ShowHistoryBiz -> ShowHistoryMeta 内存占用从 19k 到约216B

下载记录 ShowRecordBiz -> ShowRecordMeta 内存占用从 14k 到约100B

粗略估计，这里修改的播放历史（每次播放都会增加一个记录，上限600个），(19256-216)* 600 = 10.9M

和下载记录（假设一个轻度使用用户用户下载100个节目），内存总共可以减少：
(14727-100)* 100 = 1.4M

如果是重度用户，下载1000个节目，则有14M之多！

不得不说这是个很大的数字！

四

图片内存

在Android 2.3 之后，Bitmap改了实现，图片内存从native heap转移到了Java heap。这就导致了JavaHeap占用暴增。（然而8.0又改成NativeHeap了，具体原因官方文档并没有提及，有待考察）。

通常我们分析 heap dump 的时候会发现Bitmap占用的内存是绝对的大头。这次我们做内存优化也不例外。

这里的思路是分析内存占用是否合理：

1. 是否所有图片都用于界面展示

2. 是否图片尺寸过大。

首先，分析内存占用是否合理。经过一期的优化，在不打开MainActivity的时候，内存中几乎没有图片。但是打开MainActivity之后，内存中会出现几十兆的图片内存。
图片内存主要是用于展示的，也即：被AsyncImageView持有的部分。

另外是内存的图片缓存，会持有最大JavaHeap 1/8 的内存充当 Bitmap 缓存，使用LRU算法淘汰老数据。

当然另外一些图片过大属于使用不当，实际上可以裁剪才View实际的大小。

而一些全屏（和屏幕等宽的图，主要是Banner）图其实可以裁剪的更小一点（如3/4大小）减少近46%的内存占用，而观感不会有特别明显的区别。（写这个文档的时候突然想到的，TODO一下）。

问题1：针对AsyncImageView的问题，思考是否所有图片都在用户展示？
答案显然是否定的，一部分图片被ListView回收的view所持有，这些内存占用显然是不合理的。

问题2：另外就是ViewPager这种多页面视图，给用户展示的实际上只有一个，其他几个视图并没有在展示，因此这里是否可以改造ViewPager呢？

针对第一个问题，被ListView回收的view仍然在内存中的问题，通过改造AsyncImageView，在View从windowdetach的时候，主动释放Bitmap，attach到Window的时候再次尝试加载图片。另外是多图滚动视图，这里的图片很大，因此占用内存也很多。因为历史原因之前使用的是Gallery，其有bug导致会额外引用住两个大图（已经不可见），因此这里使用RecyclerView修改了其实现，解决上述问题。

针对第二个问题，目前还没有采取有效措施，主要依赖Android系统，主动回收Activity的内存。（这里存疑，需要深挖系统代码，理清理逻辑之后再下结论。短期的结论是：系统的清理行为不可靠）。如果要改的话，可以简单的修改一下ViewPager的内存，保证在其他page不可见的时候，回收其相关的Fragment。留个TODO。

LRU + TTL

针对图片缓存，这里本身只是缓存图片并且有LRU算法保证不会超过最大内存，理论上内存占用合理。但是LRU算法有一个问题，就是一旦缓存满了，后续只能通过添加新Bitmap才能淘汰掉老的Bitmap，而此时缓存占用的内存仍然是最大值。因此这里的思考是LRU+TTL算法：即在LRU的基础上，指定每一个Bitmap在缓存中存在是有效时长。超过时长之后主动将其从缓存中清理掉。这样我们就可以解决LRUcache占用的内存不可减少的问题。

再次感谢afc组件作者raezlu和笔者讨论问题，欣然接受建议，并身体力行的实现了TTL方案！

高斯模糊

这里补充一个，关于高斯模糊图片占用内存过高的问题，在之前版本已经优化过了。

因为高斯模糊的图片本身会让图片变得模糊（废话。。），因此图片的信息实质上是丢失了很大一部分的。在此思路的基础上，我们可以把需要高斯模糊的图片先缩小（比如 100x100），然后再做高斯模糊。这样不仅减少了内存占用，同时高斯模糊处理的速度也可以大大增加！

比如，之前遇到播放页封面cover图 720*720的大小，占内存 720 * 720 * 4 = 2M，降低到 100x100 占用内存大小 100 * 100 * 4= 40K，内存优化效果明显，而视觉上几乎没有差距。

五

其他优化

这里主要针对外网的TOP1 crash，WNS内部线程创建导致的OOM。

笔者的解决方案是先根据crash上报信息，深挖系统源码《Android 创建线程源码与OOM分析》，彻底理清楚线程创建逻辑，并最终确定crash原因是线程的无节制创建。然后针对crash，整理出详细的原因分析，再给WNS的小伙伴提了bug，待修复之后替换sdk。

六

成果对比

内存优化的效果总体还不错，这里一共做了两期，优化了几十个项目。首先要比较感谢项目组给了可观的排期，这样才有时间做一些比较深入的改动。