Actualmente estoy teniendo problemas con un comportamiento extraño de la plataforma Android: el límite de memoria de montón de mapa de bits/Java. Dependiendo del dispositivo, Android limita el desarrollador de la aplicación a 16, 24 o 32 MiB de espacio de almacenamiento dinámico de Java (o puede encontrar cualquier valor aleatorio en un teléfono rooteado). Este es sin duda bastante pequeño, pero relativamente sencillo como puedo medir el uso de la API de los siguientes:Límite de mapa de bits de Android - Prevención de java.lang.OutOfMemory
Runtime rt = Runtime.getRuntime();
long javaBytes = rt.totalMemory() - rt.freeMemory();
long javaLimit = rt.maxMemory();
bastante fácil; ahora para el giro. En Android, los mapas de bits, con algunas excepciones, se almacenan en el montón nativo y no cuentan para el montón de Java. Un desarrollador purista y de ojos brillantes en Google decidió que esto era "malo" y le permitió al desarrollador obtener "más de lo que le corresponde". Así que hay una pequeña porción de código que calcula el uso de la memoria nativa en mapas de bits, y posiblemente otros recursos, y suma eso con el montón de Java y si se pasa a ... java.lang.OutOfMemory. ouch
Pero no es gran cosa. Tengo muchos mapas de bits, y no los necesito todos en todo momento. Puedo "localizar" algunos de los que no se están utilizando en este momento:
Por lo tanto, para el intento # 1, refactoré el código para poder ajustar cada carga de mapa de bits con un try/catch:
while(true) {
try {
return BitmapFactory.decodeResource(context.getResources(), android_id, bitmapFactoryOptions);
} catch (java.lang.OutOfMemory e) {
// Do some logging
// Now free some space (the code below is a simplified version of the real thing)
Bitmap victim = selectVictim();
victim.recycle();
System.gc(); // REQUIRED; else, weird behavior ensues
}
}
Sede, aquí hay un buen fragmento pequeño de registro que muestre mi código agarrar la excepción, y el reciclaje de algunos mapas de bits:
E/Epic (23221): OUT_OF_MEMORY (caught java.lang.OutOfMemory) I/Epic (23221): ArchPlatform[android].logStats() - I/Epic (23221): LoadedClassCount=0.00M I/Epic (23221): GlobalAllocSize=0.00M I/Epic (23221): GlobalFreedSize=0.02M I/Epic (23221): GlobalExternalAllocSize=0.00M I/Epic (23221): GlobalExternalFreedSize=0.00M I/Epic (23221): EpicPixels=26.6M (this is 4 * #pixels in all loaded bitmaps) I/Epic (23221): NativeHeapSize=29.4M I/Epic (23221): NativeHeapAllocSize=25.2M I/Epic (23221): ThreadAllocSize=0.00M I/Epic (23221): totalMemory()=9.1M I/Epic (23221): maxMemory()=32.0M I/Epic (23221): freeMemory()=4.4M W/Epic (23221): Recycling bitmap 'game_word_puzzle_11_aniframe_005' I/Epic (23221): BITMAP_RECYCLING: recycled 1 bitmaps worth 1.1M). age=294
Nota cómo totalMemory - FreeMemory es sólo el 4,7 MiB, pero con ~ 26? MiB de memoria nativa tomada por bitmaps, estamos en el rango de 31/32 MiB donde alcanzamos el límite. Todavía estoy un poco confundido aquí ya que mi cuenta corriente de todos los bitmaps cargados es de 26.6 MiB, sin embargo, el tamaño del alloc nativo es de solo 25.2 MiB. Así que estoy contando algo mal. Pero todo está en el estadio de béisbol y definitivamente demuestra la "suma" cruzada que ocurre con el límite de la memoria.
PENSÉ que lo tenía arreglado. Pero no, Android no se rendiría tan fácilmente ...
Esto es lo que recibo de dos de mis cuatro dispositivos de prueba:
I/dalvikvm-heap(17641): Clamp target GC heap from 32.687MB to 32.000MB D/dalvikvm(17641): GC_FOR_MALLOC freed <1K, 41% free 4684K/7815K, external 24443K/24443K, paused 24ms D/dalvikvm(17641): GC_EXTERNAL_ALLOC freed <1K, 41% free 4684K/7815K, external 24443K/24443K, paused 29ms E/dalvikvm-heap(17641): 1111200-byte external allocation too large for this process. E/dalvikvm(17641): Out of memory: Heap Size=7815KB, Allocated=4684KB, Bitmap Size=24443KB, Limit=32768KB E/dalvikvm(17641): Trim info: Footprint=7815KB, Allowed Footprint=7815KB, Trimmed=880KB E/GraphicsJNI(17641): VM won't let us allocate 1111200 bytes I/dalvikvm-heap(17641): Clamp target GC heap from 32.686MB to 32.000MB D/dalvikvm(17641): GC_FOR_MALLOC freed <1K, 41% free 4684K/7815K, external 24443K/24443K, paused 17ms I/DEBUG (1505): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG (1505): Build fingerprint: 'verizon_wwe/htc_mecha/mecha:2.3.4/GRJ22/98797:user/release-keys' I/DEBUG (1505): pid: 17641, tid: 17641 I/DEBUG (1505): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 I/DEBUG (1505): r0 0055dab8 r1 00000000 r2 00000000 r3 0055dadc I/DEBUG (1505): r4 0055dab8 r5 00000000 r6 00000000 r7 00000000 I/DEBUG (1505): r8 000002b7 r9 00000000 10 00000000 fp 00000384 I/DEBUG (1505): ip 0055dab8 sp befdb0c0 lr 00000000 pc ab14f11c cpsr 60000010 I/DEBUG (1505): d0 414000003f800000 d1 2073646565637834 I/DEBUG (1505): d2 4de4b8bc426fb934 d3 42c80000007a1f34 I/DEBUG (1505): d4 00000008004930e0 d5 0000000000000000 I/DEBUG (1505): d6 0000000000000000 d7 4080000080000000 I/DEBUG (1505): d8 0000025843e7c000 d9 c0c0000040c00000 I/DEBUG (1505): d10 40c0000040c00000 d11 0000000000000000 I/DEBUG (1505): d12 0000000000000000 d13 0000000000000000 I/DEBUG (1505): d14 0000000000000000 d15 0000000000000000 I/DEBUG (1505): d16 afd4242840704ab8 d17 0000000000000000 I/DEBUG (1505): d18 0000000000000000 d19 0000000000000000 I/DEBUG (1505): d20 0000000000000000 d21 0000000000000000 I/DEBUG (1505): d22 0000000000000000 d23 0000000000000000 I/DEBUG (1505): d24 0000000000000000 d25 0000000000000000 I/DEBUG (1505): d26 0000000000000000 d27 0000000000000000 I/DEBUG (1505): d28 00ff00ff00ff00ff d29 00ff00ff00ff00ff I/DEBUG (1505): d30 0000000000000000 d31 3fe55167807de022 I/DEBUG (1505): scr 68000012
Eso es un accidente nativa. Un segfault no menos (sig11). Por definición, un segfault es SIEMPRE un error. Esto es absolutamente un error de Android en el manejo del código nativo de GC y/o la comprobación de límites de mem. Pero sigue siendo mi aplicación la que falla, lo que resulta en malas críticas, devoluciones y ventas más bajas.
Así que tengo que calcular el límite yo mismo.
Excepto que he luchado aquí. Traté de sumar los píxeles yo mismo (EpicPixels), pero todavía golpeo el memcrash periódicamente, así que no estoy contando nada. Traté de agregar javaBytes (total - gratis) a NativeHeapAllocSize, pero ocasionalmente causó que mi aplicación se volviera "anoréxica", liberando y liberando bitmaps hasta que no quedaba nada por purgar.
¿Alguien sabe el exacta de cálculo utilizado para calcular el límite de memoria y desencadenar java.lang.OutOfMemory?
¿Alguien más ha solucionado este problema y ha solucionado el problema? ¿Tienes alguna perla de sabiduría?-
¿Alguien sabe qué empleado de Google soñó con este plan para que yo pueda golpearlo por arruinar ~ 40 horas de mi vida? j/k
RESPUESTA: El límite es para NativeHeapAllocSize < MaxMemory(); sin embargo, debido a la fragmentación de la memoria, Android se bloquea mucho antes del límite real. Por lo tanto, debe limitarse a un valor algo menor que el límite real. Este "factor de seguridad" depende de la aplicación, pero unos pocos MiB parecen funcionar para la mayoría de las personas. (¿Puedo decir que estoy impresionado por lo roto que está este comportamiento?)
Esto es muy similar al código que terminé usando. En lugar de devolver verdadero/falso, uso bitmap.recycle() para liberar espacio ... –
Lo intenté ... pero si uso checkBitmapFitsInMemory() devuelve falso y si no uso checkBitmapFitsInMemory() la aplicación carga mapa de bits sin ningún bloqueo. Mis valores registrados: bmpwidth = 93, bmpheight = 131, bmpdensity = 2, reqsize = 24366, heapPad = 4194304, allocNativeHeap = 33150304, maxMemory = 33554432. ¿Alguna idea sobre cómo escribir un método similar, pero que funciona mejor? – Geltrude
Este código no funciona en Honeycomb y más, ya que los mapas de bits ya no se almacenan en el montón nativo. – vomitcuddle