06 性能优化-内存优化-工具和方法

1 内存优化工具

1.1 工具集

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

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

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

1.2、Memory Profiler

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

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

image

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

image

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

image

4.Memory Profiler界面总览

image

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

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

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

1.3、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）

image

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

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

image

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

image

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

image

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

image image

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

image

1.Histogram

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

image

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

image

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

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

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

2.Dominator Tree

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

image

3.Top Consumers

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

image

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

4.Leak Suspects

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

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

image

5.OQL

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

image

6.thread_overview

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

image

7.unreachable Objects Histogram

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

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

1.4、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中。

image

排查内存泄漏

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

image

泄漏跟踪中的每个节点都是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/

1.5、实际应用场景

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

小团队

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

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

中等规模团队

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

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

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

2 Android常用的内存优化方法

在Android中内存优化的方式实在是太多了，往细了说，到你写的每一行代码其实都和内存优化相关。在这里我从三个方面来说下Android内存优化的方法：

1. 降低运行时内存
2. 代码优化
3. 内存泄漏优化

在实际开发中我们可以先考虑降低应用的运行时内存，然后针对代码写的不好的地方着重优化，最后通过规避一些可能导致内存泄漏的编码方式，去提前避免内存泄漏的问题。

2.1、降低运行时内存

image

降低运行时内存可以分为减小APK的体积和Bitmap优化两部分：

• 减小APK体积

1. 去除无用的资源和代码，通过合理使用git，一些由于业务变更而基本不会用到的代码，该删除的绝不能手软。即使以后要用到，通过git也能找回。同时一些图片资源未用到的也应该删除，因为即使gradle配了sharkresource选项，发布的时候这些没有用到的图片依然会被打包到你的apk。
2. 尽量复用资源，其实这是一种比较好的编码习惯。
3. 对应用的启动图引导页图片进行压缩，往往这些图片占据了大部分空间，压缩后可以起到很好的效果。平时开发中对于分辨率大雨100*100的图片基本上都会进行压缩，很多好的压缩算法经常可以减少一半的大小，而感官上基本看不出有任何改变。

• Bitmap优化

1. 统一的bitmap加载器，选择Glide、Fresco、Picasso中的一个作为图片加载框架。实际开发中加载到view的图片的大小不应该超过view的大小，图片加载框架默认会对图片进行缓存，按view实际大小加载。在开发中为了减少apk的大小，一般只放一套3X图片，但是这些图片在小分辨率的手机上直接加载就会出现内存浪费。统一的bitmap加载器就可以很好的解决该问题。
2. 图片存在像素浪费，对于.9图，美工可能在出图时在拉伸与非拉伸区域都有大量的像素重复。而这些图片是可以缩小，但并不影响显示效果。
3. inSampleSize:缩放比例，在把图片载入内存之前，我们需要计算一个合适的缩放比例，避免不必要的大图载入。
4. 选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。
5. inBitmap：这个参数用来实现Bitmap内存的复用，但复用存在一些限制，具体体现在：在Android 4.4之前只能重用相同大小的Bitmap的内存，而Android 4.4及以后版本则只要后来的Bitmap比之前的小即可。使用inBitmap参数前，每创建一个Bitmap对象都会分配一块内存供其使用，而使用了inBitmap参数后，多个Bitmap可以复用一块内存，这样可以提高性能。

参考：

Android 官网文档Managing Bitmap Memory、Handling bitmaps

2.2、代码优化

这里介绍一些好的编码习惯：

image

1. 考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构，Android系统为移动系统设计的容器ArrayMap更加高效，占用内存更少，因为HashMap需要一个额外的实例对象来记录Mapping的操作。而SparesArray高效的避免了key和value的自动装箱，而且避免了装箱后的解箱。详细参考Android性能优化典范

2. 在onDraw这种频繁调用的方法要避免对象的创建操作，因为他会迅速增加内存的使用，引起频繁的gc，甚至内存抖动。

3. SoftReference(软引用)、WeakReference(弱引用)、PhantomReference(虚引用)

   SoftReference：如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。

   WeakReference：与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

   PhantomReference：虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。

