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

最近,我将应用程序的最大内存峰值从100 MB减less到了45 MB,我很好奇使用android:largeHeap =“true”的缺点, 除了推动其他应用程序的内存不足之外,还有什么缺点? 如果规模不足以certificate推出其他应用程序是不合适的,例如,如果您的应用程序只在会议中使用了四天,那么崩溃将会是灾难性的。 或者还有其他一些我正在看的过去?

Solutions Collecting From Web of "有什么缺点使用android:largeHeap =“true”?"

从我的理解来看,它所要做的就是让应用程序具有更高的内存限制 – 不同设备之间的largeHeap大小不同,所以不能保证有足够的额外内存。 我们在我的应用程序中使用它,因为它将是设备上唯一运行的应用程序。

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

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

我认为这是一个非常有效的问题,让我再补充一些解释。

1)更长的垃圾收集时间

很难衡量多less额外的时间将需要更大的堆。 因为很多东西影响垃圾收集时间。 哪个Android运行时(Dalvik或ART)使用影响垃圾收集时间(您可以在这里看到更多)。 垃圾收集在不同的Android版本上也有不同的performance。 但可以肯定的是,较大的堆会使垃圾收集需要更长的时间。 因为垃圾收集器基本上必须遍历整个活的一组对象。 如果您有兴趣,可以从2011年Google I / O的Android应用程序内存pipe理会话中了解更多关于此主题的内容。 如会议的幻灯片中所述,垃圾收集暂停时间约为5ms。 你可能会认为几毫秒不是什么大不了的事,但每一毫秒都算。 Android设备必须每隔16 ms更新其屏幕,并且更长的GC时间可能会使您的帧处理时间超过16毫秒的屏障,从而导致可见的挂住。

2)更慢的任务切换

如这里所解释的,

系统可以从最近使用最less的进程开始,终止LRU高速caching中的进程,但也考虑到哪些进程是最占用内存的。

所以如果你使用的是较大的堆,那么你的进程就更有可能在后台被杀死,这意味着当用户想要从其他应用切换到你的时候可能需要更长的时间。 当后台进程处于前台时,后台进程将更有可能被踢出,因为你的应用需要更大的内存。 这意味着从您的应用切换到其他应用也需要更长的时间。 这对用户来说显然是不好的。