越用越卡为哪般——如何降低App的待机内存

最新推荐文章于 2021-07-27 17:47:07 发布

会飞牛牛

最新推荐文章于 2021-07-27 17:47:07 发布

阅读量968

点赞数 1

分类专栏： Android性能专项测试

Android性能专项测试专栏收录该内容

14 篇文章 1 订阅

订阅专栏

导语

最近小优听说，隔壁的腾讯TMQ团队出了一本新书——《移动App性能评测与优化》，便借阅了一本来读，读完感觉写得确实很赞。这本书体系化地介绍了移动应用性能评测与优化的方方面面，如内存，电量，流畅度，导航，网络优化和安装包瘦身等，强烈推荐大家阅读~

小优从书中摘取了第一章 “越用越卡为哪般——如何降低App的待机内存” 的内容。本章介绍了各种内存使用情况分析的方法和一些优化技巧，让大家能够准确地了解应用内存的消耗情况，找出存在的内存问题，并在开发过程中尽量节约使用内存。本章共5节，本篇为第1节的入门内容，一起来看看吧！

正文

在智能手机兴起的这几年中，我们体验到了手机内存从256M到4G的巨大变化，进程可用的内存也从仅有16/32M到现在可以使用2G以上的内存。与此同时，应用的功能也日益复杂，也有跟多的进程在同时运行，需要协作和互相切换的应用越来越多。

在硬件资源增长后，应用开发者们会尽量使用这些资源来实现更多的功能和效果，因此我们面对着各种大量消耗内存的应用，依然会感觉到内存是稀缺资源。我们任然需要需要每个应用开发者了解内存的消耗情况，并尽量节约使用内存。

1.1 新手入门

当软件实现了新功能后，准备发布版本前，往往需要进行一轮性能测试以确定没有性能问题，这类测试通常包括功能的流畅度，电量消耗和内存使用情况等。

由于内存组成的复杂性，实际上并没有简单通用的方法就能够发现所有的内存问题。下面的章节里，我们会围绕一组案例展开，通过对案例的分析讲解各种内存测试的工具和方法。这些例子都是从真实的测试案例中提取的，经过加工后使得问题表现的更加明显。

接下来我们以一个最常见的内存泄漏开始，作为最典型的内存问题，类似的情况可能在无数应用的无数版本中出现过，而且还会不断的在新版本里出现。对于这样的问题，我们必须要准确识别出来。

在大部分应用中，经常会有一类功能是需要加载附加资源的，比如显示从网络下载的文本或图片。这类功能往往需要在内存中存放要使用的资源对象，退出该功能后，就需要将这些资源对象清空。如果忘了清理，或者是代码原因造成的清理无效，就会形成内存泄漏。我们的测试任务就是保证功能的正常，并且不会有遗留的内存对象造成泄漏。

要开始进行性能测试，测试工具是必不可少的。我们一般都会优先使用SDK/IDE自带的工具，因此首先会想到的工具就是和IDE集成在一起的Android Device Monitor/Android Studio了。

大多数情况下，功能代码都是由Dalvik虚拟机里执行的Java代码实现的，因此主要的内存消耗也是由Java代码使用new分配的内存。Android Device Monitor和Android Studio能够方便的观察Heap Alloc部分的大小，进行初步的统计，还能够观察到GC发生时的内存变化情况。

图1-1 使用DDMS观察应用的内存消耗

图1-2 使用Android Studio观察应用的内存消耗

在图1-1中，我们能够看到应用当前消耗了多少内存，以及各种不同类型对象的初步统计。在图1-2中，Android Studio更进一步的将内存数据进行了图形化，这样就能过方便地看出GC（垃圾回收）情况和明显的内存趋势。如果存在明显的内存泄漏，那么在图中就会表现为随着功能的反复使用，内存值不断的升高，即使出现GC也没法降下来，如图1-3所示。

图1-3典型的内存泄漏

发现了内存泄漏，通常就可以交给开发去处理了。但我们能做的并不只是丢一个问题描述和复现路径过去，而是利用手头的工具，获得一些更详细的数据，能够使大家更快的定位和解决问题。这样分析内存获得详细数据的首选工具就是Eclipse Memory Analyzer（MAT）了。

1.1.1 使用Eclipse Memory Analyzer（MAT）进行内存分析

