What are advantages of setting largeHeap to true?

问题

I have an App with almost 50 classes I am setting android:largeHeap=\"true\", as can be seen below. Is this a good practice?

<application
        android:name=\".MyApplication\"
        android:allowBackup=\"true\"
        android:icon=\"@drawable/ic_launcher\"
        android:label=\"Mall\"
        android:largeHeap=\"true\"
        android:logo=\"@drawable/logo_for_up\"
        android:screenOrientation=\"portrait\"
        android:theme=\"@style/AppTheme\" >
</application>

Kindly suggest advantages and disadvantages for using it.

I am getting memory issues that\'s why I ask this question.

回答1:

Way too late for the party here, but i will offer my 0.02$ anyways.
It's not a good idea to use android:largeHeap="true" here's the extract from google that explains it,

However, the ability to request a large heap is intended only for a small set of apps that can justify the need to consume more RAM (such as a large photo editing app). Never request a large heap simply because you've run out of memory and you need a quick fix—you should use it only when you know exactly where all your memory is being allocated and why it must be retained. Yet, even when you're confident your app can justify the large heap, you should avoid requesting it to whatever extent possible. 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.

here's the complete link of the documentation https://developer.android.com/training/articles/memory.html

UPDATE

After working excrutiatingly with out of memory errors i would say adding this to the manifest to avoid the oom issue is not a sin, also like @Milad points out below it does not affect the normal working of the app

UPDATE 2

Here are a few tips to deal with out of memory errors

1) Use these callback that android gives onLowMemory, onTrimMemory(int) and clear the cache of image like (picasso, glide, fresco....) you can read more about them here and here
2) compress your files(images, pdf)
3) read about how to handle bitmap more efficiently here
4) Use lint regularly before production pushes to ensure code is sleek and not bulky

回答2:

I think this is a very effective question, and let me add some details about advantages and disadvantages of using this option.

What You Get :

• Obviously, you get larger heap, which means decreasing risk of OutOfMemoryError.

What You Lose :

• You may lose some frames, which can cause a visible hitching. Larger heap makes garbage collections take longer. Because the garbage collector basically has to traverse your entire live set of objects. Usually, garbage collection pause time is about 5ms, and 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.

• Also switching apps will become slower. Android 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 other 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.

Conclusion :

Avoid using largeHeap option as much as possible. It may cost you hard-to-notice performance drop and bad user experience.

回答3:

I have an App with almost 50 classes

I don't think this makes much problem. The reason why you've got outOfMemory error is usually loading to much images in app or something like that. If you are unhappy to use large heap you must find a way to optimize using memory.

You can also use Image Loading Libraries such as Picasso, UIL or Glide. All of them have the feature of image caching in memory and/or on disk.

回答4:

Actually android:largeHeap is the instrument for increasing your allocated memory to app.

There is no clear definition of the need to use this flag. If you need more memory - Android provides you with a tool to increase it. But necessity of using, you define yourself.

回答5:

If you must use (and retain) a large amount of memory, then yes, you can and should use android:largeHeap="true". But if you do use it, you should be prepared to have your app flushed from memory whenever other apps are in the foreground.

By "be prepared," I mean that you should design for that likelihood, so that your onStop() and onResume() methods are written as efficiently as possible, while ensuring that all pertinent state is saved and restored in a manner that presents a seamless appearance to the user.

There are three methods that relate to this parameter: maxMemory(), getMemoryClass(), and getLargeMemoryClass().

For most devices, maxMemory() will represent a similar value to getMemoryClass() by default, although the latter is expressed in megabytes, while the former is expressed in bytes.

When you use the largeHeap parameter, maxMemory() will be increased to a device-specific higher level, while getMemoryClass() will remain the same.

getMemoryClass() does not constrain your heap size, but it tells you the amount of heap you should use if you want your app to function comfortably and compatibly within the limits of the particular device on which you are running.

maxMemory(), by contrast, does constrain your heap size, and so you do gain access to additional heap through increasing its value, and largeHeap does increase that value. However, the increased amount of heap is still limited, and that limit will be device-specific, which means that the amount of heap available to your app will vary, depending on the resources of the device on which your app is running. So, using largeHeap is not an invitation for your app to abandon all caution and oink its way through the all-you-can-eat buffet.

Your app can discover exactly how much memory would be made available on a particular device through using the largeHeap parameter by invoking the method getLargeMemoryClass(). The value returned is in megabytes.

This earlier post includes a discussion of the largeHeap parameter, as well as a number of examples of what amounts of heap are made available with and without its usage, on several specific Android devices:

Detect application heap size in Android

I have not deployed any of my own apps with this parameter set to true. However, I have some memory-intensive code in one of my apps for compiling a set of optimization-related parameters, that runs only during development. I add the largeHeap parameter only during development, in order to avoid out of memory errors while running this code. But I remove the parameter (and the code) prior to deploying the app.

回答6:

Whether your application's processes should be created with a large Dalvik heap. This applies to all processes created for the application. It only applies to the first application loaded into a process; if you're using a shared user ID to allow multiple applications to use a process, they all must use this option consistently or they will have unpredictable results.

Most apps should not need this and should instead focus on reducing their overall memory usage for improved performance. Enabling this also does not guarantee a fixed increase in available memory, because some devices are constrained by their total available memory.

来源：https://stackoverflow.com/questions/27396892/what-are-advantages-of-setting-largeheap-to-true