4. 谨慎使用large heap，android设备由于软硬件的差异，heap阀值不同，特殊情况下可以在manifest中使用largeheap=true声明一个更大的heap空间，使用getLargeMemoryClass()来获取到这个更大的空间。但是要谨慎使用，因为额外的空间会影响到系统整体的用户体验，切换任务时性能大打折扣，对于oom异常是治标不治本的一种做法。

5. 谨慎使用多进程，使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术，一个典型的例子是创建一个可以长时间后台播放的Music Player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作UI，另外一个给后台的Service。

6. 考虑第三方库的大小，如果会和现有的代码或其他库的代码重复，考虑不要真个引入而是把库的代码精简之后再引入。

2.3、内存泄漏优化

内存泄漏的原因有很多，下面介绍一些常见的，我们需要在开发中多注意：

image

1. Activity调用了finish，但是引用Activity的对象未被释放(生命周期没有结束)，Activity Context被传递到其他实例中，可能导致自身被引用而发生泄露，建议使用weakReferce。

2. 除必须使用Activity Context的情况(Dialog的context必须是Activity),我们可以使用Application Context来避免Activity泄露。

3. 大多数情况下，我们对Bitmap对象增加缓存机制，但是有时候部分bitmap需要及时回收。比如我们临时创建的摸个相对大的bitmap对象，变换得到新的bitmap对象后，尽快回收原始的bitmap，及时释放原来的空间。

4. webview引起的内存泄漏主要是因为org.chromium.android_webview.AwContents 类中注册了component callbacks，但是未正常反注册而导致的。让onDetachedFromWindow先走，在主动调用destroy()之前，把webview从它的parent上面移除掉(Basewebfragment onDestroy())

5. 虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。

6. 我们在对数据库进行操作时，使用完cursor没有及时关闭，cursor的泄露，会对内存管理带来负面影响。

7. 谨慎使用static对象，因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏。

总结：在实际的线上环境中发现，大部分内存泄漏是因为被调用的对象生命周期不同步导致，生命周期不同步不仅仅会导致内存泄漏，更会出现异常，崩溃等更严重的问题。

2.4 做好上面说的1、2、3就够了吗？

image

上篇文章我们已经从系统级别了解了Android Framework、Darlvik/Art虚拟机、Linux在内存分配上的原理，接着又在代码级别分别从减少内存占用、避免内存泄漏和代码优化三个方面介绍了如何避免内存问题，再加上当前科技发展是如此迅速，4GB内存已经是很常见的手机配置。LPDDR4X的高速闪存也越来越被广泛的使用。对于内存优化我们是不是就已经可以高枕无忧了，有上面这些就够了吗？

我想即使我们再了解内存，写的代码再好，用户的手机再先进，总还是有出错的时候，那么事后的内存分析和监控是必不可少的了！下一篇文章我们就来谈一谈内存分析和监控。

3 优化实践

3.1、关闭无用的Service

《饭fan》是一个单Activity多Fragment的APP，在App的入口Activity同时启动了两个Service，TinkerService用于检查热修复补丁，UpdateService用于检查是否有更新。

在操作APP一段时间后，使用Memory Profiler检查内存，得到下图

image

可以看到内存中依然存在TinkerService和UpdateService。没有特殊指定的service是运行在主线程中的，这些已经无用的Service会拖慢主线程并占据主进程的可用内存。

解决方案

• 调用stopService或stopSelf关闭这些service

关闭service后再次使用Memory Profiler检查内存，可以看到，APP占用的总内存已经减少了

image

3.2、多进程WebView的优化

从1.0.3版开始《饭fan》中集成了一个简单的商城系统，商城系统的制作参考了
慕课网的一个课程—《混合开发入门 主流开发方案实战京东移动端APP》。

商城系统集成完毕后，调试过程中，LeakCanary提示，ShoppingActivity发生了内存泄漏，如下图所示

image

WebView应该是Android中最容易发生内存泄漏的系统组件，往往都是Activity退出时，WebView依然持有activity的引用，导致Activity发生泄漏。 网络上有很多如何防止WebView产生泄漏，但是效果都不好，有的甚至根本没有效果。

