android内存泄漏 OOM查找总结

本篇文章已授权微信公众号 guolin_blog (郭霖)独家发布

前言

先通俗理解下内存泄漏,内存溢出,OOM,GC回收这几个概念。
把app的堆内存空间想成了一个杯子,内存就是里面的水。
当你的app启动后,系统会分配给app一个堆空间,起始不会很大比如是32M(根据你的app启动时的内存申请为准)


image.png
  • 随着程序的运行对象的创建越来越多,系统不断加内存分配:32M -> 64M -> ...
  • 而GC回收则会定时扫描内存,发现不被引用的对象即可回收。
    正常来说你的app堆内存会有升有降。
    此时如果有某个Activity持有某个引用,在onDestroy时还不把这个引用设为null,那么返回进入退出这个界面,Activity就会创建很多次从而存在多个实例,导致堆内存直升不降!这就叫做内存泄漏。

当用户重复这个操作或者有多个不同Activity内存泄漏时,app运行一段时间堆内存超过系统规定的最大值 heapSize,杯子满了就会发现内存溢出(OOM),app崩溃。

关键点

通过上面这个例子,我们知道查找内存泄漏有如下几点关键点:

  1. 如何知道你的app上限值heapSize是多少
  2. 什么情况导致无法GC
  3. 怎么复现是哪个界面内存泄漏
    下面通过一个实例来演示,如何借助AndroidStudio查找内存泄漏:

内存泄漏实例

当你的app在使用中莫名崩溃,如果是OOM那么会有如下日志:


image.png

接下来我们用下面的代码获取heapsize:

ActivityManager manager = (ActivityManager)getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getMemoryClass();
int maxHeapSize = manager.getLargeMemoryClass();  // manafest.xml   android:largeHeap="true"
  • heapSize是设备分配给app的最大堆内存
  • maxHeapSize 是当配置了android:largeHeap="true" 才有的最大堆内存,一般是heapSize的2-3倍
    以HTC ONE为例,两个值分别是: 192M和512M。这里我只关注192M,maxHeapSize放到后面再说。然后尝试复现问题,手机连接AndroidStudio打开monitor,反复进入/退出怀疑内存泄漏的界面:


    image.png

    如果发现内存一直上升,并且到接近192M的时候不动了,此时已经OOM只不过不一定会崩溃(oom异常可以try catch)

  • 接着,用AndroidStudio自带的内存分析工具分析,点击Dump Java Heap:


    image.png

(备注:ViewDefectPhotoActivity是我的app里面一个界面,用ViewPager展示,ImageLoader加载很多照片)

会在代码区 生成当前时间点的 .hprof格式文件,里面当前的每个对象 内存占用情况,我们现在怀疑ViewDefectPhotoActivity 可能内存泄漏 看一下:ViewDefectPhotoActivity 确实占用了很高的内存 而且有8个实例化对象,足以证明它有内存泄漏,随便点击其中一个,发现都和EditDefectActivity的内部类 ShowEditDefectHelper有关。而且ShowEditDefectHelpe前面带有 黄蓝三角树 这个图标表示,他可以被GC访问到,也就是无法回收:


image.png

接下来看看ShowEditDefectHelper这个对象持有什么引用,右键点击 Go To Instance:


image.png

发现这个内部类也被实例化多次,随便点击一个,发现属于EventBus的引用 ,并且EventBus带有黄蓝图标,那么问题就大概找到了,因为EventBus一直持有这个内部类的引用,导致这个内部类无法被回收,而这个内部类持有ViewDefectPhotoActivity引用,导致ViewDefectPhotoActivity无法被回收 这个界面有很多图片资源 当实例化7,8次之后 出现了OOM。

EventBus是用于事件通知的开源库,应该很多人都了解。它需要在某个类里面绑定和解绑定,我这里是在ShowEditDefectHelper注册的,看下Activity的内部类ShowEditDefectHelper:


image.png

解释下这里的逻辑:进入这个activity我会显示一个进度条,请求网络数据,用户可以随时取消进度条。然后onCancel里面对EventBus解绑定:
但是这里有个低级错误:EventBus.getDefult().unregister(this)传入的this是onCancelled()的匿名内部类而不是ShowEditDefectHelper.class导致EventBus无法解绑!
!
所以应该这么解绑:
EventBus.getDefult().unregister(ShowEditDefectHelper.Class);


通过这个示例,我们回答了上面前两个关键点:

  1. 如何知道你的app上限值heapSize是多少
  2. 什么情况导致无法GC
    第三个关键点:3. 怎么复现是哪个界面内存泄漏。内存泄漏不是一眼就能看出来了,需要测试人员配合。当然还有一个办法就是facebook的开源库:leakcanary,具体使用我不多介绍了。它是一个apk安装在手机上可以直接列出内存泄漏的Activity,但是有一定误报几率:


    image.png

我更喜欢leakcanary + AndroidStudio的方式,精确无误地找出问题。

怎么避免内存

一句话归纳:(生命周期比Activity长的类不要去强引用Activity)

  1. 内部类请使用static,因为非静态内部类默认持有外部类的引用,比如在Activity里面直接放一个自定义的Adapter

  2. 静态类(比如Application,单例类,其他static类)请不要持有Activity引用,因为静态类生命周期比Activity长。解决办法:在需要的地方用BaseApplication.getTopActivity。或者Activity作为弱引用传入

  3. 注意Handler会默认持有当前Activity,用的时候最好不要直接new Handler().post(new Runnable...),除非你确定这个runnable会在Activity销毁前执行完

OK,假设你的项目比较紧急,想暂时规避内存泄漏问题怎么办?可以在manifest.xml加入本文开头给的那个设置:

android:largeHeap="true"

此时heapsize会增大2-3倍,缓解OOM的发生,但是技术债终究要还的。希望大家认真揣摩本文用AndroidStudio分析泄漏的方法,而不是过分依赖leakcanary这个开源库。

推荐阅读更多精彩内容