1.1　新手入门

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

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

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

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

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

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

 

图1-1　使用Android Device Monitor观察应用的内存消耗

 

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

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

 

图1-3　典型的内存泄漏

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

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类对象，将对象地址转换为十进制后输入以下查询语句：

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的内存。

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

 

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