最近我将应用程序的最大内存峰值从100 MB减少到45 MB，我很好奇使用android有什么缺点：largeHeap =“true”除之外是否有可能推动其他应用程序内存不足？如果规模不足以证明推出其他应用程序是不合理的，那么它是不是一个很好的故障保护，例如，如果你的应用程序只会在会议中使用四天，那么崩溃可能是灾难性的？或者我正在寻找其他一些骗局？
答案 0 :(得分：4)
根据我的理解，所有它真正做的就是允许你的应用程序有更高的内存限制 - 尽管设备之间的largeHeap大小不同，所以你不能保证特定数量的额外内存。我们在我的工作中使用它来处理我们的应用程序，因为它将是设备上运行的唯一应用程序。
答案 1 :(得分：4)
正如this training guide指出的那样，
“使用额外内存将越来越不利于整体用户体验，因为垃圾回收需要更长时间，系统性能可能会在任务切换或执行时变慢其他常见的操作。“
我认为这是一个非常有效的问题，让我在此补充说明。
1）垃圾收集时间越长：
很难衡量更大堆需要多少额外时间。因为很多事情影响垃圾收集时间。使用哪个Android运行时（Dalvik或ART）会影响垃圾收集时间（您可以在here查看更多信息）。垃圾收集在different Android version上的执行方式也不同。但可以肯定的是，更大的堆使垃圾收集需要更长的时间。因为垃圾收集器基本上必须遍历整个实时对象集。如果您感到好奇，可以从2011年Google I / O的Memory management for Android Apps会话中了解有关此主题的更多信息。并且如会话幻灯片中所述，垃圾收集暂停时间约为5毫秒。您可能认为几毫秒并不是什么大不了的事，但每毫秒计算一次。 Android设备必须每16毫秒更新一次屏幕，更长的GC时间可能会使您的帧处理时间超过16毫秒的障碍，这可能导致可见的挂接。
2）任务切换速度较慢：
正如here所述，
系统可能会从最近最少使用的进程开始终止LRU缓存中的进程，但会考虑哪些进程占用的内存最多。
因此，如果你使用更大的堆，你的进程在后台运行时更有可能被杀死，这意味着当用户想要从其他应用程序切换到你的应用程序时可能需要更长的时间。当您的流程处于前台时，后台流程也更有可能被淘汰，因为您的应用需要更大的内存。这意味着从您的应用切换到其他应用也需要更长时间。这些对用户来说显然是不好的。