Este documento discute varias técnicas para mejorar el rendimiento de las aplicaciones móviles, incluyendo el uso de caché para datos y bitmaps, la ejecución de tareas pesadas fuera del subproceso de interfaz de usuario, mantener la aplicación en memoria, lograr 60 fotogramas por segundo y utilizar herramientas como Systrace y Hierarchy Viewer para perfilar el rendimiento. También enfatiza la importancia de la velocidad de carga y respuesta para la retención de usuarios.

1. Thinking of CPU & Memory
(Code for Responsiveness)

2. La aplicación funciona
Terminado!

3. Por que?
1 de cada 4 personas abandona una web que
tarda más de 4 segundos en cargar

4. Por que?
● Amazon: +100ms = -1% ventas
● Google: un incremento de 0.4 segundos a
0.9 segundos en carga de pàgina equivale a
un descenso de tràfico e ingresos del 20%
● Apps móviles?

5. Cada vez somos más
vagos exigentes

6. El concepto
Caso clásico:
1. Descargas datos
2. Parseas
3. Descargas más datos: imágenes, etc
4. Cargas en memoria
5. Los muestras en pantalla

7. Don't be a Java Hero
"Tengo la impresión de que Java fue diseñado
para hacer que fuera difícil escribir mal código,
mientras que Python está diseñado para hacer
que sea sencillo escribir buen código."
– Magnus Lycka

8. Como?
● Compila contra el último SDK (hardware accel, p.ej)
● Las splash-screens són malignas
● No hacer trabajos en el UI Thread
● No bloquear la UI (ProgressDialogs...)
● GetView "ligeros"
● No descargar los mismos datos 2 veces
○ punto 1 a tratar
● Luchar por los 60fps
○ punto 2 a tratar

9. Velocidad

10. Strict Mode
.penaltyLog()
.penaltyDeath()

11. Red
(Enemigo nº 1)

12. Red (Análisis)
DDMS (Network Statistics)

13. Red (tip 1) - cache de string
12s -> 0.4s (wifi mala, móvil bueno)

14. Red (tip 2) - cache de bitmaps
LruCache+DiskLruCache
● Displaying Bitmaps Efficiently (Android
Developers)
● https://github.
com/koush/UrlImageViewHelper
○ No gestiona bien vistas recicladas (aún)

15. CPU
No todos los móviles son de 4 núcleos

16. CPU (Análisis)
Traceview (code y DDMS)

17. Guardar y leer object
7s -> 0.8s (móvil malo)

18. Mostrar datos
viejos siempre
Ejemplo: Google+
Mal-ejemplo: facebook

19. Memória RAM
Si no compartes, te echan

20. Mantener la aplicación en memoria (Análisis)
$ adb shell procrank

21. Mantener la aplicación en memoria (Tip)

22. Smoothness
Los preciados 60 fps

23. Smoothness
● Sección "robada" de:
○ http://www.curious-creature.org/docs/android-performance-case-study-1.html
○ http://www.curious-creature.org/2012/12/06/android-performance-in-practice/
● Profile GPU rendering (4.1)
● GPU Overdraw (4.2)
● Systrace (4.1)
● Hierarchy Viewer

24. Profile GPU Rendering
● profile first 128 frames of every window
● Activar en dispositivo (dev. options)
● adb shell dumpsys glxinfo com.test.app
● se necesitan <16ms por frame

25. Systrace
● Activar en dispositivo (dev. options)
● tools/systrace/systrace.py (5 seconds by default)

26. GPU OverDraw
● Como recomendación,
podemos pintar cada pixel un
máximo de 3 veces
● 9-patch for backgrounds

27. Hierarchy Viewer

28. Otras utilidades
● Heap dump (memoria por objetos)
● Eclipse MAT (memoria por objetos)
● PerfMon (memoria, cpu, red en float)
● Usage Timelines Pro (cpu, memoria)
● traceview (cpu)

29. Detectar regresiones
● Guardar un long en Application y mostrar un
Toast con la diferencia al mostrar los
primeros datos
● Enviar por analytics velocidades de boot

30. "La optimización prematura es la raíz de
todos los males"
"Donald Knuth"

31. Reférencias
● Google I/O 2012 - Doing More With less: Beign a Good
Android Citizen
● Designing for Performance (developer.android.com)
● "Displaying Bitmaps Efficiently" Android Developers
● http://www.curious-creature.org/docs/android-performance-
case-study-1.html
● http://www.curious-creature.org/2012/12/06/android-
performance-in-practice/
twitter: @oriolj
+Oriol Jiménez