这是我在分析我们的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堆内容。

10-07 19:47
查看更多