(Code for Responsiveness)

Thinking of CPU & Memory

Terminado!

La aplicación funciona

Por que?

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

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?

Cada vez somos más vagos exigentes

El concepto

Caso clásico:1. Descargas datos2. Parseas3. Descargas más datos: imágenes, etc4. Cargas en memoria5. Los muestras en pantalla

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

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

Velocidad

Strict Mode

.penaltyLog()

.penaltyDeath()

Red(Enemigo nº 1)

DDMS (Network Statistics)

Red (Análisis)

12s -> 0.4s (wifi mala, móvil bueno)

Red (tip 1) - cache de string

LruCache+DiskLruCache

● Displaying Bitmaps Efficiently (Android Developers)

● https://github.com/koush/UrlImageViewHelper○ No gestiona bien vistas recicladas (aún)

Red (tip 2) - cache de bitmaps

CPUNo todos los móviles son de 4 núcleos

Traceview (code y DDMS)

CPU (Análisis)

Guardar y leer object

7s -> 0.8s (móvil malo)

Mostrar datosviejos siempre

Ejemplo: Google+Mal-ejemplo: facebook

Memória RAMSi no compartes, te echan

$ adb shell procrank

Mantener la aplicación en memoria (Análisis)

Mantener la aplicación en memoria (Tip)

SmoothnessLos preciados 60 fps

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

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

Systrace

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

GPU OverDraw

● Como recomendación, podemos pintar cada pixel un máximo de 3 veces

● 9-patch for backgrounds

Hierarchy Viewer

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

Otras utilidades

● Guardar un long en Application y mostrar un Toast con la diferencia al mostrar los primeros datos

● Enviar por analytics velocidades de boot

Detectar regresiones

"Donald Knuth"

"La optimización prematura es la raíz de todos los males"

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