前言

本篇文章是《全面理解Android内存优化》系列文章的第二篇。系列的主要目的是希望将Android开发中涉及性能优化的部分做一次系统的归纳、总结和学习。本系列文章包含理论基础、工具使用、项目实践三个部分。

理论基础：「全面理解Android内存优化 1」-Android的内存机制与管理建议，主要讲解Android性能优化时涉及到的各种基础知识

工具使用：「全面理解Android内存优化 2」-内存优化工具的使用，主要讲解Android性能优化时各种常用工具的使用。

项目实践：「全面理解Android内存优化 3」-从理论到实践，以一个实际APP为例，总结在开发中会被忽视的内存问题。

本文中实战时使用的项目地址：https://github.com/linux-link/Fan，可以先阅读这篇文章了解这个项目一次组件化与Android Jetpack的实践

本篇属于三个部分中的工具使用部分。

目录

工具集
Memory Profiler
Memory Analyzer
Leak Canary
总结

正文

一、工具集

Android的内存分析工具随着时代的进步，一直在不停的推陈出新，这里只挑选了三个常用、易上手且能覆盖大多场景的工具。

工具	目标	能力	上手难度
Memory Profiler	内存泄漏、内存抖动、应用卡顿等	定位+实时追踪	中
Memory Analyzer	内存泄漏、内存占比	定位+发现	高
Leak Canary	Activity内存泄漏	定位+自动发现	低

下面就来分别介绍如果使用这些工具。

二、Memory Profiler

在Android Studio3.0之后Google使用全新的Android Profiler取代了原本的Android Monitor，全新的分析工具能够提供关于应用 CPU、内存和网络的实时数据。本文介绍的Memory Profiler就是Android Profiler的一部分。

Memory Profiler使用步骤：

1.在Android Studio工具栏点击下图红圈中的图标

2.选择程序运行的设备，这里我们选择实机

3.程序运行成功后，我们可以看如下界面，其中MEMORY一栏就是Memory profiler。点击Memoey的时间线图表，进入Memory Profiler。

4.Memory Profiler界面总览

如果需要要启用高级分析，请按以下步骤操作（当运行在Android 8.0及以上设备上时，会自动开启高级分析）：

1.选择 Run > Edit Configurations。
2.在左侧窗格中选择您的应用模块。
3.点击 Profiling 标签，然后勾选 Enable advanced profiling。

关于怎么打开memory profiler介绍完了，更多更详细的资料可以参考官方的中文资料，使用 Memory Profiler 查看 Java 堆和内存分配。Memory Profiler是在Android内存调试时最常用的分析工具，如果你还没有掌握Memory Profiler的使用，请务必仔细阅读，官方的中文文档非常的详细！

三、Memory Analyzer

上面介绍的Memory Profiler在做内存分析时，只能给出相对简单的分析，有的时并不一定能立即定位或确认内存泄漏的地方，这时候就需要结合Memory Analyzer来做进一步的分析了。

说起Memory Analyzer（内存分析器）你可能没有听说过，但是你一定听过它的简称MAT。MAT是IBM Eclipse的顶级开源项目，它的设计初衷是分析J2SE或J2ME下的Java类型的应用程序的内存问题。

MAT功能强大，操作也相对复杂，它本身是一个独立的工具，需要在Eclipse官方网站下载，下载地址：https://www.eclipse.org/mat/downloads.php

MAT使用步骤：

1.在Android Studio中打开Memory profiler，dump一段时间内的内存，并保存内存快照（Hprof）

接下来将Android Studio的内存快照转换为MAT支持的格式

2.打开终端，切换到Android SDK的platform-tools目录下

3.执行转换命令：hprof-conv 内存快照的地址 转换后写入内存快照地址

4.打开MAT，点击workbench进入MAT工作界面

5.点击File->open file,打开转换后的hprof文件。

怎么打开MAT就介绍完了，MAT工具十分的强大，操作也相对比较复杂，本文无法全面的介绍MAT全部功能，我们根据下图的标识，来着重介绍一些MAT中常用的功能，请仔细对号阅读。

1.Histogram

查看当前内存中每一个class具体产生了多少实例，以及这些实例的Shallow Heap和Retained Heap。例如：一个activity，在内存中产生一个以上的实例，那么这个activity就非常有可能发生内存泄漏。

在选中对象上右击选择List objetcts。

with outgoing references：当前类引用了哪些类。

with incoming references：当前类被哪些类引用。

这两个属性在内存泄漏的调试中经常使用，我们可以根据当前类的引用链一直追溯到真正导致内存泄漏的类，从而排除内存泄漏。

2.Dominator Tree

以百分比的形式展示出在当前内存中占据内存最多的对象实例。它也是我们在减少APP内存占用时需要重点要观察的地方之一。

3.Top Consumers

通过图形的形式列出来比较占用内存的对象。它的下面还有一个Biggest Objects，从名字上就能看出，它里面包含了在内存中占据内存最多的几个对象的信息。

Top Consumers和上面介绍的Dominator Tree都是我们在考虑减少APP内存占用时需要重点观察的地方。找到最占内存的对象实例，并尽可能的减小它占据的内存，如果是内存泄漏则应该直接回收它。

4.Leak Suspects

在Leak Suspects中会直接给出MAT对于内存中存在问题的分析，点击Details就能查看导致当前内存问题类的的引用链，MAT会自动化的帮助我们找到内存泄漏的具体原因，这也是MAT中查找内存泄漏最快的方法。

