前言

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

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

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

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

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

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

一、工具集

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

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

二、Memory Profiler

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

Memory Profiler使用步骤：
1.在Android Studio工具栏点击下图红圈中的图标

如果需要要启用高级分析，请按以下步骤操作（当运行在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）
with outgoing references：当前类引用了哪些类。
with incoming references：当前类被哪些类引用。
这两个属性在内存泄漏的调试中经常使用，我们可以根据当前类的引用链一直追溯到真正导致内存泄漏的类，从而排除内存泄漏。
2.Dominator Tree
以百分比的形式展示出在当前内存中占据内存最多的对象实例。它也是我们在减少APP内存占用时需要重点要观察的地方之一。
image
Top Consumers和上面介绍的Dominator Tree都是我们在考虑减少APP内存占用时需要重点观察的地方。找到最占内存的对象实例，并尽可能的减小它占据的内存，如果是内存泄漏则应该直接回收它。
4.Leak Suspects
在Leak Suspects中会直接给出MAT对于内存中存在问题的分析，点击Details就能查看导致当前内存问题类的的引用链，MAT会自动化的帮助我们找到内存泄漏的具体原因，这也是MAT中查找内存泄漏最快的方法。
不过有时候，手机系统的内存问题也会在这里面给出反馈。对于手机系统的bug，可以不必理会。
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中。
泄漏跟踪中的每个节点都是Java对象，可以是类，对象数组或实例。 每个节点都有一个对下一个节点的引用。在UI中，该引用为紫色。
在LeakCanary给出报告中，每一个节点都标识了是否正在发生泄漏，在它后面的括号中还给出相应的解释。
Leaking：YES 正在发生泄漏，
Leaking：NO 没有发生泄漏，
Leaking：UNKNOWN 未知。
大致观察LeakCanary的报告后，我们就需要开始缩小观察范围来确定内存泄漏的原因。
在LeakCanary有这样一条规则，如果一个节点没有泄漏，那么指向它的任何先前引用都不是泄漏源，也不会泄漏。同样，如果一个节点泄漏，那么泄漏跟踪下的任何节点也会泄漏。由此，我们可以推断出内存泄漏原因出现在最后一次Leaking：NO和第一次Leaking：YES之间类中。
在本例中就对应下图的这四个部分，泄漏的原因往往就出这里面。在报告中用红色下波浪线标出来的部分，是LeakCanary认为导致内存泄漏的原因，也是我们接下来要重点排查的地方。
image
我们直接查看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中的内存泄漏、卡顿等问题，并定期发布相关的团队报告，让团队中其他人引以为戒。