Uso de memoria de Android AdMob
Estoy confundido acerca de la cantidad de memoria que AdMob SDK parece estar utilizando, y donde esta memoria se encuentra realmente. Dejame explicar.
Tengo dos sabores de mi aplicación: Gratis y Pago. La versión gratuita tiene anuncios de AdMob, de lo contrario, el código es casi el mismo (se utiliza la lib de Android común).
- Fuga de memoria de Android Drawables
- Llamar procrank no funciona en dispositivos reales
- Android Universal Image Loader - ¿Cómo configuro las especificaciones correctamente?
- Supervisar la memoria ocupada por mi aplicación en Android
- Analizar la memoria instantánea hprof archivos de índice programmically
Ejecutar las aplicaciones en mi Nexus 4 (Android 4.2.1) y comparar el uso de la memoria. Veo la memoria del sistema utilizada por la aplicación en la configuración del dispositivo> apps> running. También miro la memoria del montón de Dalvik según lo informado por mensajes del GC logcat, y usando archivos de HPROF.
Cuando ejecuto la versión de pago puedo ver:
- Memoria del sistema: Aproximadamente 16MB
- Tamaño del montón de Dalvik: cerca de 10MB
Cuando ejecuto la versión gratuita puedo ver:
- Memoria del sistema: Aproximadamente 29MB
- Tamaño del montón de Dalvik: cerca de 11MB
En otras palabras, el tamaño del montón de dalvik es similar para ambas versiones. ¡Pero la memoria del sistema actual usada es 10MB + más alta !
Después de haber dedicado tiempo a aprender acerca del perfil de la memoria ( http://www.youtube.com/watch?feature=player_embedded&v=_CruQY55HOk ), y horas mirando archivos HPROF para eliminar cualquier posible fuga, solo puedo ver una sola conclusión:
La memoria adicional del sistema de 10 MB utilizada por AdMob es en realidad la memoria nativa, asignada utilizando malloc, fuera de dalvik heap!
Ahora me estoy preguntando sobre dos cosas:
- Creo que puesto que la memoria de sistema libre de la versión es 10MB más grande que la versión pagada, es mucho más propenso a ser matado por OS en caso de presión de la memoria. ¿O el sistema operativo Android solo tiene en cuenta el montón de Dalvik para decidir qué aplicación matar?
- ¿Existe una manera de ajustar AdMob SDK para seleccionar cuánta memoria se le permite asignar?
Muchas gracias
- El teléfono no puede conectarse a Eclipse en modo de depuración
- Fuga de memoria de Android con final estático
- Problema de seguimiento de heap nativo - la pestaña "Native Heap" está vacía
- ¿Puedo obtener la cantidad de memoria que queda para mi programa?
- Cómo utilizar Eclipse Memory Analyzer Tool (MAT) para analizar un hashmap
- Aumento de la memoria de YouWave
- OnDraw eficiente con mapas de bits y aceleración por hardware
- ¿Hay una manera de recortar una imagen grande en android sin cargar en la memoria?
AdMob utiliza un WebView para cargar anuncios. Es un objeto bastante complejo que hace uso de bibliotecas nativas, y es propenso a bloqueos. El SDK de AdMob se esfuerza bastante por hacerlo manejable, pero en realidad no tiene ningún control sobre cómo funciona. Además, el uso de memoria probablemente varía según el tipo de anuncio: texto HTML vs banners con imágenes, etc.
Por lo tanto, a menos que esté dispuesto a administrar AdMob de forma binaria (no es de código abierto), sólo tiene que vivir con él. Puede eliminar y destruir AdView
de forma proactiva para reducir cualquier pérdida, pero no mucho más que puede hacer.
Después de probar mi aplicación con dos implementaciones diferentes de AdMob encontré que la implementación a través de código java y no XML es más ligera para la aplicación.
Actualización No1:
También puede agregar oyentes personalizados para destruir después de algún tiempo y volver a crear con el fin de manejar aún mejor. Serverside también hay un parámetro que indica al anuncio de la aplicación cuánto debería solicitar un nuevo anuncio, no estoy seguro si existe en todos los casos, pero sí para las cuentas de DFP.
Una buena manera sugerida para implementar el anuncio es que:
new Handler(new Handler.Callback() { @Override public boolean handleMessage(Message msg) { if (!isBeingDestroyed) { final AdRequest adRequest = new AdRequest(); final AdView adView = (AdView) findViewById(R.id.ad); adView.loadAd(adRequest); } }).sendEmptyMessageDelayed(0, 1000);
También no te olvides de llamar a la actividad adView.destroy()
onDestroy () o cuando no quieras más!
La forma anterior se menciona aquí con muchas versiones de memoria útil!
Actualización No2: (mejora en la Actualización No1 )
Una mejora para el manejador sugerido. Usando esa manera usted evita (espero) las devoluciones de llamada del encargado que se pueden apilar cuando intencionalmente una actividad creada / destruida antes de que se envíe el mensaje retrasado. Esto es más probable que ocurra si decide aumentar 1000
milisegundos:
Cree un campo para el controlador:
private adHandler;
En su onCreate
:
adHandler = new Handler(new Handler.Callback() { @Override public boolean handleMessage(Message msg) { if (!isBeingDestroyed) { final AdRequest adRequest = new AdRequest(); final AdView adView = (AdView) findViewById(R.id.ad); adView.loadAd(adRequest); } return false; } }); adHandler.sendEmptyMessageDelayed(0, 1000);
En su onDestroy
no olvide "liberar" al manejador:
adHandler.removeCallbacksAndMessages(null);
Null elimina las devoluciones de llamada ver doc
- El relleno de la barra de estado de CoordinatorLayout desaparece de ViewPager 2ª página
- Matcher Assertions error error opencv Android