2012-02-16 10 views
7

Tengo un bloque de imágenes que quiero cargar en mi pantalla. Todas las imágenes son archivos que descargué y almacené en SD-CARD.Android rápido Mapa de bits cargando

Hasta ahora he encontrado dos formas de hacerlo, primero es cargarlas en el hilo principal, cuando la actividad está comenzando, (obtuve alrededor de 70 imágenes y me toma unos 2.1 segundos cargarlas todas).

Otra forma es lo que estoy probando en este momento. Cargúelos en un hilo separado, por lo tanto, mientras tanto, puedo mostrar la animación de carga para el usuario. Por ahora mi implementación con ThreadPoolExecutor tomó 4.3 segundos. Lo hice en 10 hilos.

Y el último método, (es lo único que no he probado aún) está trabajando con la hoja de sprites.

No puedo usar la memoria caché de la aplicación porque en mi aplicación tengo muchas pantallas y cada pantalla tiene su propio conjunto de imágenes.

¿Qué piensas, cuál es la forma más rápida de cargar grandes cantidades de imágenes y qué técnicas de aceleración conoces que pueden ayudarme?

+0

No ha mencionado el tamaño de las imágenes y si se puede reducir su tamaño cuando usted los carga (p.ej. un JPEG de 5 megapíxeles y cargarlo como una miniatura de 320x240). Si permite esto, puede acelerar en gran medida la carga de imágenes. – BitBank

Respuesta

2

Una opción sería usar crear caché de imágenes usando WeakReference para que la imagen se elimine de la memoria cuando el sistema encuentra una situación de poca memoria. De esta manera puede mantener las imágenes en la memoria y solo necesita cargarlas desde la tarjeta SD cuando no están en la memoria. Por lo tanto, su actividad actual siempre mantendría la referencia precisa del mapa de bits requerido y la memoria caché de imágenes mantendría la referencia débil al mapa de bits.

A continuación se presenta algo más de información acerca débil referencia:

JavaDoc weakReference

StackOverflow post discussing using weak reference for cache

+1

-1: este enfoque es prácticamente inútil en todos los dispositivos sdk de 9 en adelante, ya que el recolector de basura es tan agresivo que casi instantáneamente elimina todas las referencias débiles, el enfoque actual recomendado es LRU Cache (ver http://developer.android.com/training /displaying-bitmaps/cache-bitmap.html) – for3st

8
  1. No cargar en el hilo principal. Con un retraso de 2.1 segundos, estás a punto de morir con un error ANR (aplicación que no responde) si bloqueas el hilo principal.

  2. Carga en hilo separado. No cree 10 hilos, sino uno AsyncTask, y cargue todas sus imágenes una tras otra en doInBackground.

    La carga en AsyncTask debería tomar (casi) la misma vez que la carga en el hilo principal. No coloque demasiadas animaciones sofisticadas, de modo que el hilo principal no consuma demasiado tiempo de CPU.

0

Una forma de hacer esto será implementar un tipo de oyente/observador.

Desde su subproceso de interfaz de usuario, inicie otro subproceso que cargue la imagen. Una vez que se carga la imagen, el hilo invocará un método de devolución de llamada implementado en la clase de actividad para actualizar la vista de imagen correspondiente.

En lugar de la tarea asynch de android, buscaré mis hilos (agrupados/ejecutores). Obtendré todas las posibles rutas de imagen antes de cargarlas, y las enviaré a la subasta para cargar la imagen. Y en la devolución de llamada sé dónde actualizar la imagen.

También puede comprobar cómo funciona el cargador en su caso.

0

Claramente, no debe dejar una operación de 2 segundos en el hilo de la interfaz de usuario.

Supongo que el ThreadPoolExecutor es una buena solución, pero no es óptimo crear muchos subprocesos en su grupo. En el hilo de fondo es suficiente. Apuesto a que obtendrás un mejor rendimiento simplemente cambiando esto.

No recomiendo AsyncTask directamente de la actividad, porque it is fragile to config change.

No recomiendo trabajar con sprites. Aumentar el tamaño de una imagen es muy peligroso en un dispositivo móvil donde la memoria es limitada. En particular con los sprites, tendrás que obtener partes del Bitmap, por lo tanto, tienes el mapa de bits completo en la memoria por un momento.

Ahora que he hecho un voto unánime sobre sus preguntas específicas, creo que pasa por Lazy loading of images in a listview porque el problema es muy similar.

Cuestiones relacionadas