Android OOM案例分析

柔情只为你懂 2023-10-17 19:56 3阅读 0赞

在Android（Java）开发中，基本都会遇到`java.lang.OutOfMemoryError`（本文简称OOM），这种错误解决起来相对于一般的Exception或者Error都要难一些，主要是由于错误产生的root cause不是很显而易见。由于没有办法能够直接拿到用户的内存dump文件，如果错误发生在线上的版本，分析起来就会更加困难。本文从一个具体的案例切入，介绍OOM分析的思路及相关工具的使用。

### 案例背景 ###

在美团App 7.4~7.7版本期间，美食业务的OOM数量居高不下，远高于历史水平，主要都是DECODE本地的资源出错。  
![oom_trend.png][]  
图中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的机器的特征，主要是内存和分辨率，适当考虑其它因素例如系统版本。

<table> 
 <thead> 
  <tr> 
   <th>机型</th> 
   <th>内存</th> 
   <th>分辨率</th> 
   <th>OS</th> 
   <th>stack log</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>OPPO N1(T/W)</td> 
   <td>2G</td> 
   <td>1920*1080</td> 
   <td>4.2.2</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
  <tr> 
   <td>HM 2LTE-CMCC</td> 
   <td>1G</td> 
   <td>1280*720</td> 
   <td>4.4.4</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
  <tr> 
   <td>Newman CM810</td> 
   <td>2G</td> 
   <td>1920*1080</td> 
   <td>4.4.4</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
  <tr> 
   <td>LGL22</td> 
   <td>2G</td> 
   <td>1830*1080</td> 
   <td>4.2.2</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
  <tr> 
   <td>OPPO X909</td> 
   <td>2G</td> 
   <td>1920*1080</td> 
   <td>4.2.2</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
  <tr> 
   <td>Lenovo K900</td> 
   <td>2G</td> 
   <td>1920*1080</td> 
   <td>4.2.2</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
  <tr> 
   <td>GiONEE E6</td> 
   <td>2G</td> 
   <td>1920*1080</td> 
   <td>4.2.1</td> 
   <td>java.lang.OutOfMemoryError <br>at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)</td> 
  </tr> 
 </tbody> 
</table>

这些特征可以总结为：内存一般，分辨率偏高，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\[\]实例。  
![oom_dump_step_1.png][]

右击其中一个数组->Path to GC Roots-> exclude xxx references  
![oom_dump_step_2.png][]  
如上图所示，这些byte\[\]都是系统的EdgeEffect的drawable所持有，drawable对应的bitmap占用的空间为1566 \* 406 \* 4 = 2543184，与byte数组的大小一致。

再看另外一个：  
![oom_dump_step_3.png][]

