移动App性能测评与优化1.5.3 dex mmap

1.5.3 dex mmap

dex mmap在Android应用中的作用是映射classes.dex文件。Dalvik虚拟机需要从dex文件中加载类信息、字符串常量等,还需要在调用函数的时候直接从mmap内存中读取函数代码(dvm
bytecode)来执行;所以该部分内存是程序运行必不可少的。

以一个示例应用为例,我们能够在MAT中看到,应用加载了大约1500个class类型,而dex文件的class类型共有10635个。使用dex mmap动态统计功能统计后发现,虽然只加载了1500个类,但dex内存通常高达4~6MB,差不多是dex文件大小的一半,如表1-1所示。

表1-1 dex内存的利用率

启动后加载class数  总共class数      class数占比

约1500 10635   14%

启动后dex mmap内存   dex文件大小     dex文件大小占比

约4~6MB   10.9MB 37%~55%

 

从以上数据可以看到,很大一部分dex内存空间被浪费了,实际使用到的数据和代码并没有那么多,这是为什么呢?这是由于dex文件在生成时按字母顺序排列。由于4KB页面加载的原因,实际运行时会加载许多相邻但不会被用到的数据。例如在代码中使用了A1类,虚拟机就需要加载包含A1类数据的页面。但由于A1的数据只有1KB,那在加载的4KB页面中,还会有A2A3A4类,总共占用了4KB内存。

假设我们的代码里在用到A1类后,还会用到B1、C1、D1类,那么如果能在dex文件中将A1、B1、C1、D1类放在一起,虚拟机就只需要加载一个4KB页面,不仅减少了内存使用,还对程序的运行速度有好处。因此,优化的思路就是调整dex文件中数据的顺序,将能够用到的数据紧密排列在一起。

时间: 2024-10-27 07:40:10

移动App性能测评与优化1.5.3 dex mmap的相关文章

移动App性能测评与优化导读

前 言 Preface 写作背景 当前移动设备越来越多地涌现在我们日常生活中,像网络购物.充值缴费.新闻资讯.理财.团购.车辆保养等都可以通过移动设备来搞定.通过移动设备可以帮助人们更便捷高效地完成很多事,同时越来越多的需求也希望能通过移动设备来完成,这样也催生了很多工作机会,让IT技术人员能开发更多的App来满足不同用户的不同需求.相对于传统PC,移动设备有其自身的特点,如屏幕小.移动网络复杂且需要收费.电量有限等.因此,在完成用户一系列需求的背后,我们也面临一系列的问题.比如说,如何能保证开

移动App性能测评与优化1.4.2 smaps

1.4.2 smaps 由于Android底层基于Linux内核,进程内存信息也和Linux一致,所以Dalvik Heap之外的信息都能够从/proc/<pid>/smaps中取得. 在smaps中,列出了进程的各个内存区域,并根据分配的不同用途做标识,以下是root用户使用cat /proc/<pid>/smaps的一个例子: 788c2000-789bf000 rw-p 00000000 00:00 0          [stack:5113] Size:         

移动App性能测评与优化1.6 本章小结

1.6 本章小结 在这一章里,我们通过对几个案例的分析,基本了解了Android应用的各种内存组成,以及这些成分是如何被消耗的,也总结出了一些节约和优化内存的经验.在这一小节里我们把经验都列出来供读者参考. 内存的主要组成索引: Native Heap:Native代码分配的内存,虚拟机和Android框架本身也会分配 Dalvik Heap:Java代码分配的对象 Dalvik Other:类的数据结构和索引 so mmap:Native代码和常量 dex mmap:Java代码和常量 内存工

移动App性能测评与优化1.5.4 dex文件优化

1.5.4 dex文件优化 为了达到优化的目的,我们需要先了解dex文件的结构.dex文件结构如表1-2所示. 表1-2 dex文件结构 区 域  描 述  内 容 Header             索引区  String Id list 指向Data的偏移量         Type Id list             Method Prototype Id list             Field Id list              Method Id list      

移动App性能测评与优化1.5 案例:优化dex相关内存

1.5 案例:优化dex相关内存 上一节提到,随着代码功能的增加,代码复杂度也在不断地变大,这时我们往往会发现Dalvik Other和Dex Mmap这两部分消耗的内存也在不断增加.在之前的例子里,我们知道这两部分的内存已经接近总内存的一半.在Dalvik Heap已经充分优化的情况下,我们有必要继续研究这部分内存如何优化. 我们已经知道Dalvik Other存放的是类的数据结构及关系,而Dex Mmap是类函数的代码和常量.通常情况下,要减少这部分内存,需要从代码出发,精简无用代码,或者将

移动App性能测评与优化1.2.4 新的问题

1.2.4 新的问题 经过上一轮的优化,在内存监视器里新版本的Heap内存表现已经比较好了,新功能只消耗了几万字节到几十万字节内存.但是要注意的是,Heap内存并不是应用的全部,我们在设置或其他管理工具里看到的应用内存大小是应用整个进程的内存使用量.也有可能出现Heap部分完全没有增长而其他部分增长的情况. 要观察进程的内存使用情况,就需要用到其他的观测工具,Android里最常用于观察进程内存的方法就是dumpsys meminfo <package name|pid>命令. 对我们的新版应

移动App性能测评与优化2.1.2 软件测试

2.1.2 软件测试 上面一节讲述的都是从整机层面去量化并控制手机功耗,相比做App的公司来说做手机ROM的厂商较少.那么从应用的性能优化出发,上面讲述的硬件测试方法就不那么实用了,原因如下: 每个App本身的耗电是微量的,硬件测试方法中仪器本身波动可能无法体现App的功耗: 硬件测试方法只能通过测试整机功耗来体现App耗电,而这样很难避免其他App影响测试结果. 为了解决这个问题,MIG专项测试组从分析Android系统电量统计原理入手,并结合在实际项目中对耗电优化做的工作,来分享下对App功

移动App性能测评与优化1.3.2 问题所在

1.3.2 问题所在 在了解DVM分配释放内存的机制后,根据dumpsys观察到的现象,猜测可能出现了页利用率问题(页内碎片).如图1-13所示,第一行:在开始阶段,内存分配较满.第二行:经过GC(垃圾回收)后,大部分对象被释放,少部分留下来.   图1-13 产生内存碎片 这种情况下可能会产生的问题是,整页的4KB内存中可能只有一个小对象,但统计PrivateDirty/Pss时还是按4KB计算. 在通常的JVM中,借助Compacting GC机制,整理内存对象,将散布的内存移动到一起.但根

移动App性能测评与优化2.1.1 硬件测试

2.1.1 硬件测试 方法1:通过Android API获取,代码如下: registerReceiver(receiver, new IntentFilter(Intent.ACTION_BATTERY_CHANGED)): 这种方法的缺点:获取手机整机耗电,实时性差精度小(只能监控电池电量剩余量和跳变),测试工具本身的性能消耗,手机休眠后无法持续监测. 方法2:通过读取系统电池传感器设备节点. /sys/class/power_supply/battery/uevent 这种方法的缺点是:测