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).
- Cómo utilizar Eclipse Memory Analyzer Tool (MAT) para analizar un hashmap
- Callback de Android: ¿es una posible pérdida de memoria?
- Uso de finales estáticas en la actividad de Android
- ¿Cómo puedo crear Libgdx.so desde el origen para Android con el rastreo gdb habilitado?
- DDMS y OS muestran información de memoria diferente sobre mi aplicación
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
- Android: LibGDX 2D consumo de memoria del juego
- ¿Los oyentes crean fugas de memoria si no se eliminan de una actividad destruida?
- Enum de tamaño de byte en Java
- Obtenga memoria de proceso libre en android
- Xamarin android consumo de memoria crece infinitamente después de que el uso alcanza un cierto umbral
- DialogFragment pérdida de memoria
- Consulta sobre "dumpsys meminfo" en android
- El objeto de conexión de SQLite se filtró - Android
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