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

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:

打开profile

打开MEMORY监控：

双击MEMORY部分

DUMP一段运行中的内存快照：

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

DUMP信息

点击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.hprof  output.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原始方法

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