关闭

【腾讯优测干货分享】如何降低App的待机内存(四)——进阶:内存原理

标签: 内存原理内存优化
453人阅读 评论(0) 收藏 举报

本文来自于腾讯优测公众号(wxutest),未经作者同意,请勿转载,原文地址:http://mp.weixin.qq.com/s/3FTPFvZRqyAQnU047kmWJQ

1.4进阶:内存原理

在上一节里,我们通过深入调查Dalvik虚拟机的方式,解决了Dalvik Heap Pss消耗内存过高的问题。除了Dalvik Heap Pss部分,应用还有其他许多消耗内存的部分。本节里我们就主要介绍其他这些部分的内存是如何被分配和消耗的。

同样以我们的应用为例,在几个版本之后,新加入了一个缓存功能。缓存功能会预先取一些手机的信息,并放在内存中供其他功能使用,这样可以减少后续功能的消耗,加快运行速度。

有了之前的经验,我们自然会想到不能简单粗暴的将所有缓存一次生成,这样可能会产生大量的碎片,因此需要选择一种合适的策略来进行。在选择新功能的缓存策略时,内存测试也同样有用,通过对不同策略的测试,决定那种策略比较有效,并且消耗内存比较少。

在测试过程中我们发现,随着使用不同的策略,Dalvik Heap部分会随之增减。与此同时,不同策略执行代码的时机也会使dalvik other和dex mmap的内存消耗变化。总结规律如下:
- 不生成缓存时,Dalvik Other和mmap会随之下降。
- 按需生成缓存时,即使只生成一条记录,Dalvik Other和mmap会增加。
- 生成多条缓存记录时,Dalvik Other和mmap会在开始增加,然后一直保持不变。
- Dalvik Other不会下降,mmap偶尔会下降。

通常我们只是大致了解到,Dalvik Other和mmap和代码数量相关,越复杂的应用这部分内存就越多,并没有进行过定量的分析。但现在随着对Dalvik Heap部分的优化,我们发现Dalvik Other和mmap在内存中的比重越来越大。在这个版本里,占总内存的将近一半,不能再置之不理,而是要寻找办法对这部分内存进行优化。

对于这些不熟悉的部分,我们也首先要先去了解背后的原理,才能够针对性的去研究这些内存是如何被消耗的。

1.4.1 从物理内存到应用

我们首先要了解系统的内存机制,搞清楚物理内存是如何被分配到各个进程的,以及共享内存的机制等等。理解内存机制对测试及优化都有很大帮助。

图1-14 Android架构

根据Google提供的Android整体架构图,如图1-14所示,可以看到Android系统是基于Linux内核的,因此底层的内存分配及共享机制与Linux基本相同。但由于Android是为移动设备设计的,所以整套架构为了符合移动设备的特性,需要有较低的内存及能耗需求。因此Android只使用了Linux内核,不使用传统Linux系统的组件。这些组件虽然功能强大,但是较为消耗系统资源。Google开发了若干较小的组件,例如将庞大的glibc换为bionic库,使用sqlite数据库等。Android还扩充了许多内核机制和实现,其中对内存影响较大的是Ashmem和Binder机制。

在Ashmem及COW(Copy-On-Write)机制的基础上,Android进程最明显的内存特征是与zygote共享内存。为了加快启动速度及节约内存,Android应用的进程都是由zygote fork出来的。由于zygote已经载入了完整的Dalvik虚拟机和Android 应用框架的代码,fork出的进程和zygote共享同一块内存这样就节约了每个进程单独载入的时间和内存。应用进程只需要载入自己的dalvik字节码及资源就可以开始工作。

综上所述,一个在运行的Android应用进程会包含以下几个部分:

  • 共享内存:Dalvik虚拟机代码
  • 共享内存:应用框架的代码
  • 共享内存:应用框架的资源
  • 共享内存:应用框架的so库
  • 私有内存:应用的代码
  • 私有内存:应用的资源
  • 私有内存:应用的so库
  • 共享/私有:堆内存,其它部分

有了整体视角后,我们再开始深入,观察某一个应用的内存情况。在之前的测试中,我们使用系统提供的dumpsys meminfo工具来观察内存值。它能够将不同的内存消耗分类统计,输出成便于查看的格式。

但如果我们想细致的研究各部分内存的由来,只靠这个工具是不够的,但我们有必要按照系统划分各部分的方式来理解和分析内存。

通过阅读和分析dumpsys meminfo的代码,我们能够了解到Android是如何划分各部分内存的。下面我们详细讲解dumpsys meminfo工具是如何统计各部分内存值的。

1.4.2 smaps

由于Android底层基于是Linux内核,进程内存信息也和linux一致,所以Dalvik Heap之外的信息都能够从/proc//smaps中取得。

在smaps中,列出了进程的各个内存区域,并根据分配的不同用途做标识,以下是root用户使用cat /proc//smaps的一个例子:

dumpsys统计各个内存块的Pss,SharedDirty,PrivateDirty等值,并按以下原则进行了归并:
- /dev/ashmem/dalvik-heap和/dev/ashmem/dalvik-zygote归为Dalvik Heap。
- 其它以/dev/ashmem/dalvik-开头的内存区域归为Dalvik Other。
- Ashmem对应所有/dev/ashmem/下不以dalvik-开头的内存区域。
- Other dev对应的是以/dev下其他的内存区域。
- 文件的mmap按已知的几个扩展名分类,其余的归为other mmap。
- 其它部分,如[stack],[malloc],Unknown等。

了解了dumpsys的方法后,我们可以自己解析smaps,看看归并前各项的内存都是多少。这样能够得到比dumpsys更详细的信息,有助于分析一些问题。

