¿Cuáles son las ventajas de establecer largeHeap en verdadero?

Tengo una App con casi 50 clases que estoy configurando android:largeHeap="true", como se puede ver a continuación. ¿Es esta una buena practica?

<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>

Sugiera amablemente las ventajas y desventajas de su uso.

Tengo problemas de memoria, por eso hago esta pregunta.

Demasiado tarde para la fiesta aquí, pero ofreceré mis 0.02 $ de todos modos.
No es una buena idea usar android:largeHeap="true" aquí el extracto de Google que lo explica,

Sin embargo, la capacidad de solicitar un montón grande está pensada solo para un pequeño conjunto de aplicaciones que pueden justificar la necesidad de consumir más RAM (como una aplicación de edición de fotos grande). Nunca solicite un montón grande simplemente porque se ha quedado sin memoria y necesita una solución rápida; debe usarlo solo cuando sepa exactamente dónde se asigna toda la memoria y por qué debe retenerse. Sin embargo, incluso cuando esté seguro de que su aplicación puede justificar el gran montón, debe evitar solicitarla en la medida de lo posible. El uso de la memoria adicional será cada vez más en detrimento de la experiencia general del usuario porque la recolección de basura llevará más tiempo y el rendimiento del sistema puede ser más lento cuando se cambia de tarea o se realizan otras operaciones comunes.

aquí está el enlace completo de la documentación https://developer.android.com/training/articles/memory.html

ACTUALIZAR

Después de trabajar de manera insoportable out of memory errors, diría que agregar esto al manifiesto para evitar el problema de oom no es un pecado, también como @Milad señala a continuación, no afecta el funcionamiento normal de la aplicación

ACTUALIZACIÓN 2

Aquí están algunos consejos para solucionar conout of memory errors

1) Utilice estos devolución de llamada que da androide onLowMemory, onTrimMemory(int) y borrar la caché de la imagen como (Picasso, deslizamiento, fresco ....) se puede leer más acerca de ellos aquí y aquí
2) comprimir los archivos (imágenes, pdf)
3) leen sobre cómo manejar el mapa de bits de manera más eficiente aquí
4) Use lint regularmente antes de que comience la producción para garantizar que el código sea elegante y no voluminoso

Creo que esta es una pregunta muy eficaz y permítanme agregar algunos detalles sobre las ventajas y desventajas de usar esta opción.

Lo que obtienes :

• Obviamente, obtienes un montón más grande, lo que significa una disminución del riesgo de OutOfMemoryError.

Lo que pierdes:

• Puede perder algunos marcos, lo que puede provocar un enganche visible . Un montón más grande hace que las recolecciones de basura tomen más tiempo. Porque el recolector de basura básicamente tiene que atravesar todo su conjunto de objetos en vivo. Por lo general, el tiempo de pausa de la recolección de basura es de aproximadamente 5 ms, y puede pensar que unos milisegundos no son un gran problema. Pero cada milisegundo cuenta. El dispositivo Android tiene que actualizar su pantalla cada 16 ms y un tiempo de GC más prolongado podría empujar el tiempo de procesamiento de su marco por encima de la barrera de los 16 milisegundos, lo que puede causar un enganche visible.

• Además, el cambio de aplicaciones será más lento . El sistema Android puede matar procesos en la caché LRU comenzando con el proceso que se usó menos recientemente, pero también teniendo en cuenta qué procesos consumen más memoria. Entonces, si usa un montón más grande, es más probable que su proceso se elimine cuando esté en segundo plano, lo que significa que puede llevar más tiempo cuando los usuarios quieran cambiar de otras aplicaciones a la suya. Además, es más probable que otros procesos en segundo plano se eliminen cuando su proceso esté en primer plano, porque su aplicación requiere más memoria. Significa que cambiar de su aplicación a otras aplicaciones también lleva más tiempo.

Conclusión:

Evite el uso de la largeHeapopción tanto como sea posible. Puede costarle una caída de rendimiento difícil de notar y una mala experiencia de usuario.

Tengo una App con casi 50 clases

