【腾讯优测干货分享】越用越卡为哪般——如何降低App的待机内存(一)
本文来自于腾讯优测公众号(wxutest),未经作者同意,请勿转载,原文地址:http://mp.weixin.qq.com/s/1_FKMbi1enpcKMqto-o_FQ
作者:腾讯TMQ专项测试团队
导语
最近小优听说,隔壁的腾讯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的代码部分哪里有问题,从而快速的修复问题。
下周我们将带来规范测试流程及常见问题
更多精彩内容欢迎关注腾讯优测的微信公众账号:
腾讯优测是专业的移动云测试平台,为应用、游戏、H5混合应用的研发团队提供产品质量检测与问题解决服务。不仅在线上平台提供app自动化测试、云真机远程操控与调试、私有自动化测试工具XTest等多种质量检测工具,更为VIP客户配备了专家团队提供定制化综合测试解决方案。