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).

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:

  1. 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?
  2. ¿Existe una manera de ajustar AdMob SDK para seleccionar cuánta memoria se le permite asignar?

Muchas gracias

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

  • Apertura de la cámara en un proceso diferente
  • ¿Las referencias de fuga de Butterknife después de la actividad terminada?
  • Beneficios de GSON sobre el análisis normal de JSON
  • Encontrar el mecanismo de caché de memoria "asesino" para Android
  • Android: ¿Cómo probar la pérdida de memoria en una aplicación?
  • Callback de Android: ¿es una posible pérdida de memoria?
  • Excepción de objetos muertos de Android
  • Fugas de contexto de Android en AsyncTask
  • Tipos de memoria de Android (RAM v Memoria interna)
  • Fuga de memoria AsyncTask
  • Inicializaciones repetidas de actividad y uso de memoria
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.