edition - instalar android go en cualquier android

Dos preguntas sobre los tamaños máximos de almacenamiento dinámico y la memoria disponible en Android

Question

Veo que el tamaño del Heap se aumenta automáticamente a medida que la aplicación lo necesita, hasta el tamaño de Heap Max máximo del teléfono. También veo que el tamaño máximo de Heap es diferente según el dispositivo.

Así que mi primera pregunta es, ¿cuáles son los típicos tamaños Max Heap en los dispositivos Android? Probé la asignación de memoria en un teléfono que podía usar un montón de más de 40 MB, mientras que otro daba errores de OutOfMemory en los mbs de los 20. ¿Cuáles son los más bajos que son de uso común y cuáles son los más altos que están en dispositivos comunes? ¿Hay un estándar o promedio?

La segunda pregunta, y la más importante, es cómo asegurarse de que pueda usar los recursos disponibles por dispositivo, pero evite usar demasiado. Sé que hay métodos como onLowMemory () pero parecen ser solo para toda la memoria del sistema, no solo para la aplicación específica.

¿Hay alguna manera de detectar el tamaño máximo de almacenamiento dinámico para el dispositivo y también detectar cuándo la memoria de almacenamiento dinámico disponible está llegando a un punto bajo para su aplicación?

Por ejemplo, si el dispositivo solo permitía un máximo de 24 MB y la aplicación se acercaba a ese límite en la asignación, entonces podría detectar y volver a escalar. Sin embargo, si el dispositivo pudiera manejar más cómodamente, podría aprovechar lo que está disponible.

Gracias

Answer 1

Estos son los tamaños de montón "normales" (ver a continuación) para algunos dispositivos específicos:

• G1: 16 MB
• Moto Droid: 24MB
• Nexus One: 32 MB
• Viewsonic GTab: 32MB
• Paladín Novo7: 60 MB

Digo "normal" porque algunas versiones de Android (p. Ej., CyanogenMod) permitirán a un usuario ajustar manualmente el límite del montón. El resultado puede ser mayor o menor que los valores "normales".

Consulte esta respuesta para obtener información adicional, que incluye cómo averiguar cuál es el tamaño del almacenamiento dinámico programáticamente, y también cómo distinguir entre el límite de tamaño de almacenamiento dinámico absoluto por un lado y el límite de almacenamiento dinámico que idealmente debe respetar, por el otro:

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

Para detectar cuál es su utilización actual del montón, podría intentar usar el método totalMemory () de la clase Runtime. Sin embargo, he leído informes de que diferentes versiones / implementaciones del sistema operativo Android pueden tener diferentes políticas con respecto a si la memoria nativa (a partir de la cual se asigna la memoria de respaldo para mapas de bits) se cuenta contra el máximo del montón o no. Y, desde la versión 3.0, la memoria nativa se toma directamente del propio montón de la aplicación.

La incertidumbre de este cálculo me hace pensar que es un error controlar el uso de memoria de la aplicación en tiempo de ejecución, comparándola constantemente con la cantidad disponible. Además, si se encuentra en medio de un cálculo involucrado y encuentra que se está quedando sin memoria, no siempre es conveniente o razonable cancelar ese cálculo, y puede crear una mala experiencia para los usuarios si lo hace.

En su lugar, puede intentar definir preventivamente ciertos modos, o restricciones, sobre el comportamiento funcional de su aplicación que garantizará que esté dentro de los límites de montón relevantes de su dispositivo actual (como se detectó durante la inicialización de su aplicación).

Por ejemplo, si tiene una aplicación que usa una gran lista de palabras que deben cargarse en la memoria de una sola vez, puede restringir su aplicación para que, para límites de montón más pequeños, solo se pueda cargar una lista más pequeña de las palabras más comunes, mientras que para los límites de montón más grandes se puede cargar una lista completa que contiene muchas más palabras.

También hay técnicas de programación de Java que le permiten declarar que cierta memoria es recuperable por el recolector de basura bajo demanda, incluso si tiene referencias "blandas" (en lugar de duras) existentes. Si tiene datos que le gustaría conservar en la memoria, pero que se pueden volver a cargar desde un almacenamiento no volátil si es necesario (es decir, un caché), puede considerar el uso de referencias suaves para liberar dicha memoria automáticamente cuando su aplicación comienza a chocar contra los límites superiores de tu montón. Consulte esta página para obtener información sobre referencias suaves en Android:

http://developer.android.com/reference/java/lang/ref/SoftReference.html

Answer 2

Los primeros dispositivos tenían un límite de 16 MB por aplicación. Los dispositivos posteriores aumentaron eso a 24 MB. Los dispositivos futuros probablemente tendrán aún más disponible.

El valor es un reflejo de la memoria física disponible en el dispositivo y las propiedades del dispositivo de visualización (porque una pantalla más grande capaz de mostrar más colores generalmente requerirá mapas de bits más grandes).

Editar: reflexiones adicionales ...

Leí un artículo no hace mucho tiempo que señalaba que los asignadores de recolección de basura están esencialmente modelando una máquina con memoria infinita. Puede asignar todo lo que quiera y se ocupará de los detalles. Android funciona principalmente de esta manera; mantiene referencias difíciles a las cosas que necesita, referencias blandas / débiles a cosas que quizás no tenga, y descarta referencias a las cosas que nunca necesitará de nuevo. El GC lo soluciona todo.

En su caso particular, usaría referencias suaves para mantener alrededor de las cosas que no necesita tener en la memoria, pero que le gustaría conservar si hay espacio suficiente.

Esto comienza a desmoronarse con mapas de bits, en gran parte debido a algunas decisiones tempranas de diseño que dieron como resultado el mecanismo de "asignación externa". Además, el mecanismo de referencia suave necesita un poco de ajuste: la versión inicial tendía a mantener todo o descartar todo.

El montón de Dalvik está en desarrollo activo (ver, por ejemplo, las notas en Android 2.3 "Gingerbread", que presenta un GC simultáneo), por lo que esperamos que estos problemas se aborden en una versión futura.

Editar: actualizar ...

El mecanismo de "asignación externa" desapareció en 4.0 (Ice Cream Sandwich). Los datos de píxeles para mapas de bits ahora se almacenan en el montón Dalvik, evitando las molestias anteriores.

Los dispositivos recientes (por ejemplo, el Nexus 4) limitan el tamaño del almacenamiento dinámico a 96 MB o más.

Se puede obtener una sensación general de los límites de memoria de la aplicación como la "clase de memoria", de ActivityManager.getMemoryClass() . Se puede obtener un valor más específico de la función java.lang.Runtime maxMemory() .