Android AndroidStudio MAT LeakCanary 内存分析之 AndroidStudio 内存泄漏分析 Memory Monitor

Android AndroidStudio MAT LeakCanary 内存分析之 初识内存泄漏
http://blog.csdn.net/qq_28195645/article/details/51733342

Android AndroidStudio MAT LeakCanary 内存分析之 AndroidStudio 内存泄漏分析 Memory Monitor
http://blog.csdn.net/qq_28195645/article/details/51734506

Android AndroidStudio MAT LeakCanary 内存分析之 LeakCanary
http://blog.csdn.net/qq_28195645/article/details/51734987

Android AndroidStudio MAT LeakCanary 内存分析之 DDMS+MAT
http://blog.csdn.net/qq_28195645/article/details/51735522

前面 说到内存泄漏引发的原因、Android AndroidStudio MAT LeakCanary 内存分析之 初识内存泄漏

那么在开发过程中要尽量避免内存泄漏、当然我们也很难完全避免。如果出现泄漏我们就去找到万恶的根源。
首先最简单的、就是AndroidStudio, as1.5以上已经提供了这个功能,我们就直接基于as来分析岂不是很方便

ok、写一段内存泄漏的code

    private TextView txt;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_analyze);
        txt = (TextView) findViewById(R.id.txt);
        Handler handler = new Handler();
        handler.postDelayed(new Runnable() {
            @Override
            public void run() {
                txt.setText("Done");
            }
        }, 800000L);
    }

注意这个匿名的Runnable被送到了Handler中,而且延迟非常的长。现在我们运行这个Activity,反复旋转屏幕。
为什么会内存泄漏、阅读过上篇文章(Android AndroidStudio MAT LeakCanary 内存分析之 初识内存泄漏)的道友已经明白了。在翻转屏幕的时候Activity 就 Destroy了、但是runnable中的TextView还持有着Activity的引用,那么导致Activity不能被GC、导致内存泄漏

在执行这些操作时先打开 Android Monitor 并定位到Memory部分
这里写图片描述
在Memory一栏中,可以观察不同时间App内存的动态使用情况,点击这里写图片描述可以手动触发GC,点击这里写图片描述可以进入HPROF Viewer界面,查看Java的Heap 再点击这里写图片描述Analyzer Task,Android Monitor就可以为我们自动分析泄漏的Activity啦。执行完这些操作、as会自动打开*.hprof文件、这些文件可以用map打开、我们直接通过as来分析吧

(通过Dump java heap 和allocation tracking获取的文件都在 Camptures)如下
这里写图片描述

在我们分析之前、先看看各部分所代表的含义
这里写图片描述

Reference Tree代表指向该实例的引用,可以从这里面查看内存泄漏的原因,Shallow Size指的是该对象本身占用内存的大小,Retained Size代表该对象被释放后,垃圾回收器能回收的内存总和。

ok、点击红色箭头部分 Analyzer Tasks、打开后再点击绿色箭头进行分析

LeakedActivity 就是出现内存泄漏的activity 可以看到就是之前我们写的MemoryAna….

这里写图片描述
在instance中 我们可以右键 jump to Source跳到对应code中

找到元凶了、我们把他解决了吧

使用弱引用 + static Runnable
现在我们把刚刚内存泄露的罪魁祸首 - TextView改成弱引用。
最后onDestroy来手动控制生命周期

public class MemoryAnalyzeRightActivity extends Activity {
    private TextView txt;
    private Handler mHandler = new Handler();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_memory_analyze);
        txt = (TextView) findViewById(R.id.txt);

        Handler handler = new Handler();

        handler.postDelayed(new DoneRunnable(txt), 800000L);
    }

    private static final class DoneRunnable implements Runnable {
        private final WeakReference<TextView> txtWeak;

        private DoneRunnable(TextView txtWark) {
            this.txtWeak = new WeakReference<>(txtWark);
        }

        @Override
        public void run() {
            final TextView textView = txtWeak.get();
            if (textView!=null){
                textView.setText("Done");
            }
        }
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }
}

是不是很简单、下一篇会说到利用强大的LeakCanary来检测 内存泄漏

阅读更多
个人分类: Android进阶
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