App的待机内存增长的原因是什么
这篇文章给大家介绍App的待机内存增长的原因是什么,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
成都创新互联是一家专业提供淳安企业网站建设,专注与成都网站制作、成都网站建设、H5场景定制、小程序制作等业务。10年已为淳安众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。
1.新问题的进一步挖掘
在上一节里,我们介绍了内存测试的基本流程,讲述了如何发现并处理简单的内存问题。对于Dalvik Heap部分总结出了一些常见的问题模式,以及如何使用工具识别和处理这些常见的内存问题。
当简单问题不再是问题的时候,我们就会开始遇上一些奇怪问题了,类似于下面这些:
“我们这个版本引入了一个挺简单的库,内存就涨了2M” “这些代码只是初始化了几个对象,还没有开始用呢” “我只是改了一行代码,没有创建新对象” “我一行代码都没改,怎么会涨呢”
这次出现的问题就是这样这一类问题,新版本的Dalvik Heap Pss内存出现了2M左右的增长。但Dalvik Heap Alloc只增长了273K的情况下。而从Dalvik Heap Free也能看出大部分增长的内存是空闲状态的。
经过一段时间对问题的观察,我们有以下几点发现:
经过较长时间待机后也没有被释放回系统。
有几处代码会导致内存增长,只要将这些代码屏蔽掉,内存情况就下降到正常水品。
这些代码分配的内存并不多,甚至有些地方是不需要分配内存的。
有些代码并不是这个版本新加入的,已经存在较长时间了。
使用裁剪功能的方法编译并分析内存后,基本可以确定是新加入代码消耗了内存,但并没有内存泄漏,代码经过review也没有发现问题。
这个结果让我们陷入了困惑,常用的方法找不出问题,说明有更深层次的原因。接下来要从更底层的Dalvik虚拟机寻找问题。
1.1 Dalvik Heap内部机制
为了弄清楚为什么DVM占着内存不释放,我们阅读了DVM分配内存部分的代码。位置在Android源码的dalvik/vm/alloc下,约255K。分析出的主要流程如下:
1)DVM使用mmap系统调用从系统分配大块内存作为Java Heap。根据系统机制,如果分类的内存尚未真正使用,就不计入PrivateDirty和PSS。例如图1-8,Heap Size/Alloc很多,但大部分是共享,实际使用的较少。所以反映到PrivateDirty/PSS里的内存并不多。
图1-8 共享内存较多的进程
2)New对象之后,由于要向对应的地址写入数据,内核开始真正分配该地址对应的4K物理内存页面。
Alloc.cpp, 176行起:
3)运行一段时间后,开始GC,有些对象被回收了,有些会一直存在。
4)在GC时,有可能会进行trim。即将空闲的物理页面释放回系统,表现为PrivateDirty/PSS下降。
HeapSource.cpp, 431行:
1.2 问题所在
在了解DVM分配释放内存的机制后,根据dumpsys观察到的现象,猜测可能出现了页利用率问题(页内碎片)。如图1-13所示,第一行:在开始阶段,内存分配的较满。第二行:经过GC后,大部分对象被释放,少部分留下来。
这种情况下可能会产生的问题是,整页的4K内存中可能只有一个小对象,但统计PrivateDirty/PSS时还是按4K计算。
在通常的jvm虚拟机中,有Compacting GC机制,整理内存对象,将散布的内存移动到一起。但根据DVM的代码,DVM的Mark-Sweep算法不能移动对象,即没有内存整理功能,这种情况下就会形成内存空洞。
在猜测了可能的问题后,需要验证是否如猜测原因所致,由于MAT的对象实例数据中有地址和大小信息,我们先从MAT中导出数据。
在MAT中列出所有对象实例:list_objects java.*,然后选中所有数据导出为CSV格式,如下所示:
Class Name,Shallow Heap,Retained Heap, class java.lang.Class @ 0x41fdd1e8,16,56, class test.bxi$3 @ 0x432501c8,0,0, class test.aaw$c$1 @ 0x4324fef8,0,0, class test.ds @ 0x4324fc88,8,48, class test.bxh @ 0x4324f438,8,248, class test.bxg @ 0x4324f248,0,0, class test.bxd$1 @ 0x4324f028,0,0,
处理导出的csv文件,按页面进行统计,取每个对象的地址的高位(&0xfffff000),结果相同的对象处在同一页面中。最后再按每个页面所有对象的大小分类统计,做出直方图如图1-14所示。
这张图就是被测应用的页面利用率分布图,左边是利用率低的页面,右边是利用率高的页面。如果发现利用率低的页面数目增加,说明小对象碎片的数量增加了。
1.3 优化Dalvik内存碎片
为了能够找出有问题的代码,我们将上一步得到的数据继续处理。取出所有使用不满2K的页面的内存块地址,再使用OQL将地址导入到MAT中,分析地址对应的对象是什么。如图1-15所示就是将地址重新导入到MAT中得到的对象列表了:
在这里基本就能看出来是哪些对象造成了内存的碎片化,数量比较多的前几个类的自然嫌疑比较大,可以先对前几个类的相关代码进行分析。也可以对这些代码进行针对性的内存测试,观察内存情况。
通过对生成这些对象的代码分析和模拟实验,我们还原出问题的基本过程:
生成对象过程需要较多的临时变量。
批量生成过程中,由于还有空闲内存,虚拟机没有做GC。
完成后才进行GC,清除了所有的零时变量,留下碎片化的内存。
下图是造成这个问题的类似代码,执行这段代码将会在内存中形成很多碎片,造成很高的PSS占用。
private Object result[] = new Object[100]; void foo() { for(int i = 0; i < 100; ++i) { byte[] tmp = new byte[2000]; result[i] = new byte[4]; } }
显示了类似情况下数组的分配范围,可见数组中每个成员的内存地址都是不连续的,并且相隔很远。这种情况下就会消耗很多个物理内存页面,增加Heap Free,造成例子中的问题。
根据上述的流程,我们搞清楚了造成问题的原因,并且找到了问题代码。那么应当总结一些经验,以供借鉴。对于测试人员来说,有以下两个经验:
MAT是探索Java堆并发现问题的好帮手,能够迅速发现常见的图片和大数组等问题。但仅靠MAT提供的功能也不是万能的,比如这个问题的数据就隐藏在对象的地址中。
对Android测试经验来说,可能容易找到的是应用代码及框架的各种测试经验和指导,底层以及涉及性能的测试经验并不太多。这方面可以借鉴Linux系统的测试经验,了解内核及进程相关的知识,熟悉常用工具。
内存分配的最小单位是页面,通常为4K。
对于开发人员,以下两个经验也许能有帮助:
尽量不要在循环中创建很多临时变量。
可以将大型的循环拆散,分段或者按需执行。
关于App的待机内存增长的原因是什么就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
分享题目:App的待机内存增长的原因是什么
文章来源:http://scyanting.com/article/gegcoc.html