案例背景
在美团App 7.4~7.7版本期间，美食业务的OOM数量居高不下，远高于历史水平，紧张都是DECODE本地的资源出错。
图中OOM数量为各版本发版后第一个月的统计量，包含新发版本及历史版本。比拟了同期间其他业务的情形，也有类似OOM。由于美食业务的访问量占美团App的比重较大，因此，OOM的数量相对其他业务也多一些。
思路方案
在问题较为严重的7.6~7.7版本期间，团队对OOM频现的缘故原由有过各种预测。笔者疑惑过是否是业务上某些修正引起的，例如头图尺寸变大，或者是由页面模块加载办法引起的等等。但这些与OOM问题涌现的韶光并不吻合。其次也疑惑过是否由某些ROM的Bug导致，但此推断缺少有力的证据支撑。因此，要找到OOM的root cause，根本路子还是找到谁占的内存最多，然后再根据详细case详细剖析，为什么占了这么多。
采集用户手机内存信息
要剖析内存的占用，须要内存的dump文件，但是dump文件一样平常都比较大，让用户合营上传dump文件不得当。以是希望能够运行时采集一些内存的特色然后随着crash日志上报上来。当用户发生OOM时，dump出用户的内存，然后基于com.squareup.haha:haha:2.0.3剖析，得到一些关键数据（内存占用最多的实例及所占比例等）。但这个方案很快就被证明是不可行的。紧张基于下面几个缘故原由：
须要引入新的库。
dump和剖析内存都很耗时，效率难以接管。
OOM时内存已经险些耗尽，再加载内存dump文件并剖析会导致二次OOM，得不偿失落。
仿照复现OOM
采集用户手机内存信息的方案不可行，那么只能采纳复现用户场景的办法。由于发生OOM时，用户操作路径的不愿定性，无法精确复现线上的OOM，因此采纳仿照复现的办法，终极发生OOM时的栈信息基本同等即可。为了能够只管即便仿照用户发生OOM的场景，须要基本条件基本同等，即用户利用的手机的各种干系参数。
挖掘OOM特色
剖析7.4以来的OOM，列出发生OOM的机器的特色，紧张是内存和分辨率，适当考虑其它成分例如系统版本。
这些特色可以总结为：内存一样平常，分辨率偏高，OOM的堆栈log基本同等。个中，OPPO N1(T/W)上所发生的OOM比重较高，约为65%，因此选定这款机器作为复现OOM的机器。
关键数据（内存dump文件）
须要复现OOM然后获取内存dump。思路是采纳内存压力测试，让问题暴露的快速且充分。详细方案为：
选取图片资源多且较为繁芜的页面，比如美食的POI详情页。
加载30次该页面，为了增加OOM的几率，30个POI页面的ID是不同的。
OOM发生后，利用Android Studio自带的Android Monitor dump出HPROF文件，然后利用SDK中的hprof-conv（位于sdk_root/platform-tools）工具转换为标准的Java堆转储文件格式，这样可以利用MAT（Eclipse Memory Analyzer）连续剖析。
切到histogram视图，按shadow heap降序排列。
选取byte数组，右击->list objects->with incoming references，降序排列可以看到有很多大小同等的byte[]实例。
右击个中一个数组->Path to GC Roots-> exclude xxx references
如上图所示，这些byte[]都是系统的EdgeEffect的drawable所持有，drawable对应的bitmap占用的空间为1566 406 4 = 2543184，与byte数组的大小同等。
再看其余一个：
这些byte[]是被App的一个背景图所持有，如下图：
通过ImageView的ID（如图）及build目录下的R.txt反查可知该ImageView的ID名称，即可知其设置的背景图的大小为720 200（xhdpi），加载到内存并考虑density，size刚好是1080 300 4 = 1296000，与byte数组大小同等。
数据剖析
为什么会涌现这些大小同等的byte数组，或者说，为什么会创建多份EdgeEffect的drawable？查看EdgeEffect的源码（4.2.2）可知，其drawable成员也是通过Resources.getDrawable系统调用获取的。
/
ImageView(View)获取background对应的drawable的过程类似。
for (int i = 0; i < N; i++) {
不论是Resources.getDrawable还是TypedArray.getDrawable，终极都会调用Resources.loadDrawable。连续看Resources.loadDrawable的源码，创造的确是利用了缓存。对付同一个drawable资源，系统只会加载一次，之后都会从缓存去取。
既然drawable的加载机制并没有问题，那么drawable所在的缓存实例或者获取drawable的Resources实例是否是同一个呢？通过下面的代码，打印出每个Activity的Resources实例及Resources实例的drawable cache。
//noinspection unchecked
这也进一步阐明了其余一个征象，即这些大小相同的数组的个数基本和启动Activity的数量成正比。
通过数据剖析可知，这些drawable之以是存在多份，是由于其所在的Resources实例并不是同一个。进一步debug可知，Resources实例存在多个的缘故原由是开启了标志位sCompatVectorFromResourcesEnabled。
虽然终极造成OOM溘然增多的缘故原由只是开启一个标志位，但是这也告诫大家阅读API文档的主要性，实在很多时候API的利用解释已经明确奉告了利用的限定条件乃至风险。
7.8版本关闭了此标志，发版后第一个月的OOM数量（包含历史版本）为153，如下图。
个中新版本发生的OOM数量为22。
总结
对付线上涌现的OOM，如何剖析和解决可以大致分为三个步骤：
充分挖掘特色。在挖掘特色时，须要多方面考虑，此过程更多的是预测疑惑，以是可能的方面都要考虑到，包括但不限于代码改动、机器特色、韶光特色等，必要时还须要做一定的统计剖析。
根据节制的特色探求稳定的复现的路子。一样平常须要做内存压力测试，这样比较随意马虎达到OOM的临界值，只是大略的一些正常操作难以触发OOM。
获取可剖析的数据（内存dump文件）。利用MAT剖析dump文件，MAT可以方便的按照大小排序实例，可以查看某些实例到GC ROOT的路径。
作者简介
军慧，美团点评Android高等工程师，2015年加入原美团，卖力美团点评到店餐饮业务美团Android App的开拓事情。
到店餐饮技能部交易与信息技能中央，卖力美团点评美食用户端业务，做事于数以亿计用户，通过更好的榜单、真实的评价和完善的信息为用户供应更好的决策支持，致力于提升用户体验；同时承载所有餐饮商户端线上流量，为餐饮商户供应多种营销工具，提升餐饮商户营销效率，终极达到让国人“Eat Better、Live Better”的美好愿景！
我们的团队包含且不限于Android、iOS、FE、Java、PHP等技能方向，已完备覆盖前后端技能栈。只要你来，就能点亮全栈开拓技能树。
不想错过技能博客更新？想给文章评论、和作者互动？第一韶光获取技能沙龙信息？
请关注我们的官方微信公众年夜众号“美团点评技能团队”。
