Rendimiento en apps móviles

El cold start es el tiempo que pasa desde que el usuario toca el icono de la app hasta que la primera pantalla es interactiva. Apple recomienda que sea inferior a 400ms y penaliza apps que exceden 20 segundos con un kill automático. Google mide el TTID (Time To Initial Display) y el TTFD (Time To Full Display) como métricas oficiales.

Las causas más comunes de cold start lento son: inicialización de SDKs pesados en el thread principal, carga de datos remotos bloqueante, splash screens que ocultan carga real, y dependencias que se resuelven síncronamente. La solución pasa por diferir la inicialización de servicios no críticos, pre-cachear datos esenciales y usar lazy loading.

Los dispositivos móviles tienen memoria limitada. Cuando una app consume demasiada RAM, el sistema operativo la mata para liberar recursos (OOM kill). Esto resulta en crashes inesperados, especialmente en dispositivos de gama baja que representan la mayoría del mercado global.

Los memory leaks son el problema más insidioso: objetos que deberían ser liberados pero mantienen referencias fuertes que impiden al garbage collector reclamarlos. En iOS, los retain cycles (referencias circulares entre objetos) son la causa más frecuente. En Android, las Activities que se retienen después de onDestroy por listeners o callbacks no eliminados.

El consumo excesivo de batería es una de las principales razones de desinstalación. Los mayores consumidores son: GPS continuo, polling frecuente a servidores, animaciones constantes, wake locks innecesarios y procesamiento en background no optimizado.

Para reducir el impacto en batería, usa location services solo cuando sean necesarios (y con la precisión mínima requerida), reemplaza polling por push notifications o WebSockets, agrupa las peticiones de red para aprovechar la radio del móvil cuando ya está activa, y respeta los modos de ahorro de batería del sistema.

Las conexiones móviles son inestables, con latencia variable y ancho de banda limitado. Una app bien diseñada debe funcionar razonablemente bien en 3G (o incluso offline) y aprovechar al máximo las conexiones rápidas cuando están disponibles.

Las técnicas clave son: caché HTTP agresiva con ETags, compresión de payloads (gzip/brotli), paginación de listas, carga progresiva de imágenes (thumbnails primero, resolución completa después), y request deduplication para evitar peticiones duplicadas cuando el usuario navega rápido.

El estándar mínimo de fluidez es 60 fps (16.6ms por frame). Los dispositivos con pantalla de alta frecuencia (ProMotion, 120Hz) requieren 8.3ms por frame. Cualquier operación que bloquee el thread principal durante más tiempo causa jank: frames perdidos que el usuario percibe como lentitud o "lag".

Las causas más comunes de jank son: layout recalculations complejos, renderizado de sombras y gradientes sin caché, overdraw (pintar píxeles que se sobreescriben inmediatamente), y operaciones de I/O en el thread principal. La regla de oro: el thread principal solo debe encargarse del renderizado; todo lo demás va a threads secundarios.

El profiling es imprescindible para optimizar con datos, no con intuición. Cada plataforma ofrece herramientas potentes: Xcode Instruments (iOS) permite analizar CPU, memoria, energía, red y renderizado frame a frame. Android Studio Profiler cubre CPU, memoria, red y energía con visualización en tiempo real.

Para monitorización en producción, Firebase Performance Monitoring rastrea tiempos de inicio, traces personalizados y peticiones HTTP lentas. Sentry y Datadog ofrecen monitorización de crashes y performance con alertas configurables. Lo fundamental es medir en dispositivos reales, no solo en el simulador.

La optimización de rendimiento no es un evento único sino un proceso continuo. Establece un performance budget (tiempos máximos aceptables para inicio, transiciones, respuesta de red) y mídelo en CI/CD con tests automatizados. Herramientas como Maestro y Detox permiten medir tiempos de renderizado en pipelines de integración continua.

Prioriza las optimizaciones por impacto en usuario: un segundo menos en cold start tiene más impacto que ahorrar 5MB de RAM en un dispositivo de gama alta. Testea siempre en dispositivos de gama baja (los que usan tus usuarios reales), no solo en el último iPhone o Pixel.