解决方案

• 让持有webview的Activity独立运行在一个进程，在activity的onDestroy中关闭这个进程

让Activity独立运行在一个进程中，可以彻底清除掉webview以及Activity
，但是让持有webview的Activity独立在一个进程中，会产生另一个问题——长时间的白屏。
webview本身初始化以及载入Html页面都需要一定的时间，这段时间会产白屏。
如果在启动Activity时需要额外再创建一个进程，那么白屏的时间就会进一步拉长，有时甚至长达4-5秒。

《饭fan》中针对长时间这个问题，又做了进一步优化。

• 1.在app启动时，同时启动一个ShoppingService。ShoppingService运行在与WebViewActivity相同的进程中，退出WebViewActivity后当前进程会被关闭，在适当时候再重启ShoppingService。
• 2.引入腾讯的x5WebView和VasSonic，加快webview初始化速度，同时也提高了WebView在各个系统上兼容性。
• 3.在webview初始化的同时，使用APP内网络框架来请求Html页面中所需的数据。通过并行的方式，节省webview的加载数据的时间。

优化步骤大致就是以上这些，具体实现的代码请参考《饭fan》中Component_shopping组件。

3.3、Bitmap造成的内存泄漏

在Android内存优化中有“一图毁十优”的说法，一般普通的内存泄漏浪费的内存都在几十KB到几MB之间，但是一个bitmap泄漏就有可能浪费几十MB的内存空间，所以bitmap的优化一直是Android内存优化的重中之重。所以我们接下来的就重点介绍Bitmap的优化方案。

• 1.使用RGB_565解码图片

在开发中大多数的图片加载框架的默认解码方案是ARGB_8888，这种解码方案，每个像素占4个字节，其实还有一种图片解码方案是RGB_565,这种解码方案，每个像素占2个字节，但是在视觉效果上与ARGB_8888差距并不明显。

所以一些页面的缩略图、背景图片以及一些用户感官上认为它就是缩略图的地方可以使用RGB_565来解码，在减小内存占用上，有立竿见影的效果，强烈推荐使用。

• 2.不要乱放图片

在开发中我们往往会要求美工一张图标切3到5套不同尺寸的，然后分别放置在res下不同的资源目录里面

目录	对应的dpi
res/drawable	0
res/mipmap-lidp	120
res/mipmap-mdpi	160
res/mipmap-hdpi	240
res/mipmap-xhdpi	320
res/mipmap-xxhdpi	480
res/mipmap-xxxhdpi	640

Android有一套特殊的适配策略，对放在mipmap目录的图标会忽略屏幕密度，会去尽量匹配大一点的，然后系统自动对图片进行缩放，从而优化显示和节省资源。图片的缩放比率=手机的dpi / mipmap目录的dpi。

放在drawable目录下的会根据ROM的不同得到一个默认的dpi，但是这个dpi并一定是手机屏幕的实际dpi。

例如：如果我们将一张500X500的图标仅放在ldpi（120）下，那么在在480dpi的手机上实际的显示尺寸是2000X2000。

当我们分不清图标应该放在哪个目录下时，应该尽量将高品质的图片放在高密度目录下，这样能控制图片的缩放比率小于1，保证画质的前提，内存也是可控的。

• 3.控制那些不可控的图片

这是什么意思呢，举一个我曾经实际遇到的例子，我们的APP有一个课件的功能，允许教师上传课件，服务器会把这些课件转成图片返回给APP显示，有个老师上传了一篇PDF格式的论文，服务器转换后每个图片足足有4000X8000这么大，加载每张图片需要消耗内存4000X8000X4/1024/1204=122MB，直接导致了OOM。

在这个例子中教师上传的课件转换后的图片就属于不可控图片，如果服务器不做过滤，那么APP就需要对这些用户上传的图片特殊处理。

处理步骤如下：

• 从服务器下载的图片获取它的高度和宽度
• 对于高度或宽度大于手机屏幕尺寸的图片计算缩放比率，并做缩放解码
• 要对所有的图片解码API（decodexxxx）做OutOfMemoryError的异常处理

具体的代码请参考BitmapUtils。