最近我将我的应用程序的最大内存峰值从 100 MB 降低到了 45 MB,我很好奇使用 android:largeHeap="true"除了可能将其他应用程序推出内存之外还有什么缺点?如果大小没有增长到足以证明推出其他应用程序的合理性,这不是一个很好的故障保护措施,例如,如果您的应用程序在一个可能会造成灾难性崩溃的会议上仅使用四天?还是我正在寻找其他一些骗局?
2 回答
据我了解,它真正要做的就是允许您的应用程序具有更高的内存限制——尽管设备之间的 largeHeap 大小不同,因此不能保证特定数量的额外内存。我们在我的工作中将它用于我们的一个应用程序,因为它将是设备上唯一运行的应用程序。
正如本培训指南所指出的,
“使用额外的内存将越来越多地损害整体用户体验,因为垃圾收集将花费更长的时间,并且在任务切换或执行其他常见操作时系统性能可能会变慢。”
我认为这是一个非常有效的问题,让我对此添加一些额外的解释。
1)更长的垃圾收集时间:
很难衡量更大的堆需要多少额外的时间。因为很多事情都会影响垃圾收集时间。使用哪个 Android 运行时(Dalvik 或 ART)会影响垃圾收集时间(您可以在此处查看更多信息)。此外,垃圾收集在不同的 Android 版本上执行的方式也不同。但可以肯定的是,更大的堆会使垃圾收集需要更长的时间。因为垃圾收集器基本上必须遍历您的整个活动对象集。如果您好奇,您可以从Android 应用程序的内存管理中了解有关此主题的更多信息2011 年 Google I/O 会议。正如会话幻灯片中所述,垃圾收集暂停时间约为 5 毫秒。您可能认为几毫秒没什么大不了的,但每一毫秒都很重要。Android 设备必须每 16 毫秒更新一次屏幕,较长的 GC 时间可能会使您的帧处理时间超过 16 毫秒的障碍,这可能会导致明显的卡顿。
2) 较慢的任务切换:
正如这里所解释的,
系统可能会从最近最少使用的进程开始杀死 LRU 缓存中的进程,但也会考虑哪些进程最占用内存。
因此,如果您使用更大的堆,您的进程在后台运行时更有可能被杀死,这意味着当用户想要从其他应用程序切换到您的应用程序时可能需要更长的时间。当您的进程处于前台时,后台进程也更有可能被踢出,因为您的应用程序需要更大的内存。这意味着从您的应用切换到其他应用也需要更长的时间。这些显然对用户不利。