Recently I’ve reduced the max memory peak of my application from 100 MB to 45 MB and I’m curious what are the downsides of using the android:largeHeap=”true” other than the potential to push other applications out of memory? If the size doesn’t grow enough to justify pushing other apps out wouldn’t it be a nice failsafe, for instance, if your app was only going to be used for four days at a convention where a crash would be potentially catastrophic? Or is there some other con that I’m looking past?
From my understanding, all it will really do is allow your application a higher memory limit – the largeHeap size differs between devices though, so you’re not guaranteed a particular amount of extra memory. We use it at my job for one of our applications since it will be the only application running on the device.
As this training guide pointed out,
“Using the extra memory will increasingly be to the detriment of the overall user experience because garbage collection will take longer and system performance may be slower when task switching or performing other common operations.”
I think this is a very effective question, and let me add some additional explanation on this.
1) Longer garbage collection time :
It’s hard to measure how many extra time would take for larger heap. Because a lot of things affect garbage collection time. Which Android runtime(Dalvik or ART) to use affects garbage collection time(You can see more on this at here). Also garbage collection is performed differently on different Android version. But it is for sure that larger heap make garbage collections take longer. Because the garbage collector basically has to traverse your entire live set of objects. If you are curious, you can learn more about this topic from Memory management for Android Apps session at 2011 Google I/O. And as noted in the session’s slide, garbage collection pause time is about 5ms. You may think few milliseconds are not a big deal, but every millisecond count. Android device has to update its screen in every 16 ms and longer GC time might push your frame processing time over the 16 millisecond barrier, which can cause a visible hitching.
2) Slower task switching :
As explained here,
the system may kill processes in the LRU cache beginning with the process least recently used, but also giving some consideration toward which processes are most memory intensive.
So if you use larger heap, your process would more likely to be killed when it’s backgrounded, which means it may take longer time when users want to switch from other apps to yours. Also backgrounded processes will more likely to be kicked out when your process is foreground, because your app require larger memory. It means switching from your app to other apps also takes longer. These are obviously bad for users.