Android 内存申请分析

作者:amritazhou

最近一直在做有关内存方面的优化工作,在做优化的过程,除了关注内存的申请量以及GC的情况之外,我们经常需要想方法找出是那些对象占用了大量内存,以及他们是如何导致GC的,这意味着我们需要获取对象申请的信息(大小,类型,堆栈等),我们这篇文章来介绍下几种获取对象申请信息的方法。

Allocation Trakcer

Allocation Tracker是Android Studio自带的一个功能,我们可以在MemoryMonitor中打开使用:

如上图,点击红框按钮,然后操作app,开始allocation tracking,当认为需要结束的时候,再次点击按钮,稍等片刻,即可以在Android Studio中dump出在 这段时间 内 新申请 对象的信息:

这种使用方式相当直观,可以看到申请对象大小,数量,还有堆栈等,通过这些信息,我们可以作为我们接下来进行内存优化的参考

但是,对于这种获取申请对象信息的方法,会存在几个问题:

1、获取的信息过于分散,中间夹杂着不少其他的信息,不完全是app申请的,可能需要进行不少查找才能定位到具体的问题; 2、跟TraceView一样,无法做到自动化分析,每次都需要开发者手工开始/结束,对于某些问题的分析可能会造成不便,而且对于批量分析来说也比较困难; 3、虽然在allocation tracking的时候,不会对手机本身的运行造成过多的性能影响,然而在停止allocation tracker的时候,直到把数据dump出来之前,会把手机完全卡死,时间过长甚至会直接ANR。

对于这几个问题,特别是自动化分析来说,是否能够直接在代码上发起Allocation Tracker的请求并获得数据来分析呢?

在代码中发起Allocation Tracker请求

自然是可以的,不然为什么会有这个标题。。。

我们可以把Android Studio的源码clone下来,在http://tools.android.com/build 中可以找到对应的git地址。在clone下来之后,我们可以在./tools/adt/idea/android/src/com/android/tools/idea/ddms/actions/ToggleAllocationTrackingAction.java中看到Android Studio具体是如何发起和停止Allocation Tracker的:

发起和停止:

获取并解析数据:

可以看出来这应该是一个异步的过程,在发起请求之后,系统会开始记录,然后再次发起停止请求之后,请求获得内存申请的数据(通过c.requestAllocationDetails这一行),然后再预先注册好的IClientChangeListener回调当中,获得数据已经准备好的通知,然后再获取数据,进行分析

对于这里发起和停止Allocation的数据,以及注册的回调,大概涉及到了Client,AndroidDebugBridge,IClientChangeListener等几个接口,这几个接口均不是Android Studio/IDEA中自带的类,而是在ddmlib这个库中包含的,在Android studio源码/tools/base/ddmlib目录中有其源码,另外,在/prebuilts/tools/common/offline-m2/com/android/tools/ddms/ddmlib目录中也有其预先build好的jar包。

ddmlib这个库的作用,是用来建立电脑和Android手机上连接的AndroidDebugBridge,然后让其对手机发起一些请求,例如刚才的AllocationTracker,还有dump hprof,traceview,甚至可以直接发送JdwpPacket,自定义PC和手机上的通讯(当然这个接口并非是开放的)。

更重要的是,Google这个库是对外开放的,并且放到了maven当中,可以让开发者直接获取到这个库,不过似乎Google并没有大肆宣传这个,甚至连文档都没有。

既然如此,我们也可以仿照上面的代码,用代码发起一次AllocationTracker请求,并进行分析:

代码比较长,我们主要做了这些操作:

1、初始化AndroidDebugBridge,并获取连接上的第一个设备对应的IDevice; 2、获取这个设备上"com.example.ragnarok.allocrecordtest"这个进程上对应的Client实例; 3、注册回调,并在回调中获取AllocationTracker回来的数据,并调用AllocationParser进行解析; 4、发起和停止allocation tracker。