这些byte\[\]是被App的一个背景图所持有，如下图：  
![oom_dump_step_4.png][]  
通过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`系统调用获取的。

/**
     * Construct a new EdgeEffect with a theme appropriate for the provided context.
     * @param context Context used to provide theming and resource information for the EdgeEffect
     */
    public EdgeEffect(Context context) {
        final Resources res = context.getResources();
        mEdge = res.getDrawable(R.drawable.overscroll_edge);
        mGlow = res.getDrawable(R.drawable.overscroll_glow);
    
            ******
    
        mMinWidth = (int) (res.getDisplayMetrics().density * MIN_WIDTH + 0.5f);
        mInterpolator = new DecelerateInterpolator();
    }

ImageView(View)获取background对应的drawable的过程类似。

for (int i = 0; i < N; i++) {
        int attr = a.getIndex(i);
        switch (attr) {
            case com.android.internal.R.styleable.View_background:
                background = a.getDrawable(attr); // TypedArray.getDrawable
                break;
            ******
        }
    }

不论是Resources.getDrawable还是TypedArray.getDrawable，最终都会调用Resources.loadDrawable。继续看`Resources.loadDrawable`的源码，发现的确是使用了缓存。对于同一个drawable资源，系统只会加载一次，之后都会从缓存去取。

既然drawable的加载机制并没有问题，那么drawable所在的缓存实例或者获取drawable的Resources实例是否是同一个呢？通过下面的代码，打印出每个Activity的Resources实例及Resources实例的drawable cache。

//noinspection unchecked
    LongSparseArray<WeakReference<Drawable.ConstantState>> cache = (LongSparseArray<WeakReference<Drawable.ConstantState>>) Hack.into(Resources.class).field("mDrawableCache").get(getResources());
    Object appCache = Hack.into(Resources.class).field("mDrawableCache").get(getApplication().getResources());
    Log.e("oom", "Resources: {application=" + getApplication().getResources() + ", activity=" + getResources() + "}");
    Log.e("oom", "Resources.mDrawableCache: {application=" + appCache + ", activity=" + cache + "}");

![oom_log.png][]

这也进一步解释了另外一个现象，即这些大小相同的数组的个数基本和启动Activity的数量成正比。

通过数据分析可知，这些drawable之所以存在多份，是因为其所在的Resources实例并不是同一个。进一步debug可知，Resources实例存在多个的原因是开启了标志位[sCompatVectorFromResourcesEnabled][]。  
虽然最终造成OOM突然增多的原因只是开启一个标志位，但是这也告诫大家阅读API文档的重要性，其实很多时候API的使用说明已经明确告知了使用的限制条件甚至风险。

7.8版本关闭了此标志，发版后第一个月的OOM数量（包含历史版本）为153，如下图。  
![oom_trend2.png][]  
其中新版本发生的OOM数量为22。

### 总结 ###

对于线上出现的OOM，如何分析和解决可以大致分为三个步骤：

1.  充分挖掘特征。在挖掘特征时，需要多方面考虑，此过程更多的是猜测怀疑，所以可能的方面都要考虑到，包括但不限于代码改动、机器特征、时间特征等，必要时还需要做一定的统计分析。
2.  根据掌握的特征寻找稳定的复现的途径。一般需要做内存压力测试，这样比较容易达到OOM的临界值，只是简单的一些正常操作难以触发OOM。
3.  获取可分析的数据（内存dump文件）。利用MAT分析dump文件，MAT可以方便的按照大小排序实例，可以查看某些实例到GC ROOT的路径。

### 作者简介 ###

军慧，美团点评Android高级工程师，2015年加入原美团，负责美团点评到店餐饮业务美团Android App的开发工作。

到店餐饮技术部交易与信息技术中心，负责美团点评美食用户端业务，服务于数以亿计用户，通过更好的榜单、真实的评价和完善的信息为用户提供更好的决策支持，致力于提升用户体验；同时承载所有餐饮商户端线上流量，为餐饮商户提供多种营销工具，提升餐饮商户营销效率，最终达到让国人“Eat Better、Live Better”的美好愿景！我们的团队包含且不限于Android、iOS、FE、Java、PHP等技术方向，已完备覆盖前后端技术栈。只要你来，就能点亮全栈开发技能树。

**发现文章有错误、对内容有疑问，都可以关注美团点评技术团队微信公众号（meituantech），在后台给我们留言。我们每周会挑选出一位热心小伙伴，送上一份精美的小礼品。快来扫码关注我们吧！**

![公众号二维码][1521521024099-image.png]

[oom_trend.png]: https://tech.meituan.com/img/oom-analysis/oom_trend.png
[oom_dump_step_1.png]: https://tech.meituan.com/img/oom-analysis/oom_dump_step_1.png
[oom_dump_step_2.png]: https://tech.meituan.com/img/oom-analysis/oom_dump_step_2.png
[oom_dump_step_3.png]: https://tech.meituan.com/img/oom-analysis/oom_dump_step_3.png
[oom_dump_step_4.png]: https://tech.meituan.com/img/oom-analysis/oom_dump_step_4.png
[oom_log.png]: https://tech.meituan.com/img/oom-analysis/oom_log.png
[sCompatVectorFromResourcesEnabled]: https://developer.android.com/reference/android/support/v7/app/AppCompatDelegate.html#setCompatVectorFromResourcesEnabled%28boolean%29
[oom_trend2.png]: https://tech.meituan.com/img/oom-analysis/oom_trend2.png
[1521521024099-image.png]: https://tech.meituan.com//img/1521521024099-image.png