这是一个奇怪的问题,我在分析我们的android jar在lollipop中的兼容性时发现.我是android的新手.我写了一个简单的应用程序,它有一个屏幕和一个按钮,按下按钮,它调用方法jar执行一些服务器调用.我使用adb命令来分析应用程序的内存占用量,
adb shell dumpsys meminfo
这里是kitkat的足迹,(我没有添加其余的行,因为我们只关注脚印中dalvik堆的私有脏列,因为这是专门为应用程序分配的RAM,包括我们自己的分配.)
** MEMINFO in pid 876 [XXXXX] ** Pss Private Private Swapped Heap Heap Heap Total Dirty Clean Dirty Size Alloc Free ------ ------ ------ ------ ------ ------ ------ Native Heap 3054 3032 0 0 6208 5733 178 Dalvik Heap 4338 4012 0 0 12756 11514 1242
这是棒棒糖的足迹,
** MEMINFO in pid 201 [XXXX] ** Pss Private Private Swapped Heap Heap Heap Total Dirty Clean Dirty Size Alloc Free ------ ------ ------ ------ ------ ------ ------ Native Heap 3412 3360 0 0 5572 5236 335 Dalvik Heap 10359 10132 0 0 18762 11338 7424
如果比较两个私有脏列中的dalvik堆,kitkat使用大约4MB的RAM而棒棒糖使用大约10MB的RAM.它是在两个操作系统中执行的相同应用程序,并且差异很大.
基于此的几个问题,
你们有没有人在棒棒糖中看到这种增加的记忆消耗?
知道为什么棒棒糖的RAM使用率更高?
是否有可视化应用程序RAM分配的工具?
PS:我在棒棒糖中获取了应用程序的堆转储,我可以看到android.res.Resources系统类对象使用的4.4 MB内存.我不知道这些资源对象是什么,因为app和jar都没有静态资源.
Android Lollipop内置了ART(Android Runtime)虚拟机而不是Kitkat的Dalvik vm.ART将应用程序的字节码转换为本机指令,稍后由设备的运行时环境执行.ART工作于提前编译(AOT)的概念,并在应用程序安装期间保存已编译的类,其中Dalvik的工作原理是Just及时(JIT)编译并在应用程序存在时清除已编译类的缓存,并在每次启动应用程序的新实例时重新编译每个类.
知道为什么棒棒糖的RAM使用率更高?
保持与现有应用程序的向后兼容性.ART使用与Dalvik相同的输入字节码,通过标准.dex文件作为APK文件的一部分提供,而.odex文件替换为可执行和可链接格式(ELF)可执行文件.一旦使用ART的设备上的dex2oat实用程序编译应用程序,它就可以从编译的ELF可执行文件中运行; 这种方法消除了JIT编译所涉及的各种开销,但是在安装应用程序时需要额外的时间进行编译,并且应用程序占用稍大的空间来存储编译的代码.
是否有可视化应用程序RAM分配的工具?
cat/proc/meminfo - 这将给出一些内存统计信息.在那里,如果你添加"memfree + cached",你将获得完全可用的可用内存.dumpsys meminfo - 这将为特定进程的所有当前进程dumpsys meminfo -to dump提供内存信息.
除此之外,您还可以使用Eclipse MAT插件来分析JVM堆内容.