Explicá tu caja de herramientas para perfilar una app Android o iOS que anda lenta

Perfilar arranca por nombrar bien el síntoma, no por abrir una herramienta. "La app anda lenta" en realidad esconde al menos cuatro problemas distintos que viven en subsistemas distintos: frames perdidos al hacer scroll (jank), una pantalla que tarda visiblemente en abrir (latencia de arranque), memoria que sube hasta un OutOfMemoryError (una fuga o hinchazón real), o una función en primer plano que drena batería. Cada uno tiene una herramienta construida específicamente para verlo, y elegir la equivocada primero es lo que más tiempo hace perder, tanto en una entrevista como en debugging real.

En Android, el día a día pasa por la ventana de Profiler de Android Studio (pestañas CPU, Memory, Network, Energy) conectada a un proceso debuggable o, mejor, "profileable". La pestaña CPU ofrece grabación por muestreo (bajo overhead, estadística, ideal para "dónde está la función caliente") frente a instrumentada/tracing (cada entrada y salida de método con timestamp, conteos exactos y timing preciso, pero con mucho más overhead —que puede distorsionar la propia medición, sobre todo en código con muchas allocations). La pestaña Memory permite rastrear allocations en vivo y forzar un heap dump para comparar cantidades de instancias ante una fuga sospechada.

Más allá de la ventana propia del Profiler, Perfetto (que reemplazó a systrace) te da una traza a nivel de todo el sistema: el scheduling en cada core, si tu hilo principal realmente estaba corriendo o solo "runnable" esperando un core, el desglose de Choreographer frame por frame, y las llamadas Binder hacia system_server. Esta es la herramienta para "por qué este frame en particular tardó 40ms", porque muestra todo el sistema durante ese frame, no solo las llamadas a método de tu propio proceso.

Para fugas específicamente, LeakCanary automatiza la misma idea —heap dump más análisis de camino de retención— para que las fugas aparezcan de forma continua en un build de debug en lugar de requerir una sesión deliberada de profiling. Para arranque y jank como métrica con gate de regresión en lugar de una investigación puntual, la librería Macrobenchmark corre StartupTimingMetric y FrameTimingMetric contra un build parecido a release en CI, y los Baseline Profiles son el artefacto que generás a partir de esos mismos benchmarks para acelerar la ejecución del primer arranque.

En iOS, Instruments es el paraguas equivalente: Time Profiler para árboles de llamadas de CPU por muestreo (el análogo directo del muestreo de CPU de Android), Allocations para rastrear cantidades de objetos vivos y análisis de generaciones, el instrumento Leaks —o, más útil en Swift moderno, el Memory Graph Debugger de Xcode para detectar ciclos de retención directamente, ya que las fugas bajo ARC son casi siempre ciclos y no un "me olvidé de liberar"—, Core Animation para FPS y renderizado fuera de pantalla/capas mezcladas (el análogo iOS de cazar jank), el instrumento App Launch para desglosar arranques fríos/tibios, y os_signpost para instrumentar a mano tus propios intervalos y que aparezcan como pistas nombradas junto a las del sistema.

Para telemetría de producción en lugar de una sesión en tu propia máquina, MetricKit es el análogo iOS de los Android vitals de Play Console: agrega hangs, tiempos de lanzamiento, memoria y uso de disco de dispositivos reales en el campo, y los entrega en lotes diarios, sin que nadie tenga que conectar un debugger al teléfono de un usuario.

El matiz que separa una respuesta senior de una junior: perfilá sobre un build parecido a release, no sobre un build de debug. Un APK de debug tiene rutas de bytecode poco amigables con el JIT, sin shrinking de R8/ProGuard, y —si debuggable=true— hooks de instrumentación extra que inflan el tiempo medido; la bandera de manifest android:profileable existe justamente para poder conectar el Profiler a un build configurado como release sin publicarlo. iOS tiene la misma trampa: un build del scheme Debug sin optimizar en Instruments va a mostrar costos de CPU que un build Release/Optimizado simplemente no tiene. Medir sobre la configuración de build equivocada es una de las formas más comunes de "arreglar" un cuello de botella que en realidad nunca existió.