最后在分析的时候,我们获得了一组AllocationInfo,存储了申请对象的信息:

因为现在可以用代码发起Allocation Tracker请求了,那我们就可以接入自动化分析,并过滤掉我们不需要的数据。

但是这样,也还是会有问题:

1、这种方法会占用adb端口,这意味着可能在使用的时候,需要停止掉其他地方对adb的使用; 2、在停止Allocation Tracker之后,requestAllocationDetails的调用还是会卡死手机,当然其实对于自动化分析来说,这里问题应该不大,但是对于使用者来说,还是造成了些许不爽。

对于上面的第二个问题,我们先来分析下Android上的JVM是如何响应发过来的Allocation Tracker请求的

Android 的 JVM 如何响应 Allocation Tracker 请求(Dalvik only now)

我们先来看下Dalvik虚拟机是怎么响应这个请求的,下面仅以4.4.4的代码为例

首先,Dalvik虚拟机在收到Allocation Tracker的请求之后,在对JdwpPacket包进行解析之后,最后会在DdmVmInternal这个类中进行处理,这个类在/libcore/dalvik/src/main/java/org/apache/harmony/dalvik/ddmc/DdmVmInternal.java当中,其中有这么两个方法:

很明显,这两个方法是用于开启和关闭Allocation Tracker,并且获得申请对象信息的数据的,然而是native的方法,对应的native代码在/dalvik/vm/native/org_apache_harmony_dalvik_ddmc_DdmVmInternal.cpp这里:

而dvmEnableAllocTracker,dvmDisableAllocTracker,dvmDdmGetRecentAllocations这几个方法,经过几层的调用之后,最后是调用到了/dalvik/vm/AllocTracker.cpp这里的方法:

从上面的代码可以看出,在开启了Allocation Tracker之后,在Dalvik全局变量gDvm下,将其中的allocRecords指向了一块新的申请的内存区域,另外allocRecordHead指向最新申请的对象信息的index,allocRecordCount则是总的记录的数量,另外allocRecordMax则是整个Allocation Tracker所允许记录的最大申请对象信息的数目,在4.4.4这个版本下,这个值默认是65536,也可以在手机中的/sytem/build.prop中指定dalvik.vm.allocTrackerMax项的值。 这里很明显看出来,gDvm.allocRecords是用来记录新申请对象的信息的,而申请对象的时候,只要开启了Allocation Tracker,每次都会往这里添加一个记录,具体代码在这里:

首先这里是新申请对象地方,在/dalvik/vm/alloc/Alloc.cpp中:

而在dvmTrackAllocation方法,则是在/vm/AllocTracker.h中定义:

分析到这里,Dalvik对Allocation Tracker的响应过程就非常清晰了:

1、在收到Allocation Tracker的请求的时候,首先给Dalvik全局变量gDvm中的allocRecords字段指向一段新申请的内存,申请内存的大小,由gDvm.allocRecordMax指定; 2、后续Dalvik每次新申请对象的时候,只要allocRecords不为NULL,那就会不断的往allocRecords指向的内存区域中写入的新申请对象的信息,包括类型,大小,线程号,堆栈。

而gDvm这个变量则具体是一个全局记录Dalvik虚拟机中状态的全局变量,定义和声明都在/dalvik/vm/Globals.h中:

而AllocRecord的定义,则是在/dalvik/vm/AllocTracker.cpp 中:

可以看出来这里拿到的信息,跟直接使用ddmlib的是一样的

另外,可以看到gDvm的声明是为extern的,这意味着我们或许可以 直接 获取到这个变量,一颗赛艇!

不影响手机本身性能的情况下获取申请对象信息

从上面的代码分析可以看到,类型为DvmGlobals的gDvm这个变量被声明成了extern,并且为非static变量,这意味在dalvik的so中,我们可以直接在符号表中获取到这个变量,简单来说,测试的代码如下:

上面的#include "Globals.h"是指Dalvik源码中的Globals.h头文件, 另外这段Native的代码需要打包在某个app当中,然后在开启Allocation Tracker之后(之前介绍的随便一种方法都可以),运行这段代码,那么t_gDvm->allocRecords中就是申请对象的数据了,可以直接读取里面的字段,打印出来大概是这样的:

由于是直接读取Dalvik本身记录对象信息的结构,没有了结束Allocation Tracker时候把数据dump出来的请求,这意味着完全不会影响手机本身的性能,而且对于对象信息的获取,也能够更加的及时,例如说每隔10s把数据拿出来分析。相对来说,对于之前使用ddmlib的方案,10s定时请求这么高的频率,很有可能跑一会直接就把手机卡死了。

但是对于这种方案,会存在兼容性问题,这里可以看到,我们获取gDvm变量的方式是用dlsym系统调用直接拿出来,然后强转成DvmGlobals类型,然而由于不同版本的Dalvik虚拟机中的DvmGlobals的定义不一样,可能会造成拿出gDvm这个符号之后,对应的allocRecords字段并不是真正的在这台机器上的allocRecords字段,出现数据的错乱,或者gDvm->allocRecords压根为NULL 。就目前的简单测试来,暂时只有MX3 4.4.4系统的flyme os能够正常操作,估计这里要适配大部分机器的话,工作量应该不少。

Notes:

1、关于Allocation Tracker在JVM层的响应,目前暂时只有Dalvik的分析,而ART对Allocation Tracker的处理似乎更加复杂,尚在研究中。 2、这篇文章中的示例代码,可以从我的Github上拿到:https://github.com/ragnraok/AllocRecordDemo

本文来源于:WeMobileDev 微信公众号

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏向治洪

Android热插拔事件处理详解

一、Android热插拔事件处理流程图 Android热插拔事件处理流程如下图所示: ? 二、组成 1. NetlinkManager:       ...

5257
来自专栏Linyb极客之路

APP架构设计经验谈:接口的设计

App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。

703
来自专栏禅林阆苑

memcache学习笔记

下载稳定版的memcache包,http://pecl.php.net/package/memcache

1132
来自专栏Java帮帮-微信公众号-技术文章全总结

Sharding-JDBC—分库分表实例【面试+工作】

Sharding-JDBC是一个开源的适用于微服务的分布式数据访问基础类库,它始终以云原生的基础开发套件为目标。

932
来自专栏xingoo, 一个梦想做发明家的程序员

Java程序员的日常——经验贴(纯干货)二

继昨天的经验贴,今天的工作又收获不少。 windows下编辑器会给文件添加BOM 在windows的编辑器中,为了区分编码,通常会添加一个BOM标记。比如...

1999
来自专栏我和PYTHON有个约会

爬虫 0030~ requests利刃出鞘

requests第三方封装的模块,通过简化请求和响应数据的处理,简化繁琐的开发步骤和处理逻辑、统一不同请求的编码风格以及高效的数据处理特性等而风靡于爬虫市场。

741
来自专栏张善友的专栏

Mongo Database 性能优化

SQL Server有工具进行数据库的优化,Mongo Database Profiler.不仅有,而且功能更强大。 MongoDB 自带 Profiler,可...

26810
来自专栏Golang语言社区

Leaf 游戏服务器框架简介

下载地址: https://github.com/name5566/leaf/blob/master/TUTORIAL_ZH.md Leaf 游戏服务器框架简介...

4317
来自专栏Keegan小钢

App架构设计经验谈:接口的设计

App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。

883
来自专栏公有云大数据平台弹性MapReduce

浅谈Hadoop Distcp工具的InputFormat

从Hadoop的出现到现在已经超过十年了,它在大数据领域扮演着一个重要的角色,相信在Hadoop的使用过程中,或多或少的都会用到自带的一个常用工具,就是Hado...

1053

扫码关注云+社区