Esteban Etayo

Mas info: http://www.research2guidance.com/

Este post quiza sea demasiado especifico para crear con él una nueva entrada, pero creo sinceramente que se lo merece. Este problema, o excepcion que saltaba en uno de mis juegos, me ha quitado varias decenas de horas de mi vida, así que espero poder evitar este perdida a muchos de vosotros.

Explicacion del problema:

Esta exception salta, cuando se cargan demasidas imagenes dentro de una aplicacion android. El limite medio de una aplicacion esta entre 16Mb y 24Mb dependiendo del dispositivo. Cuando se soprepasa el limite la maquina dalvik fuerza el cierre de la aplicacion y en el logCat obtenemos algo parecido a esto:

11-12 18:15:01.932: D/dalvikvm(411): GC_FOR_MALLOC freed 4K, 50% free 3523K/6919K, external 16605K/17130K, paused 70ms
11-12 18:15:01.962: D/skia(411): --- decoder->decode returned false
11-12 18:15:01.972: D/AndroidRuntime(411): Shutting down VM
11-12 18:15:01.972: W/dalvikvm(411): threadid=1: thread exiting with uncaught exception (group=0x40015560)
11-12 18:15:02.042: E/AndroidRuntime(411): FATAL EXCEPTION: main
11-12 18:15:02.042: E/AndroidRuntime(411): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
11-12 18:15:02.042: E/AndroidRuntime(411): 	at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
11-12 18:15:02.042: E/AndroidRuntime(411): 	at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:470)

En este caso podemos apreciar que cuando la memoria externa ha llegado a 17Mb es cuando el sistema se viene abajo. Te recomiendo que leas mi post sobre gestion de memoria para que entiedas los mensajes. Normalmente es un fallo que salta en aplicaciones con alta carga en imágenes.

Tras probar con cientos de soluciones que he encontrado en la web, llege a la conclusion que ninguna por si sola resolvia mi problema, asi que optimice al maximo mi aplicacion e hice un remix de todas ellas. Asi se soluciono el problema

Solución del problema:

1) En el método onDestroy de cada Activity, es necesirio liberar todos los elementos que se estan utilizando en el sistema. He aqui un ejemplo:

 @Override
protected void onDestroy() {
	    super.onDestroy();
	    this.liberarMemoria();
}
public void liberarMemoria(){
     imagenes.recycleBitmaps();  // <-- esta llamada la voy a explicar a continuación
     this.unbindDrawables(.....vista que deseamos eliminar......);
      //Cerrar cualquier tipo de conexion, webservices, bd, etc...
      //asignar todos los elementos que usamos a NULL
}
 private void unbindDrawables(View view) {
		    if (view.getBackground() != null) {
		        view.getBackground().setCallback(null);
		    }
		    if (view instanceof ViewGroup) {
		        for (int i = 0; i < ((ViewGroup) view).getChildCount(); i++) {
		            unbindDrawables(((ViewGroup) view).getChildAt(i));
		        }
		        ((ViewGroup) view).removeAllViews();
		    }
}

2) El segundo paso es eliminar todas las asignaciones a imágenes como R.drawable.nombreImagen y crearnos un gestor propio de imágenes. Android tiene un bug desde su nacimiento y no gestiona de manera optima las imágenes, en la mayoría de las aplicaciones no hay problema, pero en algunos casos hay que replantearnos la utilización de su gestor.

a) Trasladar todas las imagenes desde la carpeta “\res\drawable-hdpi” a una carpeta que crearemos dentro de assets, tal como “\assets\drawable”

b) Copia esta clase en tu proyecto

import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;
import java.lang.ref.WeakReference;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;

import android.content.Context;
import android.content.res.AssetManager;
import android.graphics.Bitmap;
import android.graphics.BitmapFactory;
import android.graphics.drawable.BitmapDrawable;
import android.graphics.drawable.Drawable;

public class Imagenes {

	  private HashMap> mBitmaps;

          public WeakReference getAssetImage(Context context, String filename){
		//WeakReference tempbitmap = new WeakReference(BitmapFactory.decodeStream(inputStream));
		InputStream is=null;
		AssetManager assets;
		WeakReference bitmap=null;
		try{
			if(mBitmaps==null)mBitmaps=new HashMap>();
			assets = context.getResources().getAssets();
		    is = new BufferedInputStream((assets.open("drawable/" + filename + ".png")));
		    bitmap = new WeakReference(BitmapFactory.decodeStream(is));
		    mBitmaps.put(filename,bitmap);
			is.close();
			WeakReference tempDW = new WeakReference(new BitmapDrawable(bitmap.get()));
		    return tempDW;
		}catch(Exception e){
			e.printStackTrace();
		}finally{
			is = null;
			bitmap=null;
		}
		return null;
	}

	public void recycleBitmaps() {
		Iterator itr = mBitmaps.entrySet().iterator();
        while (itr.hasNext()) {
            Map.Entry e = (Map.Entry)itr.next();
            System.out.println("Eliminar:"+e.getKey());
            if(((Bitmap) mBitmaps.get(e.getKey()).get())!=null){
            	((Bitmap) mBitmaps.get(e.getKey()).get()).recycle();
            }
        }
        mBitmaps.clear();
    }

}

