这是一个奇怪的问题,我在分析我们的android jar在lollipop中的兼容性时发现。我是android的新手。我写了一个简单的应用程序,它有一个屏幕和一个按钮,按下按钮,它调用jar中的方法来执行一些服务器调用。我使用adb命令来分析应用程序的内存占用量,
adb shell dumpsys meminfo <package_name>
这里是kitkat的足迹,(我没有添加其余的行,因为我们只会关注脚印中dalvik堆的私有脏列,因为这是专门为app分配的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。它是在两个操作系统中执行的相同应用程序,而且差异很大。
基于此的几个问题,
PS:我在棒棒糖中获取了应用程序的堆转储,我可以看到android.res.Resources系统类对象使用的4.4 MB内存。我不知道这些资源对象是什么因为app和jar都没有静态资源。
答案 0 :(得分:5)
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转储特定进程。
除此之外,您还可以使用Eclipse MAT插件来分析JVM堆内容。
答案 1 :(得分:1)
内存是私有的,这意味着它是独占的,或者是共享的,这意味着多个进程可能会映射和使用它(想想共享库代码等)。内存也可以是干净的 - 它没有被修改,因为它是从磁盘加载或提供为零填充页面或其他什么,所以如果它需要被释放为其他进程提供内存页面,它可以只是丢弃,重新加载/重新填充,如果再次需要它 - 或脏,这意味着如果它需要被释放,它必须被写出到交换区域,以便在必要时可以恢复修改后的内容。 p>
检查link。它将为您提供合子内存分配的概述。