内存泄露作业

Bug项目地址
MemoryBugs

第一�步

打开ActivityB，leakcanary直接ANR

LeakCanary ANR

查StackOverFlow得知在6.0需要权限：WRITE_EXTERNAL_STORAGE

第二步

LeakCanary成功弹出通知
log打印：

• Reference Key: 42c5fe29-3abe-49bf-b745-2bae8b6e170a
• Device: Genymotion Android Google Nexus 5X - 6.0.0 - API 23 - 1080x1920 vbox86p
• Android Version: 6.0 API: 23 LeakCanary: 1.3.1
• Durations: watch=5020ms, gc=107ms, heap dump=2226ms, analysis=3173ms
  但是通知详情里提示分析失败。。 leak analysis failed

�analysis failed

升级LeakCanary到1.4 beta2后成功监测到内存泄露

�检测到内存泄露

第三步

可以看到�内存泄露是TextView持有MainActivity引用造成的，最简单的解决办法就是取消sTextView的static关键字，那如果非要采用静态的呢？

我们再用Dump Heap查看一下
在MainActivity界面，Dump

�启动ActivityB之前

可以看到ActivityB数量是0，MainActivity数量1
接下来我们启动ActivityB，然后点击initiate GC将MainActivity回收

�启动ActivityB并点击initiate GC后

可以看到MainActivity仍然没有被回收

那么该怎么解决呢？
想到用弱引用activity来findView，结果仍然泄露，因为find到的TextView对象还是持有Activity的引用

WeakReference weakReference = new WeakReference<>(this);
sTextView = (TextView) weakReference.get().findViewById(R.id.tv_text);

于是，弱引用textview，依然泄露。这里不懂为什么

sTextView = new WeakReference<>((TextView) findViewById(R.id.tv_text)).get();

�怒了，在onDestory中释放资源

    @Override
    protected void onDestroy() {
        super.onDestroy();
        sTextView = null;
    }

成功！leakcanary不再监测到泄露。可以看到log里触发了GC

I/System.out: post delayed may leak
I/art: Starting a blocking GC Explicit
I/art: Explicit concurrent mark sweep GC freed 539(43KB) AllocSpace objects, 0(0B) LOS objects, 40% free, 1483KB/2MB, paused 174us total 4.290ms

在ActivityB界面我们initial GC一下，发现MainActivity被回收了

MainActivity被回收

这里Handler可能也会造成内存泄露，我们在打开ActivityB时，5秒内initial GC，然后LeakCanary就弹出了通知：

Snip20160401_15.png

显然这里泄露了，我们改写Handler为静态内部类

    // 解决Handler造成的内存泄露
    private MyHandler mHandler = new MyHandler(this);

    public static class MyHandler extends Handler {
        private WeakReference  mWeakReference;

        public MyHandler(MainActivity activity) {
            mWeakReference = new WeakReference<>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
        }
    }

再测试就不会发生这种问题了。

第四步

点击STARTALLOCATION按钮出现了内存抖动
log打印了一大堆100后停止打印，log最后三行如下，但是App没有ANR也没有FC。

s I/Choreographer: Skipped 60 frames!  The application may be doing too much work on its main thread.
W/EGL_emulation: eglSurfaceAttrib not implemented
W/OpenGLRenderer: Failed to set EGL_SWAP_BEHAVIOR on surface 0xdf81e4e0, error=EGL_SUCCESS
E/Surface: getSlotFromBufferLocked: unknown buffer: 0xe02c5f70

打开Allocation Tracking 如图

Allocation Tracking

发现MainActivity里有20001个对象，基本一半是Rect一半是StringBuilder。。。说明打印10000次是全部执行完了。这里可以发现，用+进行字符串拼接时，系统实际还是通过StringBuilder来拼接的

第五�步

将MyView的onDraw方法中new对象的操作放到构造中，不然会造成内存抖动，因为onDraw会被频繁调用。

大概就这些。。没找到其他可优化的地方了