前言

通过这几天对好几个应用的内存泄露检测和改善，效果明显：

• 完全退出应用时，手动触发 GC，从原来占有内存 100 多 M 降到低于 20M；
• 手动触发 GC 后，通过 adb shell dumpsys meminfo packagename -d 查看 Activity 和 View 的数量也趋近于 0 了（没有做到归零是因为 SDK 中存在内存泄露，需要中间层去处理）；
• 发现了一个 SDK 中的内存泄露（Android InputMethodManager 导致的内存泄露及解决方案）；
• 发现一个 MTK Webview 的内存泄露 (org.chromium.android_webview.AwPasswordHandler.java 中 private static AwPasswordHandler sInstance = null 导致的内存泄露)。
  

从结果来看分析和改善内存泄露的方法是对的，这个过程并不复杂，所以可以梳理总结出来作为分享。

原则

对于性能问题，分析和改善有必要遵循以下原则：

• 一切看数据说话，不能跟着感觉走，感觉哪有问题就去改，很有可能会适得其反；
• 性能优化是一个持续的过程，需要不断地改善，不要想着一气呵成；
• 对于性能问题，不一定必须要改善，受限于架构或者其它原因某些问题可能会很难改善，必须要先保证能用，再才考虑好用。
• 改善后一定要验证，任何一个地方的改动都需要验证，避免因为改善性能问题导致其它的问题。
  

步骤

下面是我在针对内存泄露这个性能问题的解决步骤：

优先处理常见的内存泄露问题

首先解决常见的内存泄露问题，这个过程可以借助 Android Studio 的 Analyz

-Inspect Code 对代码做静态分析，常见的内存泄露问题有：

• 非静态内部类导致的内存泄露，比如 Handler，解决方法是将内部类写成静态内部类，在静态内部类中使用软引用/弱引用持有外部类的实例，eg：
• IO 操作后，没有关闭文件导致的内存泄露，比如 Cursor、FileInputStream、FileOutputStream 使用完后没有关闭，这种问题在 Android Studio 2.0 中能够通过静态代码分析检查出来，直接改善就可以了；
• 自定义 View 中使用 TypedArray 后，没有 recycle，这种问题也可以在 Android Studio 2.0 中能够通过静态代码分析检查出来，直接改善就可以了；
• 某些地方使用了四大组件的 context，在离开这些组件后仍然持有其 context 导致的内存泄露，这种问题属于共识，在编写代码的过程中就应该按照规则来，使用 Application 的 Context 就可以解决这类内存泄露的问题了，至于什么情况下应该使用四大组件的 Context，什么时候应该使用 Application 的 context 可以参见下表：
  

application 使用场景

备注：大家注意看到有一些 NO 上添加了一些数字，其实这些从能力上来说是 YES，但是为什么说是 NO 呢？下面一个一个解释：

• 还有一种不属于内存泄露，但在分析内存泄露的问题时应该一并解决：同一个 APP，将图片放在不同的 drawable 文件夹下，在相同的设备上占用的内存情况不一样，具体可以参见：关于 Android 中图片大小、内存占用与 drawable 文件夹关系的研究与分析。解决这个问题遵循以下原则就可以了： 　　 1、UI 只提供一套高分辨率的图，图片建议放在 drawable-xxhdpi 文件夹下（放在 xxxhdpi 或者更高分辨率的文件夹下没有必要，权衡利弊，照顾主流设备即可），这样在低分辨率设备中图片的大小只是压缩，不会存在内存增大的情况； 　　 2、涉及到桌面插件或者不需要缩放的图片，放在 drawable-nodpi 文件夹下，这个文件夹下的图片在任何设备上都是不会缩放的。
  

通过工具检查程序运行后的内存泄露

通过上面的步骤，应用中的大部分内存泄露问题都能够得到解决，还有一些内存泄露，需要运行程序，分析运行后的内存快照来解决，比如注册之后没有反注册、类中的静态成员变量导致的内存泄露、SDK 中的内存泄露等。解决这类问题可以分两步进行：

通过内存泄露检测工具先定位是哪有问题，内存泄露的检测有两种比较便捷的方式：

1、一种是使用开源项目 Leakcanary，需要添加到代码中，运行后生成分析结果；

2、另一种方式是使用 adb shell dumpsys meminfo packagename -d 命令，在进入一个界面之前查看一遍 Activity 和 View 的数量，在退出这个界面之后再查看一遍 Activity 和 View 的数量，对比进入前和进入后 Activity 和 View 数量的变化情况，如果有差异，则说明存在内存泄露（在使用命令查看 Activity 和 View 的数量之前，记得手动触发 GC）。

备注：在 Android Studio 中，可以通过如下方式获取当前选中进程的内存信息：

• 然后通过 MAT 取程序运行时的内存快照做详细分析，对于 MAT 的使用，网上有很多优质的文章，比如：Android 性能优化之使用 MAT 分析内存泄露问题，在使用 MAT 前，有必要知道这几点：
  

1、 不要指望 MAT 明确告诉你哪里存在内存泄露，这需要你根据上一步骤首先定位到可能存在内存泄露的类，然后借助 MAT 确认是否真的存在内存泄露，具体哪个地方存在内存泄露；

2、借助 Retained Size 分析某一个类及与之相关的实例所消耗的内存，如果这个类的 Retained Size 比较大，优先分析；

3、检查某个类是否存在内存泄露时，排除其软/弱/虚引用，右键某个类→Merge Shortest Paths to GC Roots→exclude all phantom/weak/soft etc.references。

验证改善效果

根据个人经验，我一般是这样验证改善效果的，运行程序，各个功能跑一遍，确保没有改出问题，完全退出程序，手动触发 GC，然后通过 adb shell dumpsys meminfo packagename -d 查看 Activivites 和 Views 的数量是否趋近于 0；如果不是 0，通过 Leakcanary 检查可能存在内存泄露的地方，继续通过 MAT 分析，周而复始，改善到自己满意为止。　　

 阿里云测移动质量中心（以下简称 MQC）是为广大企业客户和移动开发者提供真机测试服务的云平台，拥有大量热门机型，提供 7x24 全天候服务。       

我们致力于提供专业、稳定、全面、高价值的自动化测试能力，以及简单易用的使用流程、贴心的技术服务，并且帮助客户以最低的成本、最高的效率发现 APP 中的各类隐患（APP 崩溃、各类兼容性问题、功能性问题、性能问题等），减少用户流失，提高 APP 质量和市场竞争力。

联系我们：
 网站地址：https://mqc.aliyun.com
 开发者交流旺旺群：335334143
 开发者交流 QQ 群：492028798
 客服邮箱：mqc_group@service.alibaba.com；
更多精彩技术分享 欢迎关注 MQC 公众号