这是我在分析我们的android jar在棒棒糖中的兼容性时发现的一个奇怪的问题。我是android新手。我写了一个简单的应用程序,它有一个单一的屏幕、一个按钮和一个按钮按下,它调用jar中的方法来执行一些服务器调用,我使用adb命令来分析应用程序的内存占用,
adb shell dumpsys meminfo <package_name>
这里是kitkat中的内存(我没有添加其他行,因为我们只关心底图中dalvik heap的private dirty列,因为这是专门为应用程序分配的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,而lollipop使用大约10mb的ram,这是两个操作系统中执行的同一个应用程序,差别很大。
基于这个有几个问题,
你们中有人看到棒棒糖增加了记忆消耗吗?.
你知道为什么棒棒糖中的公羊用量更高吗?
是否有工具可以可视化应用程序的RAM分配?.
PS:我在棒棒糖中对应用程序进行了堆转储,我可以看到android.res.resources系统类对象使用了4.4MB的内存,我不知道这些资源对象是什么,因为应用程序和jar都没有静态资源。
最佳答案
android棒棒糖内置了art(android运行时)虚拟机,而不是kitkat的dalvik虚拟机。art将应用程序的字节码转换为本机指令,然后由设备的运行时环境执行。art处理提前编译(aot)的概念,并在应用程序安装期间保存编译的类,其中dalvik处理准时(jit)编译的原则,在应用程序存在时清除已编译类的缓存,并在应用程序的新实例启动时重新编译每个类。
你知道为什么棒棒糖中的公羊用量更高吗?
以保持与现有应用程序的向后兼容性。art使用与dalvik相同的输入字节码,通过作为apk文件一部分的标准.dex文件提供,而.odex文件则替换为可执行和可链接格式(elf)可执行文件。一旦使用art的设备上dex2oat实用程序编译了应用程序,它就只能从编译的elf可执行文件运行;这种方法消除了jit编译所涉及的各种开销,但在安装应用程序时需要额外的编译时间,而且应用程序占用的空间稍微大一些,以存储编译后的代码。
是否有工具可以可视化应用程序的RAM分配?.
cat/proc/meminfo这将提供一些内存统计信息。如果你添加“memfree+cached”,你将得到总的可用内存。
dumpsys meminfo这将为所有当前进程提供内存信息
dumpsys meminfo-为特定进程转储。
除此之外,您还可以使用eclipse mat插件分析jvm堆内容。