¿El uso de largeheap en Android es una buena práctica?

Estoy desarrollando en NDK . Se cuelga en Galaxy S3 . Para probar puse android:largeheap = "true" en Manifest . Entonces no había ningún problema pendiente. ¿Es una buena práctica usar largeHeap="true" ?

¿Hay alguna posibilidad de que Google rechace mi compilación debido a esta etiqueta y cómo puedo evitar que mi aplicación colgar sin usar largeheap="true" ?

Respuesta corta

No, si lo necesitas no es un mal acicate porque está ahí para ello.

Respuesta larga

Estados oficiales del doc

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.
Sólo se aplica a la primera aplicación cargada en un proceso; Si utiliza un ID de usuario compartido para permitir que varias aplicaciones utilicen un proceso, todos ellos deben utilizar esta opción de forma coherente o tendrán resultados impredecibles.
La mayoría de las aplicaciones no deben necesitar esto y 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, ya que algunos dispositivos están limitados por su memoria total disponible.

Algunos desarrolladores lo utilizan para evitar excepetion OOM, por lo que si lo está utilizando sólo para evitar algunos OOM es un muy mal pactice.

Nunca solicite un montón grande simplemente porque ha quedado sin memoria y necesita una solución rápida . Sólo debe utilizarlo cuando se sabe exactamente dónde se ha asignado toda su memoria y por qué debe conservarse

Si realmente necesita más espacio está bien para usarlo , puede utilizar getMemoryClass() para comprobar el montón y getLargeMemoryClass() montón grande.

Pero si usted puede evitar el uso de la granHeap sería la mejor manera de ir, como la documentación oficial continúa:

Sin embargo, incluso cuando está seguro de que su aplicación puede justificar el montón grande, debe evitar solicitarlo en la medida de lo posible . El uso de la memoria extra será cada vez más 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 la tarea o se realizan otras operaciones comunes.
Además, el tamaño de montón grande no es el mismo en todos los dispositivos y puede ser exactamente el mismo que el tamaño de montón regular . Por lo tanto, incluso si solicita el tamaño de montón grande, debe llamar a getMemoryClass () para comprobar el tamaño de montón regular y tratar de permanecer siempre por debajo de ese límite.

También sugiero que eche un vistazo aquí Administración de la memoria de su aplicación

Personalmente diría que realmente no caen en la categoría de 'buena / mala práctica' cuando se utiliza correctamente .

Según los documentos :

La mayoría de las aplicaciones no deben necesitar esto y 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, ya que algunos dispositivos están limitados por su memoria total disponible.

Si ha hecho todo lo que está a su alcance para reducir el uso de memoria, y todavía lo requiere, entonces no es malo usarlo.

Si su aplicación está colgando, tendrá que dirigirse directamente a eso – la largeHeap no es una varita mágica que hará que los problemas desaparezcan para todos los dispositivos. Este punto queda claro en el siguiente extracto de los documentos de Android Training:

[La] capacidad de solicitar un gran montón se destina sólo a un pequeño conjunto de aplicaciones que pueden justificar la necesidad de consumir más memoria RAM (como una gran aplicación de edición de fotos). Nunca solicite un gran montón simplemente porque se ha quedado sin memoria y necesita una solución rápida, debe usarla sólo cuando sepa exactamente dónde se ha asignado toda su memoria y por qué debe conservarse. – (fuente)

También debo añadir que Google no rechazará su aplicación por usarla.

  • Android NDK UnsatisfiedLinkError - una razón sorprendente
  • Los bytecodes dalvik de anchura extendida que faltan en Jellybean
  • Sustituyendo glReadPixels por EGL_KHR_image_base para una copia de píxeles más rápida
  • Cómo capturar UnsatisifiedLinkError cuando se utiliza biblioteca NDK-construida en una aplicación para Android?
  • Android de vídeo cuadrado y concat
  • Carga de bibliotecas compartidas que dependen de otras librerías compartidas
  • No se encontró ninguna implementación para los nativos
  • No se pueden incluir archivos de encabezado STL con Android NDK r5
  • "Aplicación desconocida ABI:" mientras "depurar como aplicación nativa"
  • reproducir un archivo MP3 android NDK utilizando openSL desde la memoria
  • DSP biblioteca para hacer una aplicación de Android ..?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.