（原创）内存泄漏分析解决方案（三）：Memory Profiler介绍和使用
前言
上一篇讲了使用LeakCanary检测和分析内存泄漏
LeakCanary作为一个开源库，还是很好用的
但其实我们Android Studio也提供了内存检测工具
它的名字叫做Memory Profiler。
这篇博客就带大家来认识它
Memory Profiler使用
首先我们来看怎么打开Memory Profiler
在Android Studio中有两种方式打开Memory Profiler
第一种通过标题栏打开，如图所示
第二种通过下方菜单栏打开，如图所示
使用的话也很简单，首先运行起你的项目
然后点击Profiler窗口左上角的 + 号
选择你项目的包名
选择完成后，就会创建你项目的SESSIONS界面，如下图
当然，有时候AS会默认给你创建这个包名的SESSIONS
如果你想删除这个SESSIONS，右键删除即可
下面开始介绍如何进行内存分析
点击MEMORY进入到内存分析，界面如下：
1：强制调用GC进行内存回收
2：Dump the java heap
3: 记录内存分配情况， 此按钮仅在连接至运行 Android 7.1 或更低版本的设备时才会显示
4: 实时播放内存分配情况
5: 发生一些事件的记录（如Activity跳转，事件的输入、屏幕的旋转）
6: 放大/缩小时间线
7: 使用的内存时间线
8: 退出MEMORY，回到SESSIONS主界面
关于顶部的几种内存类型介绍
Java：java代码分配的内存
Native：c/c++代码分配的内存（有时候其实并没有使用c/c++代码，但还是会有Native的内存分配，因为Android Framework会去通过java代码访问一些需要使用Native的资源，如图像资源的Bitmap）
Graphics：图像缓存等，包括GL surfaces,GL textures等
Stack：栈内存（包括java和c/c++）
Code：代码的内存分配（例如代码，资源，libs等等）
Other：这个是系统都不知道什么类型的内存
Allocated：java分配的对象个数
点击一个时间线上的节点，然后点击Dump the java heap按钮
进入到如下界面：
可以看到提示有四个内存泄漏
按照图里的顺序，最后点击Jump to Source
可以定位到大概的泄漏代码位置
当然，和LeakCanary一样
Memory Profiler也不是能定位到所有的泄漏
比如，如果你怀疑一个Activity泄漏
你可以通过上面界面的Class列表
查看这个Activity在内存中的个数，
如果退出后个数并未减少，说明存在泄漏
可以继续按照上图的方式定位问题。
在Class列表里，点击Class Name可以对这些Class按照类名排序
如下图所示
在图片中可以看到如下列
Class Name：类名
Alloc Count:对象个数
Native Size:c/c++层内存大小（byte）
Shallow Size:java层内存大小（bytes）
Retained Size:这个是这个类中所引用到的对象的总大小*该类对象的个数
关于Memory Profiler的使用就介绍到这里，下面看一个实战小例子
Memory Profiler实战小例子
我们先来看这一段代码
class MainActivity2 : AppCompatActivity() {
lateinit var myHandler: MyHandler
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main2)
//传入activity对象
myHandler = MyHandler(this)
myHandler.postDelayed(Runnable {
Log.d("MainActivity2", "十分钟后日志打印")
}, 0x001, 1000 * 60 * 10)
}
class MyHandler(var mainContext: MainActivity2) : Handler() {
override fun handleMessage(msg: Message) {
super.handleMessage(msg)
}
}
}
运行这个代码，然后利用Memory Profiler进行分析
发现存在内存泄漏，并且定位到代码位置
class MyHandler(var mainContext: MainActivity2) : Handler() {
override fun handleMessage(msg: Message) {
super.handleMessage(msg)
}
}
因为代码里这个Handler有延时操作，在Activity退出后还持有了Activity对象的引用
所以存在内存泄漏
我们只需要在onDestroy方法里移除延时任务，即可修复这个泄漏
override fun onDestroy() {
super.onDestroy()
myHandler.removeCallbacksAndMessages(0x001)
}
这样，我们就通过Memory Profiler成功分析、定位、修复了这个内存泄漏
Memory Profiler注意事项
Profiler窗口里的MEMORY运行久了
这时候再进行内存分析，AS可能会出现卡死的情况
可能是需要分析的文件太多导致的
这时候可以先右键删除SEESIONS下的这个项目
然后重新添加进来即可
不影响内存分析的结果
最后还有个小Tip
内存泄漏的定位和分析
可以用Memory Profiler和LeakCanary两个工具互相验证
两个软件各有利弊
互相验证能让我们更好的确保内存泄漏问题的复现和解决