演示用Profiler+MAT+LeakCanary排查Android内存泄漏问题演示用Profiler+MAT+LeakCanary排查

首先写一段存在内存泄漏问题的代码：

public class MainActivity extends AppCompatActivity {@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); //Activity退出时，内部类handler仍一直运行，且拥有activity引用，导致内存泄漏 handler.sendEmptyMessageDelayed(HANDLER_FLAG,1000); }private int HANDLER_FLAG = 1; private Handler handler = new Handler() { @Override public void handleMessage(@NonNull Message msg) { super.handleMessage(msg); handler.sendEmptyMessageDelayed(HANDLER_FLAG,1000); } }; }

使用Android Profiler 在模拟器中运行该Activity所在的App，然后打开Profiler:

演示用Profiler+MAT+LeakCanary排查Android内存泄漏问题

文章图片
打开profile 打开MEMORY监控：

文章图片
双击MEMORY部分 DUMP一段运行中的内存快照：

文章图片
查看DUMP信息，可以看到我们的Activity（com.example.memerytest.MainActivity）占用了内存，并且也看到了内部类handler：

文章图片
DUMP信息 【演示用Profiler+MAT+LeakCanary排查Android内存泄漏问题】点击Attach to live按键继续查看MEMORY信息：

文章图片
点击模拟器中的back按键，关闭app，并且点击profiler中的Force GC按键强制进行GC：

文章图片
再次DUMP内存快照，查看后发现，Activity的内存并没有被GC。
我们可以右键时间线上DUMP的那段信息，或者通过左侧DUMP列表，来将DUMP信息保存为hprof文件：

文章图片
要让DUMP信息可供其他工具（如MAT）使用，需要转为Java SE HPROF格式，可以通过android sdk自带的工具转换：

sdk/platform-tools/hprof-conv input.hprofoutput.hprof

MAT 安装 Memory Analyzer Tool
下载地址：
http://www.eclipse.org/mat/downloads.php
注意下载时要将镜像站点选为国内站点。Mac系统如果遇到无法启动的问题，可以参考https://yq.aliyun.com/articles/642590
使用抓取了三段DUMP:
1，第一次打开应用
2，按back退出应用
3，多次打开关闭应用
通过MAT加载我们转换过的HPROF文件，先在dominator_tree中搜索MainActivity：

文章图片
第一次打开应用

文章图片
按back退出应用

文章图片
多次打开关闭应用
可以明显地看到，MainActivity一直没有被GC，没开启一次应用，MainActivity就多一份内存占用。
我们还能使用Histogram中的对比功能对两个HPROF文件进行对比，更直观地发现问题：

文章图片

文章图片

上图是第一次打开应用的DUMP和多次打开应用的DUMP对比，过滤“MainActivity”能很明显地发现，多次打开关闭app后，MainActivity对象多了12个，堆内存占用共多了4032字节。
LeakCanary LeakCanary是一种嵌入在应用中的内存泄漏检测工具。不需要添加代码，只需要添加一行依赖：

dependencies { ... debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.3' }

应用编译运行后，一旦出现可能的内存泄漏场景，LeakCanary就会在通知栏发消息：

文章图片

点击通知栏消息，里面有详细的DUMP信息，也有明确的内存泄漏点：

文章图片

点击下方的提示，可以很明确的看到，引起内存泄漏的是MainActivity，并且原因是Message.target(就是Handler)处理的消息队列处于阻塞等待状态，导致引用的外部类不能被GC：

文章图片
内存泄漏问题的解决方案 1，使用softreference
只会在内存不足的情况下才会回收softreference泄漏的内存
2，weakreference
一旦GC就会被回收
3，使用static修饰内部类
这样内部类就不会持有外部类的引用。但会造成额外的内存消耗。
如果有耗时的线程内部类，将其改为静态内部类。在线程内部采用弱引用保存Context引用。
4，外部类生命周期结束时，解除内部类对其的应用
比如在onDestroy时，清空内部Handler的消息队列（removeMessages）
5，良好的业务设计
如果我们充分了解各个类的生命周期和应用关系，并且熟悉业务场景，那么也可以不通过上面的保护措施，而是通过良好的业务涉及来避免内存泄漏
关于GC算法标记算法：
1）引用计数算法
2）可达性分析算法
清除算法：
1）标记清除算法
2）复制算法
3）标记压缩算法
4）分代垃圾收集算法
LeakCanary 原理分析 1，用ActivityLifecycleCallbacks接口来检测Activity生命周期，主要是在onDestroy()方法中，手动调用 GC，然后利用ReferenceQueue+WeakReference 监听对象回收情况，来判断是否有释放不掉的引用。
2，LeakCanary会单独开一进程，用来执行分析任务，和监听任务分开处理。Application中可通过processName判断是否是任务执行进程；
3，利用主线程空闲的时候执行检测任务，在MessageQueue中加入了一个IdleHandler来得到主线程空闲回调；,
4，LeakCanary检测只针对Activiy里的相关对象。其他类无法使用，还得用MAT原始方法