Eclipse Memory Analyzer（MAT）是使用非常广泛的Java内存分析工具，功能强大。已经有很多关于它的详细教程，在本书中就不再细述用法。本节内容主要介绍使用MAT在分析Android应用时的一些常用技巧。

通常我们用MAT打开hprof文件后，能够在首页看到Top Consumers和Component Report等功能，使用这些功能能够快速定位一些大块的内存消耗。但对于Android应用的hprof文件，我们在使用了Top Consumers统计使用情况后，往往只能看到如图1-4所示的情况：

图1-4 使用MAT分析内存构成

系统的资源类占据了很大一部分的内存，而其余的前几名也往往是系统类。这是由于从虚拟机角度不会区分系统框架和应用自身的对象，后面的1.4.3节会详细说明出现这种现象的原因。

为了去除这部分对分析的干扰，我们在用Android SDK提供的hprof-conv转换时需要增加一个参数：

hprof-conv [-z] <infile><outfile>
-z: exclude non-app heaps, such as Zygote

另一种可替代的方法是使用OQL。如果hprof文件是已经转换过的，可以在数据中寻找应用的Application类对象，将对象地址转换为10进制后输入以下查询语句：

select * from instanceof java.lang.Object s where s.@objectAddress > 1107296256

使用-z参数转换或OQL查询后得到的对象集合就只包含应用代码分配的部分了。在此基础上使用MAT提供的Top Consumers和Component Report等功能就能够得到比较准确的结果。如图1-5所示，没有了系统类所占内存的干扰，只有应用自身代码创建的对象，对于发现内存问题比较有帮助。

图1-5分离之后再次分析内存构成

对于一般的内存泄露类问题，使用以上方法后通过MAT提供的分析报告就很容易就会识别出来。在我们以往的测试经历中，用这种方法发现了上百次的内存问题。这些内存往往是加载后忘了释放的Bitmap，临时生成的byte数组和文件缓冲区，包含Handler的Activity等等。

接下来我们看一个真实的应用测试案例。在这个案例里，有些位图在使用完之后由于种种原因，一直没有销毁而存在ImageLoader里，使用一段时间后ImageLoader会变得越来越庞大。使用上面介绍的方法去除了系统的影响后，MAT的泄露报告给出了结果，如图1-6所示，ImageLoader消耗了接近1/3的内存。

图1-6 MAT识别出来的问题

有了这样的数据，接下来就可以结合图片追踪代码，看引用到ImageLoader的代码部分哪里有问题，从而快速的修复问题。

下周我们将继续带来后续章节内容——“规范测试流程及常见问题”

腾讯TMQ出品的《移动App性能评测与优化》在各大渠道均已上架。

小优也帮大家争取到了优测用户专享福利

现在点击“阅读原文”即可享受7折的优惠价格！

仅限150本！

腾讯优测

腾讯优测是专业的移动云测试平台，为应用、游戏、H5混合应用的研发团队提供产品质量检测与问题解决服务。不仅在线上平台提供app自动化测试、云真机远程操控与调试、私有自动化测试工具XTest等多种质量检测工具，更为VIP客户配备了专家团队提供定制化综合测试解决方案。

导语

最近小优听说，隔壁的腾讯TMQ团队出了一本新书——《移动App性能评测与优化》，便借阅了一本，读完感觉写得确实很赞。这本书体系化地介绍了移动应用性能评测与优化的方方面面，如内存，电量，流畅度，导航，网络优化和安装包瘦身等，强烈推荐大家阅读~

小优从书中摘取了第一章 “越用越卡为哪般——如何降低App的待机内存” 的内容。本章介绍了各种内存使用情况分析的方法和一些优化技巧，让大家能够准确地了解应用内存的消耗情况，找出存在的内存问题，并在开发过程中尽量节约使用内存。

本章共5节，上周给大家推送了第1节“内存测试新手入门”的内容，本周我们继续讲解“规范测试流程及常见问题”，一起来看看吧！

1.2规范测试流程及常见问题

最开始进行内存测试时，我们可能还有些摸不着头脑，试着找了些工具，看了看教程就开始动手了。有时候因为问题比较明显，就真的发现了问题。再之后遇到类似的测试需求，我们就会按上次的经验去做。有时候可能发现问题，也可能发现不了，还有些时候发现是甚至是在白费功夫。因为随着明显的问题逐渐被找出来，剩下的有都是更加复杂而不太明显的问题，甚至有些更是可以归属到优化范畴或者产品策略之内，而不再是简单的内存问题。