c) Cambia todas las llamadas a una imagen

Antes: R.drawable.nombreImagen;

Ahora: Imagenes.getAssetImage(mContext.getApplicationContext(), “nombreImagen”).get();

d) Crea una instancia de Imagenes en cada onCreate de cada Activity

public Imagenes imagenes;
@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		imagenes = new Imagenes(true);

e) La siguiente linea en el AndroidManifest de cada Actividad, mejorara el rendimiento

android:configChanges="orientation|keyboardHidden|navigation"

f) por ultimo optimiza, optimiza y vuelva a optimizar tu codigo

Destacar que bajo mi punto de vista la clave de la solucion es en crear un gestor propio de imagenes que utilice WeakReference

En la mayoría de aplicaciones Android no es necesario tener excesivo cuidado con la gestión de memoria, el GC(Garbage Collector) se encarga por nosotros de ir eliminando todos los elementos que han muerto en la aplicación. Esto no ocurre en otros lenguajes por ejemplo cuando se desarrolla una aplicación en iOS, donde eres el desarrollador el encargado de gestionar la memoria de cada elmento, reservando su espacio y liberandolo cuando ya no sea necesario.

¿Que es el GC(Garbage Collector)?

Es un sistema que automatiza la gestión de la memoria. Reservando cuando es necesaria, eliminando cuando ya no se usa, compactando cuando es mejor agruparla. La maquina dalvik de Android implementa un GC mas sencillo que el de java pero que es muy util.

Entonces ¿Que problema existe?

La manera en que trabaja Android, tiene parte buena y parte mala. La automatización de la gestión de memoria, hace que cuando te encuentras con un problema de desbordamiento o fuga de la pila de memoria, su solucion no es facil. Cuando estas desarrollando un juego o una aplicacion que requiere cargar en memoria muchas imagenes o un procesado de computacion alto, tienes que tener muchisimo cuidado, al menor despiste te encuentras con problemas. Yo ahora mismo estoy intentado resolver, en uno de mis juegos, un fallo “java.lang.OutOfMemoryError: bitmap size exceeds VM budget”.

Si me encuentro con un OutOfMemoryError, ¿Que puedo hacer?

1) Aprende a leer los mensajes del GC: Es muy importante conocer como esta funcionando el GC y que representa cada mensaje. Hay 5 tipos de mensajes:
– GC_CONCURRENT: Se activa cuando es necesario liberar memoria. De esta manera, se libera memoria antes de que haya una necesidad real, evitando hacer una pausa y llamar a la GC.
– GC_FOR_MALLOC: Significa que el GC fue disparado porque no habia suficiente memoria en la pila para realizar una asignacion. Puede ser activado cuando nuevos objetos estando siendo creados. Se activa cuando la pila está llena y tenemos que parar y esperar a que el GC para liberar memoria.
– GC_EXTERNAL_ALLOC: Significa que la VM esta intentando reducir el monton de memoria utilizado por coleciones de objetos, para hacer espacio para objetos que no son de colección como Bitpmap o buffers NIO.
– GC_HPROF_DUMP_HEAP: Si recoges la pila para examinarla
– GC_EXPLICIT: Cuando realizas una llamada explicita a “System.gc()”

Ahora que sabemos los tipos de mensajes, vamos a interpretar uno de ellos. Supongamos que en el LogCat hemos Obtenido:
D/dalvikm (9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703/5261, paused 2ms+2ms

Explicación: Acaba de liberarse 2049K, esta libre el 65% de memoria. Lo siguiente refiere a la memoria externa, el primer numero(3571) es el total de memoria externa que la aplicacion tiene alojada(imagenes y buffers NIO), el segundo número es una especie de límite flexible, que va aumentando segun las necesidades, hasta un punto limite segun la memoria de cada dispositivo. Finalmente el tiempo que ha consumido el GC en sus tareas.

2) Aprende a descargar el fichero hprof desde las herramientas DDMS, conviertelo a un formato valido y aprende a utilizar Eclipse Memory Analyzer

Yo estoy en proceso de aprendizaje con esta poderosa herramienta, asi que de ella tampoco podre aprotar demasiado, pero si como llegar hasta ella.
En primer lugar lanzamos la aplicacion Android en modo “debug” y nos vamos a la vista DDMS. Probamos la aplicación por sus diferentes partes, hasta que obtenemos un fallo o no necesariamente. Ahí seleccionamos en la pestaña “Devices” el proceso sobre el que corre nuestra aplicación y pulsamos el botón que podéis ver en la siguiente captura.

Guardamos el fichero que nos genera, con el nombre “dump.hprof” .Tras ello, tenemos que convertir el fichero que hemos guardado en otro formato, vamos con un terminal a donde tenemos el sdk de android y luego a la carpeta tools y hacemos lo siguiente:

$ hprof-conv dump.hprof dump-conv.hprof

Ya podemos abrir ese fichero generado (dump-conv.hprof) con MAT(Eclipse MemoryAnalyzer)