No creo que esto suponga un gran problema. La razón por la que tiene el error outOfMemory suele ser cargar demasiadas imágenes en su aplicación o algo así. Si no está satisfecho con el uso de un montón grande, debe encontrar una manera de optimizar el uso de la memoria.

También puede utilizar bibliotecas de carga de imágenes como Picasso , UIL o Glide . Todos ellos tienen la característica de caché de imágenes en memoria y / o en disco.

En realidad, android: largeHeap es el instrumento para aumentar la memoria asignada a la aplicación.

No existe una definición clara de la necesidad de utilizar esta bandera. Si necesita más memoria, Android le proporciona una herramienta para aumentarla. Pero la necesidad de consumir, tú te defines.

Si debe usar (y retener) una gran cantidad de memoria, entonces sí, puede y debe usar android:largeHeap="true". Pero si lo usa, debe estar preparado para que su aplicación se vacíe de la memoria siempre que otras aplicaciones estén en primer plano.

Por "estar preparado", me refiero a que debe diseñar para esa probabilidad, de modo que sus métodos onStop()y onResume()se escriban de la manera más eficiente posible, al tiempo que se asegura de que todo el estado pertinente se guarde y restaure de una manera que presente una apariencia perfecta para el usuario.

Hay tres métodos que se relacionan con este parámetro: maxMemory(), getMemoryClass(), y getLargeMemoryClass().

Para la mayoría de los dispositivos, maxMemory()representará un valor similar al getMemoryClass()predeterminado, aunque este último se expresa en megabytes, mientras que el primero se expresa en bytes.

Cuando use el largeHeapparámetro, maxMemory()se incrementará a un nivel superior específico del dispositivo, mientras getMemoryClass()que permanecerá igual.

getMemoryClass()no limita el tamaño de su pila, pero le indica la cantidad de pila que debe usar si desea que su aplicación funcione de manera cómoda y compatible dentro de los límites del dispositivo particular en el que se está ejecutando.

maxMemory()Por el contrario, no limitar el tamaño de la pila, y así lo hace a obtener acceso a montón adicional a través de aumentar su valor, y largeHeaphace que el valor de incremento. Sin embargo, la cantidad aumentada de montón sigue siendo limitada y ese límite será específico del dispositivo, lo que significa que la cantidad de montón disponible para su aplicación variará, dependiendo de los recursos del dispositivo en el que se ejecuta su aplicación. Por lo tanto, usar largeHeapno es una invitación para que su aplicación abandone toda precaución y se abra camino a través del buffet de todo lo que pueda comer.

Su aplicación puede descubrir exactamente cuánta memoria estaría disponible en un dispositivo en particular mediante el uso del largeHeapparámetro invocando el método getLargeMemoryClass(). El valor devuelto está en megabytes.

Esta publicación anterior incluye una discusión del largeHeapparámetro, así como una serie de ejemplos de qué cantidades de montón están disponibles con y sin su uso, en varios dispositivos Android específicos:

Detectar el tamaño del montón de aplicaciones en Android

No he implementado ninguna de mis propias aplicaciones con este parámetro establecido en verdadero. Sin embargo, tengo un código de memoria intensiva en una de mis aplicaciones para compilar un conjunto de parámetros relacionados con la optimización, que se ejecuta solo durante el desarrollo. Agrego el largeHeapparámetro solo durante el desarrollo, para evitar errores de falta de memoria al ejecutar este código. Pero elimino el parámetro (y el código) antes de implementar la aplicación.

Si los procesos de su aplicación deben crearse con un gran montón de Dalvik. Esto se aplica a todos los procesos creados para la aplicación. Solo se aplica a la primera aplicación cargada en un proceso; Si está utilizando una ID de usuario compartida para permitir que varias aplicaciones utilicen un proceso, todas deben utilizar esta opción de forma coherente o tendrán resultados impredecibles.

La mayoría de las aplicaciones no deberían necesitar esto y deberían centrarse en reducir el uso general de la memoria para mejorar el rendimiento. Habilitar esto tampoco garantiza un aumento fijo en la memoria disponible, porque algunos dispositivos están limitados por su memoria total disponible.