使用android有什么缺点:largeHeap =“true”?

最近我将应用程序的最大内存峰值从100 MB减少到45 MB,我很好奇使用android有什么缺点:largeHeap =“true”, 而不是推动其他应用程序内存不足的可能性? 如果规模不足以推动推出其他应用程序是不合理的,那么它是不是一个很好的故障保护,例如,如果你的应用程序只会在会议中使用四天,那么崩溃可能是灾难性的? 或者是否有其他一些我正在寻找的骗局?

    根据我的理解,它真正做的就是允许你的应用程序有更高的内存限制 – 尽管设备之间的largeHeap大小不同,所以你无法保证特定数量的额外内存。 我们在我的工作中使用它来处理我们的应用程序,因为它将是设备上运行的唯一应用程序。

    正如本培训指南所指出的,

    “使用额外的内存将越来越不利于整体用户体验,因为当任务切换或执行其他常见操作时, 垃圾收集将花费更长时间并且系统性能可能会变慢 。”

    我认为这是一个非常有效的问题,让我就此加上一些补充说明。

    1)更长的垃圾收集时间

    很难衡量更大堆需要多少额外时间。 因为很多事情影响垃圾收集时间。 使用哪个Android运行时(Dalvik或ART)会影响垃圾收集时间(您可以在此处查看更多内容)。 在不同的Android版本上,垃圾收集的执行方式也不同。 但可以肯定的是,更大的堆使垃圾收集需要更长的时间。 因为垃圾收集器基本上必须遍历整个实时对象集。 如果您感到好奇,可以在2011 Google I / O的Android应用内存管理中了解有关此主题的更多信息。 并且如会话幻灯片中所述,垃圾收集暂停时间约为5毫秒。 您可能认为几毫秒并不是什么大不了的事,但每毫秒计算一次。 Android设备必须每16毫秒更新一次屏幕,更长的GC时间可能会使您的帧处理时间超过16毫秒的障碍,这可能会导致可见的挂接。

    2)任务切换较慢

    如这里所解释的,

    系统可以从最近最少使用的进程开始杀死LRU高速缓存中的进程,但也考虑哪些进程占用大多数内存。

    因此,如果您使用更大的堆,则当它处于后台时,您的进程更有可能被杀死,这意味着当用户想要从其他应用切换到您的应用时,可能需要更长的时间。 当您的流程处于前台时,后台流程也更有可能被淘汰,因为您的应用需要更大的内存。 这意味着从您的应用切换到其他应用也需要更长时间。 这些对用户来说显然是不好的。