不过有时候，手机系统的内存问题也会在这里面给出反馈。对于手机系统的bug，可以不必理会。

5.OQL

OQL一种数据查询语言，使用它我们就可以一种类似SQL语句形式，查询出我们需要的类的信息。

6.thread_overview

产看当前内存中存在的线程信息。

7.unreachable Objects Histogram

内存中可被回收的对象，但是现在未被回收的对象，这些未被回收对象可以作为参考，并不一定是导致APP内存泄漏的原因。

MAT的大致使用，就介绍完毕了，下面我们来介绍一个Android开发中几乎一定会用到的一个第三方的内存泄漏检测框架——Leak Canary。

四、Leak Canary

Leak Canary是大名鼎鼎的Square公司专门为检测Android内存泄漏而开发一个第三方框架。需要注意的是，LeakCanary只能用来监控内存泄漏，它并不支持监控其他的内存问题。

github地址：https://github.com/square/leakcanary

英文帮助文档：https://square.github.io/leakcanary/

LeakCanary的使用

最新版的LeakCanary在使用时，不需要做任何初始化操作，只需要在项目的build.gradle中添加以下依赖即可。

dependencies  { 
  // debugImplementation，因为LeakCanary应该只在调试版本中运行。
  debugImplementation'com.squareup.leakcanary:leakcanary-android:2.0-beta-2' 
}

运行APP后会在手机生成一个Leaks的APP，当在我们在调试集成了LeakCanary的APP时（仅在debug模式下使用），如果检测到内存泄漏时，LeakCanary将自动在手机上显示通知，并将内存泄漏的信息保存在LeaksAPP中。

排查内存泄漏

当产生内存泄漏后，LeakCanary会给出如下图所示的内存泄漏的引用链。

泄漏跟踪中的每个节点都是Java对象，可以是类，对象数组或实例。每个节点都有一个对下一个节点的引用。在UI中，该引用为紫色。

在LeakCanary给出报告中，每一个节点都标识了是否正在发生泄漏，在它后面的括号中还给出相应的解释。

Leaking：YES 正在发生泄漏，
Leaking：NO 没有发生泄漏，
Leaking：UNKNOWN 未知。

大致观察LeakCanary的报告后，我们就需要开始缩小观察范围来确定内存泄漏的原因。

在LeakCanary有这样一条规则，如果一个节点没有泄漏，那么指向它的任何先前引用都不是泄漏源，也不会泄漏。同样，如果一个节点泄漏，那么泄漏跟踪下的任何节点也会泄漏。由此，我们可以推断出内存泄漏原因出现在最后一次Leaking：NO和第一次Leaking：YES之间类中。

在本例中就对应下图的这四个部分，泄漏的原因往往就出这里面。在报告中用红色下波浪线标出来的部分，是LeakCanary认为导致内存泄漏的原因，也是我们接下来要重点排查的地方。

我们直接查看Application中的leakedViews，会发现正是在Application中保存View的代码导致了内存泄漏的发生，接下来就是尝试如何修复这段代码了。

val leakedViews = mutableListOf <View>（）

示例只是给出，如何根据LeakCanary的报告，缩小排查范围，并一步步找到内存泄漏的原因，请不要去关注示例中的这段代码是如何会导致内存泄漏的。

实际开发中，通过引入LeakCanary基本就可以找到绝大多数的内存泄漏。通过定制LeakCanary，我们甚至有能力在APP发布后依然能够保证获取开发时遗漏的内存泄漏点，关于定制请参考LeakCanary的官方文档：https://square.github.io/leakcanary/recipes/

五、实际应用场景

上面介绍了三种各具特点内存分析与检测工具，在实际的开发中，我们应该根据项目组对于内存关注度的不同，组合使用不同的工具。

小团队

这类型团队是当前国内占比较多的一部分，Android开发组长期只有一两个人，APP的日活跃用户也比较少，却有着大量的需求亟待完成，甚至于需求本身可能都十分模糊。对于这样的团队关注的重心要集中在业务和功能上，如何保证APP不出bug才是重点。

建议：在APP中集成LeakCanary，整理、收集内存泄漏的报告，在空闲时尝试调试内存问题。调试之后一定要做充分测试，防止出现其他bug。

中等规模团队

这类型的团队基本长期都有三个人以上，APP的日活跃用户数比较多。这种团队的leader要适时关注一下APP的使用流畅度，着手解决APP中的内存泄漏、卡顿等问题，并定期发布相关的团队报告，让团队中其他人引以为戒。

建议：在APP中集成LeakCanary，每个开发人员在完成自己开发任务的同时，也要保证自己开发的功能不会出现被LeakCanary捕获的内存泄漏。如果不能根据LeakCanary定位内存泄漏的点，需要进一步使用MAT来排查。

团队的leader在版本发布前，要使用Memory Profiler监测每个新功能的内存时间线，图像的时间线相对平滑则是合格的。如果出现了剧烈波动的锯齿图像，表明出现了内存抖动，要着手修复，保持这样的节奏基本可以避免绝大多数内存方面的性能问题。监测的任务也可以交给团队内的测试人员。

六、总结

到这里，对于Android内存优化中常用的三种工具就介绍完了。熟练掌握各种分析工具的使用，能够帮助我们快速定位、解决开发中遇到的各种内存问题。既能帮助程序员提升自我，也能给用户一个良好的使用体验。

下一篇将会从实际的项目出发，来总结一下开发中会遇到的各种内存问题，感谢您的阅读！