什么是内存泄漏
内存泄漏（Memory Leak）是指程序中已动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
以上是官方针对内存泄漏的说法。说的通俗一点，应该释放的内存没有被正常释放，就是内存泄漏。当我们程序出现内存泄漏后，轻则影响运行速度，重则内存溢出，造成程序崩溃。
内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存
所以，当我们程序出现疑似内存泄漏的时候，千万要引起重视。
如何识别内存泄漏
找出程序中有内存泄漏风险的代码，我们可以通过人工去review代码，找出内存泄漏并解决掉；也可以借助adb命令去观察相关状态；也可以借助AndroidStudio提供的Profiler工具来检测。
Activity 内存泄漏检测用法
主要用到Profiler模块：
页面泄漏案例：
创建两个Activity 一个为默认Activity A，一个demo的Activity B，A启动B，然后在按下返回退出B页面，B中代码如下：
class ProfilerMainActivity : AppCompatActivity() {
companion object {
//定义一个静态变量，引用Activity实例
var refAct: ProfilerMainActivity? = null
}
private lateinit var student: Student
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_profiler_main)
//让静态变量一直持有当前实例
refAct = this
student = Student()
student.sayHello()
}
}
接下来，我们先使用Profiler工具的Capture heap dump抓取一段内存堆数据：
A启动B后：
此时还是正常的情况
退出B
当我们退出B页面时重新抓取一段：
可以看出Activity的ondestroy生命周期已经执行完成，按道理页面已经被销毁，内存中不应该继续有该对象，而该对象正是被上面的静态变量引用导致GC一直不能释放该对象。
模拟解决该问题
在上面页面中finish操作：
class ProfilerMainActivity : AppCompatActivity() {
//省略。。。。
override fun finish() {
super.finish()
refAct = null
}
}
再重复上面抓取步骤抓取一次内存数据：
可以看出，内存中仍然存在该对象，但是该对象已经没有谁引用他，那么 他将会在下一次GC回收垃圾时，被回收掉，这里我们直接强制GC执行垃圾回收，看看猜测是否正确：
抓取
可以发现，ProfilerMainActivity实例已经不再出现在内存当中。
使用Record Java/Kotlin allocations
主要记录一段时间中堆的对象个数、销毁时间
还是上面的代码 这次我们看Studen这个对象，执行操作A–》B–》A–》B，然后多次强制执行垃圾回收，抓取数据如下
看上图，Studen被创建两次，所以整个过程一共记录了两个对象，1和2，他们之间的区别是1中 Dealloc Time 不为空，没有Instance details 因为Student在第一次启动页面时创建，退出B页面后，被GC回收了 整个活跃时间为1s05ms，而2中Dealloc Time不为空 说明还没被回收，Instance details中记录了这个对象的堆栈信息，还在堆中活跃。全文讲解了在Android开发中经常遇到的内存泄漏问题，以及如何使用Profiler工具检测。更多有关Android性能优化相关的技术可以参考《Android性能优化解析》点击可以查看详细的性能优化板块。
总结
Profiler工具为了我们能方便查看内存泄漏的地方，专门提供了一个View app heap 分类来报告哪些页面泄漏，同时，我们还可以在里面查看非页面类有没有正常被释放，比如单例，当我们退出某个功能后，手动把单例置为空（”销毁“），我们只需在强制GC后抓取一段内存数据查看该对象是否仍在活跃即可。
