×

一个APP内存泄露问题的解决过程

96
会上网的井底之蛙
2017.06.28 21:52* 字数 1356

一、如何发现内存泄露了

1.打开android studio,运行APP,android studio底部栏选择 “Android Monitor”的“Monitors”视图

2.在Monitors界面的上部分,左边下拉框选择运行APP的手机或模拟器,右边下拉框选择要调试的APP进程。

3.在Monitors界面的中间部分重点关注“Memory”这一块的内存值的变化。

  当打开一个Activity后,已分配内存“Allocated”值会变大,再退出,按一下gc按钮

此时Activity正常情况下应该会被回收,已分配内存值“Allocated”应该会恢复成打开之前的值。

4.生成hprof文件进行验证与分析

点击“Dump java Heap”生成hprof文件

大概5秒后,hprof文件会被自动生成,并自动显示在代码浏览区域

此视图会显示对象的类型与实例个数,我们可以按包名进行分类,这样更方便查找自己定义的类

二、通过hprof文件分析内存泄露

用Package Tree View分类,能很快找到我们需要分析的Activity

(本APP的 launcher Activity点击进去,第二级的Activity名为MainActivity,当按返回按钮后,MainActivity正常情况下要被回收,我们正是分析MainActivity为什么发生内存泄露)

我在launcher Activity里点击进MainActivity 4次并返回,通过上图可以发现,回到launcher Activity后,MainActivty每次创建的Activity实例在返回后并没有被回收,如果这样重复操作很多次,程序肯定会因内存不足而崩溃。

点击上图的右上“Instance”区域里的某一个实例,在下方“Reference Tree”区域里会列出所有持有该实例的引用对象。


只靠人工分析hprof文件是否能找出内存泄露点?

        本APP的MainActivity非常复杂,所有子界面都采用的是Fragment来进行切换,持有MainActivity引用的其它对象众多,所以只靠人工这样去看,很难发现问题所在。有人建议使用MAT工具打开hprof文件进行分析,本篇有更简单的方法,即使用LeakCanary工具。

三、使用LeakCanary工具查找内存泄漏

1.进入“https://github.com/square/leakcanary”查看LeakCanary的最新版本与使用方法

最新版本是1.5.1,使用方法很简单,只有两步。

2.集成LeakCanary到APP中

第一步:build.gradle里添加依赖

debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'

第二步:在自定义Application中初始化

public class ExampleApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
// Normal app init code...
}
}

OK。

3.重新RUN APP,在模拟器中进行测试

   我进入MainActivity4次,做一些操作,最后每次都返回到launcher Activity中,不一会儿,模拟器标题栏收到4个通知图标

下拉点击某一个

4.进入details界面

上图中MainActivity对象生成后,从下到上一直追述到 android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mMainLooper,

同时我们可以查看logcat

显示android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mMainLooper为GC ROOT,正是因为MainActivtiy被GC ROOT所持有,所以它不能被收回,发生内存泄露。

5.分析leaks details界面

       里面引用MainActivity实例的都是系统对象,而且引用链条显示是直接的引用,换句话就是说,如果在MainActivity里有一个Fragment,Fragment里面的ImageView引用了MainActivity,那么此leaks details界面的引用链不会把Fragment实例显示出来,只会显示ImageView实例。

       这样又增加了分析的难度,但是仔细分析,我们发现中间有一个

       references android.support.v7.widget.AppCompatImageView.mContext

 说明是某个ImageView持有MainActivity引用没有被释放,而又有一条

      references android.animation.ValueAnimator$AnimationHandler.mAnimations

说明很可能是ImageView执行了属性动画,导致了内存泄露。

     分析到此处,我们大概锁定了内存泄露的点,由于代码很多,去一个一个找有点麻烦,那么就在项目里用关键字“ValueAnimator”或“ObjectAnimator”进行全局搜索  

    终于在“CustomProgressDialog.java”查找到了动画的使用,ivIcon刚好是一个ImageView实例

private void startPropertyAnim() {
// 第二个参数"rotation"表明要执行旋转
// 0f -> 360f,从旋转360度,也可以是负值,负值即为逆时针旋转,正值是顺时针旋转。
ObjectAnimator anim = ObjectAnimator.ofFloat(ivIcon, "rotation", 0f, 360f);
anim.setRepeatCount(INFINITE);
// 动画的持续时间,执行多久?
anim.setDuration(5000);
anim.setInterpolator(new LinearInterpolator());

// 正式开始启动执行动画
anim.start();
}

6.分析定位出的代码,修正

CustomProgressDialog是一个自定义对话框,对话框显示时,ImageView会执行旋转动画,但是对话框消失时,动画并没有被取消,导致了内存泄露。最后进行修正

private void startPropertyAnim() {
// 第二个参数"rotation"表明要执行旋转
// 0f -> 360f,从旋转360度,也可以是负值,负值即为逆时针旋转,正值是顺时针旋转。
if (anim != null){
anim.cancel();
}

anim = ObjectAnimator.ofFloat(ivIcon, "rotation", 0f, 360f);
anim.setRepeatCount(INFINITE);
// 动画的持续时间,执行多久?
anim.setDuration(5000);
anim.setInterpolator(new LinearInterpolator());

// 正式开始启动执行动画
anim.start();
}

@Override
public void dismiss() {
super.dismiss();
if (anim != null){
anim.cancel();
}
}

最后重新运行修改的程序,测试,发现内存泄露成功解决。

总结:

        当项目比较小,代码量不多时,可能人工检查一下,就能解决内存泄露的问题,但是当项目越来越庞大,代码量非常大时,就需要利用工具来帮助进行检查。就像上面这个问题,在没有利用工具的情况下,本人花了大量时间看代码都没有检查出来,而利用工具,很好的进行了定位,查找起来方向性非常明确,最后顺利解决隐藏很深的一个内存泄露点。

日记本
Web note ad 1