supportsrtl - android:fullbackupcontent

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

Question

Tengo una aplicación con casi 50 clases. 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>

Amablemente sugiera ventajas y desventajas para usarlo.

Tengo problemas de memoria por eso hago esta pregunta.

Answer 1

Tengo una aplicación con casi 50 clases.

No creo que esto haga mucho problema. La razón por la que tiene el error OutOfMemory generalmente se carga en muchas imágenes en la 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 usar bibliotecas de carga de imágenes como Picasso , UIL o Glide . Todos ellos tienen la función de almacenamiento en caché de imágenes en la memoria y / o en el disco.

Answer 2

Creo que esta es una pregunta muy efectiva, 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 cuadros, lo que puede causar un enganche visible . Un montón más grande hace que la recolección de basura tome más tiempo. Porque el recolector de basura básicamente tiene que atravesar todo tu conjunto de objetos en vivo. Por lo general, el tiempo de pausa de recolección de basura es de aproximadamente 5 ms, y puede pensar que pocos milisegundos no son un gran problema. Pero cada milisegundo cuenta. El dispositivo Android debe actualizar su pantalla cada 16 ms y un tiempo de GC más prolongado podría aumentar el tiempo de procesamiento de fotogramas por encima de la barrera de 16 milisegundos, lo que puede causar un enganche visible.

• También cambiar de aplicación será más lento . El sistema Android puede eliminar procesos en la memoria caché de LRU comenzando con el proceso utilizado menos recientemente, pero también teniendo en cuenta qué procesos requieren más memoria. Por lo tanto, si usa un montón más grande, es más probable que su proceso se cancele cuando esté en segundo plano, lo que significa que puede llevar más tiempo cuando los usuarios desean cambiar de otras aplicaciones a las suyas. 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 mayor memoria. Significa que cambiar de su aplicación a otras aplicaciones también lleva más tiempo.

Conclusión

Evite utilizar la opción largeHeap tanto como sea posible. Puede costarle una caída de rendimiento difícil de notar y una mala experiencia del usuario.

Answer 3

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

Sin embargo, la capacidad de solicitar un montón grande está destinada solo a 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 está asignando toda su memoria y por qué debe conservarse. 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 memoria adicional irá en detrimento de la experiencia general del usuario porque la recolección de basura tomará 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 developer.android.com/training/articles/memory.html

ACTUALIZAR

Después de trabajar de manera insoportable con errores de falta 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í hay algunos consejos para lidiar con out of memory errors falta out of memory errors

1) Use estas devoluciones de llamada que Android da en onLowMemory , onTrimMemory(int) y borre el caché de imágenes como (picasso, glide, fresco ...). Puede leer más sobre ellas here y here
2) comprime tus archivos (imágenes, pdf)
3) lea sobre cómo manejar el mapa de bits de manera más eficiente here
4) Use pelusa regularmente antes de que la producción empuje para asegurarse de que el código sea elegante y no voluminoso

Answer 4

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 usar esta bandera. Si necesita más memoria, Android le proporciona una herramienta para aumentarla. Pero la necesidad de usar, te defines a ti mismo.

Answer 5

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 borre de la memoria cada vez que otras aplicaciones estén en primer plano.

Por "estar preparado", quiero decir que debe diseñar para esa probabilidad, de modo que sus onStop() y onResume() se escriban de la manera más eficiente posible, al tiempo que se garantiza que todo el estado pertinente se guarde y restaure de una manera que presente un Apariencia perfecta para el usuario.

Existen tres métodos relacionados con este parámetro: maxMemory() , getMemoryClass() y getLargeMemoryClass() .

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

Cuando utiliza el parámetro largeHeap , maxMemory() se incrementará a un nivel superior específico del dispositivo, mientras que getMemoryClass() seguirá siendo el mismo.

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

maxMemory() , por el contrario, restringe el tamaño de su montón, por lo que obtiene acceso a un montón adicional al aumentar su valor, y largeHeap aumenta ese valor. Sin embargo, la mayor cantidad de almacenamiento dinámico sigue siendo limitada, y ese límite será específico del dispositivo, lo que significa que la cantidad de almacenamiento dinámico disponible para su aplicación variará, dependiendo de los recursos del dispositivo en el que se ejecuta su aplicación. Por lo tanto, usar largeHeap no es una invitación para que su aplicación abandone todas las precauciones 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 parámetro largeHeap invocando el método getLargeMemoryClass() . El valor devuelto está en megabytes.

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

Detecta 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 solo se ejecuta durante el desarrollo. Agrego el parámetro largeHeap solo durante el desarrollo, para evitar errores de largeHeap de memoria al ejecutar este código. Pero elimino el parámetro (y el código) antes de implementar la aplicación.

Answer 6

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 usen un proceso, todas deben usar esta opción de manera consistente o tendrán resultados impredecibles.

La mayoría de las aplicaciones no deberían necesitar esto y, en cambio, deberían centrarse en reducir el uso general de 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.