What are the benefits of setting largeHeap to true?

Question

I have an application with almost 50 classes that I set android:largeHeap="true" , as 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> 

Please offer advantages and disadvantages for its use.

I am having memory problems, so I am asking this question.

Answer 1

It's too late for a party here, but I always offer $ 0.02.
It is not recommended to use android:largeHeap="true" here is an excerpt from google that explains this,

However, the ability to request a large heap is intended only for a small set of applications that can justify the need to consume more RAM (for example, as a large photo editing application). Never ask for a large pile simply because you run out of memory and you need a quick fix - you should use it only when you know exactly where all your memory is and why it should be saved. However, even if you are sure your application can justify a large pile, you should avoid the request as much as possible. The use of additional memory will increasingly be to the detriment of the general user experience, since garbage collection will take longer and system performance may be slower if switching tasks or performing other general operations.

here is the full documentation link 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 problem is not a sin, just as @Milad points out below, it does not affect the normal operation of the application

UPDATE 2

Here are some tips for : out of memory errors

1) Use this callback that android gives onLowMemory , onTrimMemory(int) and clears the image cache (picasso, glide, fresco ....) you can learn more about them here and here
2) compress your files (images, pdf)
3) read about how to process bitmaps more efficiently here
4) Use the lint regularly before production pushes to make sure the code is smooth and not bulky

Answer 2

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

What are you getting:

• Obviously, you get a large heap, which means reducing the risk of OutOfMemoryError .

What do you lose:

• You may lose several frames, which may cause visible grip . A large pile makes garbage collection long. Because the garbage collector basically has to go through your entire live set of objects. Typically, the pause time in garbage collection is about 5 ms, and you might think that a few milliseconds do not matter much. But every milliseconds counts. An Android device needs to refresh its screen every 16 ms, and a longer GC time can increase the processing time of a frame over a 16-millisecond barrier, which can cause visible grip.

• In addition, applications will slow down . The Android system can kill processes in the LRU cache, starting with the process that was used recently, but also gives some idea of ​​which processes are most used in memory. Therefore, if you use a large heap, your process will be more likely to be killed when it is created, which means that it may take longer when users want to switch from other applications to yours. In addition, other background processes are more likely to get knocked out when your process is prioritized because your application requires more memory. This means that moving from your application to other applications also takes longer.

Output:

Avoid using largeHeap as much as possible. It may cost you hard to notice a drop in performance and a bad user interface.

Answer 3

In fact, android: largeHeap is a tool to increase the allocated memory for the application.

There is no clear definition of whether to use this flag. If you need more memory, Android has a tool to increase it. But the need for use, you define yourself.

Answer 4

I have an application with almost 50 classes

I do not think this creates a lot of problems. The cause of the outOfMemory error is usually the loading of a large number of images in an application or something like that. If you are unsatisfied with using a large heap, you should find a way to optimize memory usage.

You can also use image download libraries such as Picasso , UIL, or Glide . All of them have the function of caching images in memory and / or on disk.

Answer 5

Whether your application processes with a large bunch of Dalvik should be created. This applies to all processes created for the application. It applies only to the first application loaded into the process; if you use a common user ID to allow multiple applications to use the process, they all must use this parameter sequentially or they will have unpredictable results.

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

Answer 6

If you must use (and save) a large amount of memory, then yes, you can and should use android:largeHeap="true" . But if you use it, you should be prepared for the fact that your application will be unloaded from memory when other applications are in the foreground.

By “prepare,” I mean that you must design for this probability that your onStop() and onResume() be written as efficiently as possible, while ensuring that all relevant states are saved and restored in such a way that a perfect external view for the user.

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

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

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

getMemoryClass() does not limit the heap size, but tells the heap volume that should be used if you want your application to function comfortably and compatible within the specific device on which you are working.

maxMemory() , in contrast, limits the size of the heap, so you access the extra heap by increasing its value, and largeHeap increases this value. However, the increased heap volume is still limited, and this limit will depend on the device, which means that the heap volume available to your application will vary depending on the resources of the device on which your application is running. Thus, using largeHeap is not an invitation for your application to give up all caution and go through the "all you can eat" buffet.

Your application can determine exactly how much memory will be available on a particular device using the largeHeap parameter by calling the getLargeMemoryClass() method. The return value in megabytes.

This previous post includes a discussion of the largeHeap parameter, as well as a number of examples of how largeHeap heap volumes are available with and without using it on several specific Android devices:

Determine heap size of application in Android

I have not deployed any of my own applications with this setting set to true. However, in one of my applications there is code that uses memory intensively to compile a set of parameters related to optimization, which is executed only during development. I add the largeHeap parameter only at design time to avoid largeHeap memory errors when executing this code. But I remove the parameter (and code) before deploying the application.