首先将PSS分为以下几大类,计算各部分占比。在这个例子里,几大项是三分天下的节奏。Dalvik和Other dev内存都占了30%以上,剩下的是MMAP和Unknown。进行内存优化时不能只看Dalvik部分,需要同时评估所有的部分。

Dalvik:
Dalvik内存分为多个区域,meminfo统计的是所有区域累加的值。

  • Dalvik_Heap: 包括dalvik-heap和dalvik-zygote
    堆内存,所有的java对象实例都放在这里。
  • LinearAlloc: dalvik-LinearAlloc
    线性分配器,虚拟机存放载入类的函数信息,随着dex里的函数数量而增加。著名的65535个函数的限制就是从这里来的。
  • Accounting: dalvik-aux-structure, dalvik-bitmap, dalvik-card-table
    这部分内存主要做标记和指针表使用。dalvik-aux-structure随着类及方法数目而增大。dalvik-bitmap随着dalvik-heap的 增大而增大。
  • Code_Cache: dalvik-jit-code-cache
    jit编译代码后的缓存,随着代码复杂度的增加变大。

由于堆内存部分往往是应用消耗内存最多的地方,在内存优化中,最常见的方法就是减少Dalvik Heap中创建的对象,能够直接减少Dalvik Heap,并间接减少Accounting部分。减少代码会直接减少运行辅助部分。

在进行不同版本的对比测试时,我们往往会发现Dalvik Other和dex mmap出现了稳定的增长,这是由新加入的代码引入的内存消耗。

根据Dalvik虚拟机的原理,在加载class时,会根据类的变量个数及函数个数申请相应尺寸的内存,作为运行时的内部指针。这部分内存就会体现在LinearAlloc及aux-structure的增长中。随着版本的开发,应用class的数目及复杂度也在不断地增长,因此Dalvik Other部分也在不断地增长。

由于这部分内存的增长取决于代码复杂度,通常情况下并没有简单直接的方法能够降低它们的消耗。但是通过仔细分析他们的组成及原理,还是能够找出一些间接的方法降低这部分内存的,详细方法请见2.6节。

MMAPs:
系统会将一些文件mmap到内存中,对各个文件进行mmap的时机及大小比较复杂。Dex mmap是其中主要的内容。

应用的dex会占据较大的空间,并且随着代码增加使得dex文件变大,占用的内存也会增加。减小dex的(相当于减少代码)尺寸能够降低这部分内存占用,同时也会减少dalvik部分的内存。

1.4.3 zygote共享内存机制

在上一小节,我们介绍了应用各部分内存的含义,读者对dumpsys meminfo输出的大部分数据都能够有所理解。但dumpsys meminfo工具还会输出Heap Size/Alloc/Free部分的数值。我们知道这些数值是Dalvik虚拟机统计的内存堆的使用量,但这些数值是如何对应到Pss内存上的?比如Heap Alloc和Heap Pss往往相差不远,那他们是不是能够看做基本等同的呢?下面我们试图解释这几项数值之间的关系。

由于虚拟机运行时并不区分某个对象实例是Android框架共享的还是应用独有的,Heap Alloc统计的是由虚拟机分配的所有应用实例的内存,所以会将应用从zygote共享的部分也算进去,所以Heap Alloc值总是比实际物理内存使用值要大。

Heap Alloc虽然反映了Java代码分配的内存,但存在框架造成的失真。除此之外,进程还有许多其它部分也需要使用内存。为了准确了解应用消耗的内存,我们要从进程角度而不是虚拟机角度来进行观察。

PSS(Proportional Set Size),表示进程实际使用的物理内存,是由私有内存加上按比例分担计算的各进程共享内存得到的值。例如,如果有三个进程都使用了一个消耗30K内存的so库,那么每个进程在计算这部分PSS值的时候,只会计算10K。总的计算公式是:

Dalvik PSS内存 = 私有内存Private Dirty + (共享内存Shared Dirty / 共享的进程数)

从实际含义来讲,Private Dirty部分存放的是应用new出来的对象实例,是每个应用所独有的,不会再共享。Shared Dirty部分主要是zygote加载的Android框架部分,会被所有Android应用进程共享。通常进程数的值在10-50的范围内。

PSS是一个非常有用的数值,如果系统中所有的进程的PSS相加,所得和即为系统占用内存的总和。但要注意的是,进程的PSS并不代表进程结束后系统能够回收的内存大小。

1.4.4 多进程应用

根据我们在上一节中的描述,当一个进程结束后,它所占用的共享库内存将会被其它仍然使用该共享库的进程所分担,共享库消耗的物理内存并不会减少。实际上,所有共享使用了这个库的应用,PSS内存都会有所增加。对于一般的进程,只是共享着zygote进程的Android框架等基础部分,而通常手机使用时的应用进程数达到几十至上百,所以某个进程结束,其他进程内存增加的情况并不明显。

但对于多进程的应用来说,由于多个进程之间会共享很多内容,包括代码,资源,so库等等,因此单个进程结束造成的影响就会比较明显。以有两个进程的应用为例,进程共享着部分内存,因此当一个进程不再需要这些内存时,就会出现如图1-15所示中的场景。表现为一个进程的内存下降了,另一个进程就会明显的上升。

图1-15两个共享内存进程的内存变化

由此可见,我们在统计多进程的应用内存和进行优化时,需要综合考虑。以免出现努力优化了一个进程的内存,却造成其他进程内存增长的情况。


更多精彩内容欢迎关注腾讯优测的微信公众账号:

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

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:365351次
    • 积分:5470
    • 等级:
    • 排名:第4862名
    • 原创:188篇
    • 转载:4篇
    • 译文:0篇
    • 评论:109条
    最新评论