Si quieres aprender a dar tus primeos pasos en Eclipse MemoryAnalyzer y conocer mas cosas sobre la gestion de memoria en Android, te recomiendo que veas esta ponencia de unos de los ingenieros de google celebrada a mediados de 2011.

Espero postearos pronto nuevos trucos sobre la gestión de memoria en Android!

3) Estilos independientes dentro de un TextView: Hay momentos en los que se desea dar formatos diferentes a un secciones de un textview

TextView tv = new TextView(this);
SpannableString s = new SpannableString("Hello there world");
CharacterStyle mark = new StyleSpan(Typeface.BOLD);
s.setSpan(mark, 1, 2, Spannable.SPAN_EXCLUSIVE_EXCLUSIVE);
tv.setText(ssb);

4) Pasar de una actividad a otra de manera elegante, utilizando un efecto tipo Alpha (Transparencia): sino utilizas ningun efecto te daras de cuenta que al pasar de una actividad a la siguiente no tiene un efecto de continuidad y es demasiado rompedor. Te propongo una solucion:
Crear dos ficheros dentro de la carpeta res/anim
fichero1: fadein.xml

<?xml version=”1.0″ encoding=”utf-8″?><alpha xmlns:android=”http://schemas.android.com/apk/res/android”   android:interpolator=”@android:anim/accelerate_interpolator”   android:fromAlpha=”0.0″ android:toAlpha=”1.0″ android:duration=”1000″ />

fichero2: fadeout.xml

<?xml version=”1.0″ encoding=”utf-8″?><alpha xmlns:android=”http://schemas.android.com/apk/res/android”   android:interpolator=”@android:anim/accelerate_interpolator”   android:fromAlpha=”1.0″ android:toAlpha=”0.0″ android:duration=”1000″ />

En la Actividad A, hacemos la llamada de manera normal:

Intent i = new Intent(ActividadA.this,ActividadB.class);
startActivity(i);						
finish();

En la Actividad B, en el metodo OnCreate:

@Override
public void onCreate(Bundle savedInstanceState) {
// Transacion entre dos actividades
super.onCreate(savedInstanceState);
overridePendingTransition(R.anim.fadein, R.anim.fadeout);
setContentView(R.layout.vista1);
}

Así habremos logrado el objetivo de pasar entre ambas actividades de manera continua.

La verdad que nunca pensé que escribiría esto, pero Google Maps me esta haciendo que pensar. Ha sido la herramienta en la cual me he apoyado siempre que quería buscar información de una ubicación, la herramienta que he utilizado para desarrollar algun producto, era la única herramienta que me convencía… lo demas eran burdas y regulares imitaciones.

Hace dias llegue a una noticia que me sorprendió: La API de Google Maps dejara de ser gratuita

De ahi que empezo a rondar en mi cabeza la siguiente duda: ¿Hay que usar la API de Google Maps para futuros proyectos? ¿Merece la pena? Yo de momento sigo pensado que sigue siendo la mejor herramienta pero ¿lo seguirá siendo o habrá alguna que le adelante?

Tras varias investigaciones llegue a la conclusión de que si alguien le esta haciendo frente es OpenStreetMap que segun la wikipedia es “Un proyecto colaborativo para crear mapas libres y editables. Los mapas se crean utilizando información geográfica capturada con dispositivos GPS móviles, ortofotografías y otras fuentes libres. Esta cartografía, tanto las imágenes creadas como los datos vectoriales almacenados en su base de datos, se distribuye bajo licencia Creative Commons Attribution-ShareAlike 2.0.” En cristino es algo muy parecido a la wikipedia pero de mapas. Tienes el poder de editar, personalizar y utilizar by the face.

Hay un movimiento muy fuerte que se esta produciendo en españa con esta nueva tecnologia, podeis seguir sus pasos en esta interesante Web

¿Porque no utilizar Google Map?
– Prohibido el uso comercial
– Solo para uso personal
– No redistribuible
– Solo a través de su API
– Prohibido descargar
– Prohibido modificar
– Prohibido navegar
– !Prohibido mejorar¡
– ¡Prohibido ser creativo!

¿Porque Utilizar OpenStreetMap?
– Usalo como quieras, incluso comercialmente
– Usalo donde quieras
– Es Gratis
– Contribuye
– Mejora
– Sé Creativo

Ejemplos de uso:

• Mapas para ciclistas
• Personalización extrema
• Mapas en papel: impreso / Mapapel
• 3D: Marble / OSM2World
• Ruteo: OSRM / YOURS / Cloudmade
• Navegación: Navit
• Dispositivos móviles: Android, iOS
• Mapas temáticos: OpenPisteMap / OpenSeaMap / Transporte público

¿Como puedo contribuir a esta iniciativa?
– Usando y difundiendo su uso
– Avisando de errores: OpenStreetBugs
– Pidiendo a las instituciones la liberacion de sus datos: OpenData
– Editando directamente el mapa tu mismo ¡Es facil y divertido!

Si os ha interesado toda esta informacion, os recomiendo estos links:
http://www.openstreetmap.es/
http://www.openstreetmap.es/wp-content/uploads/osmdeusto2011/introduccion/#slide40