随着经验的逐渐增加，我们逐渐意识到，以前的很多测试方法都是随机乱测。对于较为成熟的软件，这类方法的测试有效性往往比较低，运气好了才会遇到问题。如果是较深层次的问题要么遇不到，要么遇到了也找不出原因。因此，有必要总结出一套成熟的流程方法，能够考虑到各个方面，提高测试的有效性。

1.2.1测试流程

由于内存测试属于性能测试，Android系统又和Linux有很多相通之处。因此我们可以参考常见的Linux性能测试方法和指标，来制定客户端性能测试方案。常见的测试方法包括Monkey/UIAutomator类的常规压力测试，大数据/操作的峰值压力测试，长时间运行的稳定性测试等。这些方法都可以叠加在内存测试的方案中，观察这类场景下的应用内存情况，经常能够发现类似内存泄漏或OOM的问题。

参考了常见性能测试的方案，以及总结了以往对内存性能测试的经验后，我们总结出了一套进行内存测试的经验流程，供读者在制定测试计划时参考。

1.代码

通常用来进行内存测试的版本是纯净版本，不应该附加多余的Log和调试用组件。例如有些情况下，为了测试界面延迟/函数执行时间等性能，会加入一些桩点代码。在内存测试中这些代码是不必要的，它们可能会分配临时内存，引起更多的GC，导致应用出现运行缓慢、卡顿等现象。

2.测试场景(来自于经验&开发)

测试场景通常有两类，一类是当前有新开发或改动的某项功能，需要对该功能进行性能测试。因此测试场景主要针对该功能组织，包括功能的开启前，运行，结束后等测试点。

另一类是整体性能，考察应用的常见场景，在综合使用情况下的性能指标。测试场景应当包括启动后待机，切换到后台，执行主要功能，以及反复执行各功能后。

在各类场景中，经常做为测试重点的有：

包含了图片显示的界面
网络传输大量数据
需要缓存数据的场景

3.场景转换成用例

选取了测试场景后，用例设计也要考虑内存测试的特点。一些常见的方法是：

结合场景比较操作前后或不同版本的内存变化
显示多张图片的前台进程
多个场景来回切换
长时间运行进程的内存增长

4.执行

由于GC和广播机制的存在，应用内存通常都在不停得波动，幅度可能会达到几百K，因此执行时需要考虑这种情况。在采集数据时，需要多次采集并计算平均值。

执行完成中，我们就可以根据数据进行比较初步的分析以确定方向。一方面是我们熟悉的Dalvik Heap部分，既由Java代码直接分配的内存，可以通过IDE直接观察到使用情况，也可以使用MAT进行细致的分析。

另一方面，假如我们发现Dalvik Heap没怎么增长，而其他部分增长了许多，这种情况下的分析就要复杂一些，我们留待后面的章节再说。

1.2.2 Dalvik Heap的常见问题

随着测试的执行，随之而来的就是一大堆产生的数据，对产生的数据进行分析，找出可能存在的问题，以及问题可能的原因是接下来的重点。

由于大部分Android应用是Java代码开发的，所以Dalvik Heap内存出现问题也是最常见的情况。常见的现象有以下几种：

随着功能的反复执行，Heap内存一直在持续增长。这种情况通常是出现了内存泄露，这种情况最适合用LeakCanary等泄露检查工具进行白盒测试分析。
代码执行时出现了频繁的GC，Heap Alloc内存大幅度波动。这种情况通常是分配了许多临时变量或数组，随后又被迅速回收，这种情况在确定具体场景后适合使用Heap Viewer / Allocation Tracker等工具来查看具体分配的对象。
每次启动应用后，Heap内存相比以前版本稳定增长。这种情况通常出现在启动后待机或使用某功能后，可能是由新功能及代码改动引入的固定内存增长。这种情况适合获取Heap Dump后进行多版本或功能使用前后的对此，能够迅速找到增长原因。
Heap Alloc变化不大，但进程的Dalvik Heap PSS内存明显增加。这种情况比较少见，是由于分配了大量小对象造成的内存碎片，在后面的章节里会详细讲解，具体内容请见下一节。