一次解决Android OOM的经历

OOM

**OOM(Out Of Memory)**是Android应用开发中相信每个人都遇到过的问题,而OOM在crash log中的stack trace一般没有实际意义,因为是在分配内存的时候才会抛出OOM异常,而这个时候的stack trace和OOM的原因没有任何关系。所以OOM问题的定位和分析就需要多花费一些功夫。

下面,我就结合一个例子,来讲讲怎么定位OOM问题。

问题
在程序员们把代码写完,基本流程测试无误,准备要发布的时候,云测的结果却是:一大波OOM异常。没办法,只好重新打开电脑定位问题。
由于不是我一个人写的代码,所以直接看代码定位问题有点困难,这个时候就要上工具了。

1. 定性问题

1.1 定位问题,先定性
这是一个内存泄漏导致的OOM,还是应用本身设计不当,导致一次需要加载的内存过多,导致的OOM?
定位问题的方法很简单,看内存是不是一直在增长,如果在使用的过程中内存一直在增长,则很有可能是内存泄漏导致的。
1.2 推荐使用的工具
Android Studio自带的Memory Monitor,很简单的一个小工具,能够把应用内存实时展现出来,简单到我认为不需要多说了。如下图:
在这里插入图片描述在摆弄了几分钟之后,我发现了几个问题:

  1. app刚刚启动的时候,内存占用就很大,因为用了很多的贴图(设计不当)
  2. app在进入播放界面并且推出之后,即使什么操作都不做,内存一直在缓慢增长(内存泄漏)
  3. app在我退出再进的时候,内存占用几乎翻番(内存泄漏)
    其中,问题2很快就能猜出来,播放结束后MediaPlayer没有被释放,之后验证了下,解决。

2. 设计不当?优化!

这个问题就很泛了,比如,纯色的背景就不用图片来实现,不用超过需要像素值的图片,不加载显示范围之外的图片,等等。
最终找到了几张图片,只需要1280x720,给的图是1920x1080。同时简单实现了图片的LazyLoading。问题1基本凑合搞定。

3. 内存泄漏?

如果在使用过程中,内存曲线一直是上涨趋势,这就很有可能存在内存泄漏了。

3.1 查看堆的信息
Android SDK的工具集中就提供这样一个工具:Device Monitor。使用方法如下

1. 打开Android Device Monitor
2. 选择你要调试的进程
3. 点击Update Heap按钮

基本情况如下图:
在这里插入图片描述
可以看到基本的堆情况,以及堆内对象的概览。

3.2 查看Activity泄漏

常见的内存泄漏很多都是由于Activity对象不能被释放导致的,用下面的adb命令可以快速的定位到这个问题:
在这里插入图片描述
得到结果如下:
在这里插入图片描述
其中的ViewRootImpl、Activities、AppContexts数量很值得关注。
关于其他的输出含义,见developer docs
3.3 取heap dump
在基本确定内存有泄漏之后,就需要定位具体是哪个对象泄漏,好定位相关代码,这个时候就可以对heap dump进行分析。
heap dump就是一个内存heap的快照,可以用来很具体的分析内存里到底有什么。
首先,我们用Device Manager需要导出一个heap dump,如图所示
在这里插入图片描述
然后转化成java dump,用 Eclipse Memory Analyzer Tool (MAT) 来分析。
用platform-tools里的hprof-conv来转化:
在这里插入图片描述
转化完成之后,我们就可以用MAT来打开分析。
4. Eclipse Memory Analyzer Tool (MAT)
当我们用MAT打开dump时,看到的基本界面如下:
在这里插入图片描述
这里有几个概念需要了解:
1. Shallow Heap & Retained Heap
Shallow Heap的大小就是对象所占的内存空间,一般一个Object持有一个引用会需要32或者64bit的空间(取决于JVM)。
由于A对象持有B对象引用会导致B对象在GC中不会被销毁,所以由于被对象直接或者间接持有引用而不会被释放的对象的占用的内存总和,就是Retained Heap。
简单来说,Shallow heap就是对象占用的空间,Retained Heap就是假如对象被释放,连带能够释放出来的空间。

2. Dominator Tree
定义在这里。简单来说,Dominator Tree可以很好地观察Retained Heap大小。
通常,在dump中查看Histogram和dominator_tree就可以看出一些端倪,例如这个例子中,histogram图中,占用内存最多的是byte[]对象,通过右键 -> List object菜单,可以看到
在这里插入图片描述
基本上都是Bitmap对象,而且Bitmap有重复数据:
在这里插入图片描述
到这一步,可以继续追查是谁导致两份相同的数据不能得到释放,通过
右键 -> Path to CG root功能,可以追查到最终是被哪个对象持有导致不能被释放,结果如下:
在这里插入图片描述
到这里,问题基本就明白了:

DBHelper是一个单例静态对象,这个对象会持有一个Context对象,在代码中被当成Context传入DBHelper的是一个Activity对象,所以这个Activity不会被释放;当这个Activity被销毁重建时,新的Activity会重新加载ContentView,而老的Activity所持有的整个View的树全部不会被释放,同时View持有的图片也不会被释放,导致内存不够。
至此,整个问题基本已经找到,同时告诉我们,用单例最好不要持有Context对象,如果需求需要,查看下这个设计是否合理,以及使用的时候谨慎。

一个常用的MAT技巧

在分析内存占用的时候,通常可以看到各种占用最多的时Bitmap对象,这个时候,如果能直接显示这个Bitmap内容,那么找起来会方便很多。下面是一个查看的方法:
stackoverflow上回答见这里

结尾
整个过程我基本是参照Google官方文档 Investigating Your RAM Usage,可以读下这份文档。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Android OOM(Out of Memory)是一种常见的运行时异常,指的是应用程序内存不足的错误。当应用程序试图使用超过系统分配给它的内存时,就会出现这种异常。这可能是由于应用程序在后台加载大量数据、存储过多的对象或图像,或者由于系统资源管理器分配的内存不足所致。 为了解决Android OOM问题,您可以采取以下几种策略: 1. 优化您的代码以减少内存使用量:使用正确的数据类型,避免创建不必要的对象,限制图像和资源的数量,以及优化后台加载过程等。 2. 回收不再使用的内存:当您的应用程序不再需要使用某些内存时,应该及时回收它们。这可以通过调用垃圾回收器(Garbage Collector)来完成。 3. 避免在主线程上执行耗时操作:如果您的应用程序在主线程上执行耗时操作(如大量数据处理),这可能导致系统资源管理器超载,从而引发OOM异常。应该将这些操作移至后台线程。 4. 使用内存分析工具:内存分析工具可以帮助您识别内存泄漏和无效内存引用等问题,从而避免OOM异常的发生。 5. 配置您的应用程序以适应不同的内存配置:如果您正在开发一个需要大量内存的应用程序,您应该考虑在AndroidManifest.xml文件中配置您的应用程序以适应不同的内存配置。例如,您可以设置您的应用程序需要的最低和最高内存限制。 请注意,解决Android OOM问题是一个复杂的过程,需要您仔细分析和优化您的代码。如果您遇到了OOM问题,建议寻求专业的帮助或与开发社区进行讨论。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值