Instruments — qué es, funcionalidades de Time Profiler y Allocations

¿Qué es Instruments?

Instruments es un sistema de perfilado y trazado incluido en Xcode y basado en la tecnología DTrace desarrollada por Sun Microsystems. Instruments combina docenas de herramientas de perfilado (plantillas) en una única interfaz: simplemente seleccione una plantilla, inicie su aplicación a través de Xcode y comience a recopilar datos.

La arquitectura de Instruments se basa en un modelo cliente-servidor: un agente en el dispositivo recopila datos y los transmite al Mac a través de una conexión USB. Esto minimiza el impacto del perfilador en el rendimiento de la aplicación — Instruments opera principalmente en el lado del host. Según WWDC 2022, la sobrecarga de Time Profiler con una frecuencia de muestreo de 1 ms es inferior al 3%.

Instruments admite plantillas personalizadas — el desarrollador puede combinar varios instrumentos en una sola sesión de perfilado. Por ejemplo, ejecutar simultáneamente Time Profiler + Allocations + Leaks y ver la correlación entre los picos de CPU y las asignaciones de memoria. Esto proporciona una visión holística del rendimiento que no está disponible al analizar cada componente de forma aislada.

Qué plantillas están disponibles por defecto

Xcode incluye 16 plantillas de Instruments preinstaladas: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace y otras. Cada plantilla está optimizada para una tarea específica y preconfigurada con los ajustes correctos de activadores y filtros.

Time Profiler: análisis de rendimiento de CPU

Time Profiler es la plantilla de Instruments más utilizada. Funciona mediante el muestreo de la pila de llamadas: cada 1–10 milisegundos el sistema registra la pila de llamadas de todos los hilos de la aplicación. Después de detener la sesión, Instruments agrega las muestras y muestra qué métodos y funciones consumieron más tiempo. El resultado se presenta como un Call Tree — un árbol de llamadas ordenado por Self Weight.

La métrica clave de Time Profiler es Self Weight (tiempo dedicado directamente al método, excluyendo las llamadas a métodos hijos). Self Weight muestra qué funciones realmente cargan la CPU. Weight (tiempo total con métodos hijos) puede ser engañoso: un método con Weight alto puede simplemente estar llamando a otro método lento mientras él mismo es rápido.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler mostrará que cellForItemAt tiene Self Weight = 40%
    // dentro de él, decodeImage ocupa el 35% — este es el cuello de botella

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — cuello de botella (Self Weight = 35%)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

Al analizar Time Profiler, preste atención a los métodos que se ejecutan en com.apple.main-thread. Si Self Weight en el hilo principal supera el umbral de 16 ms por fotograma, la interfaz de usuario se ralentizará. La solución a estos problemas es mover la decodificación de imágenes, los cálculos de layout y el procesamiento de datos del hilo principal a un hilo de fondo a través de Grand Central Dispatch (GCD).

Cómo leer el Call Tree en Time Profiler

Call Tree es una representación jerárquica de todas las llamadas a métodos, ordenada por Self Weight. El método más pesado en el Call Tree es la primera línea. Al expandir la línea, puede ver qué métodos hijos se llamaron y cuánto tiempo tomaron. Busque métodos donde Self Weight (tiempo propio) supere significativamente a Weight (tiempo total) — estos son signos de bloqueos síncronos y espera.

Allocations: seguimiento de memoria en tiempo real

Allocations es una herramienta para monitorear todas las asignaciones de memoria de una aplicación. Muestra qué objetos, en qué cantidad y con qué tamaño total se crean en cada momento. A diferencia de Memory Profiler en Android Studio, Allocations admite Heapshot — una instantánea de objetos vivos con la capacidad de comparar dos instantáneas.

La interfaz de Allocations consta de dos secciones principales: All Allocations (estadísticas totales por todos los tipos de objetos) y Call Trees (árbol de llamadas desglosado por métodos que crean objetos). Para encontrar fugas, use Heapshot Analysis: tome una instantánea antes de ejecutar un escenario, ejecute el escenario, tome una instantánea después — y compare qué nuevos objetos permanecen en la memoria.

Según Apple Developer Documentation, el patrón de fuga más común detectado a través de Allocations es la creación excesiva de UIView y CALayer durante el desplazamiento de colecciones. Si la cantidad de UIView vivos crece con cada desplazamiento mientras la colección reutiliza celdas — en alguna parte se están creando vistas adicionales sin liberar las antiguas. Allocations muestra la pila de llamadas exacta donde se crean estas vistas.

Heapshot Analysis: comparación de instantáneas de memoria

Heapshot es una instantánea de objetos vivos en Allocations. Tome un Heapshot antes de ejecutar un escenario, ejecute el escenario y tome un segundo Heapshot. La diferencia entre las instantáneas mostrará qué objetos se crearon y no se liberaron. El resultado ideal es el crecimiento solo de objetos temporales (Autorelease pool). Para un análisis preciso, use una combinación de Allocations + Leaks en una sola sesión. Allocations muestra qué objetos no se liberan, y Leaks muestra por qué (qué referencia fuerte los retiene). Ejecute una sesión doble siempre que sospeche una fuga.

Leaks: búsqueda automática de fugas de memoria

Leaks es una herramienta especializada para detectar fugas de memoria en aplicaciones iOS y macOS. A diferencia de Allocations, que simplemente muestra las asignaciones, Leaks escanea activamente el montón en busca de retain cycles — situaciones en las que dos o más objetos se mantienen mutuamente con referencias fuertes.

Leaks funciona junto con Cycles & Roots — un visualizador del grafo de retención de objetos. Cuando se detecta una fuga, Leaks muestra todos los objetos en el ciclo, su retain count y los campos exactos a través de los cuales se pasan las referencias. El desarrollador solo necesita mirar el grafo y entender qué referencia debe cambiarse a weak.

La herramienta resalta automáticamente las fugas con un marcador rojo en la línea de tiempo. Leaks funciona en tiempo real: tan pronto como el sistema detecta una fuga, señala inmediatamente al desarrollador. Esto permite solucionar problemas en el acto sin esperar un volcado y un análisis posterior.

Según WWDC 2022, Leaks puede detectar incluso retain cycles complejos de varios niveles — por ejemplo, cuando tres o más objetos forman una cadena cerrada de referencias fuertes. Para diagnosticar dichos ciclos, el grafo Cycles & Roots es indispensable: muestra claramente cómo los objetos se referencian entre sí en un bucle.

Cómo leer el grafo Cycles & Roots

Cada nodo del grafo es un objeto, cada flecha es una referencia fuerte. Un ciclo es un bucle cerrado de flechas. El color del nodo indica el estado: rojo — objeto con fuga, verde — raíz (GC Root), gris — objeto intermedio. Para corregir una fuga, encuentre una flecha que pueda hacerse weak sin romper la lógica — y cambie el tipo de referencia en el código.

Energy Log: análisis de consumo energético

Energy Log es una plantilla de Instruments para medir el consumo de energía de la aplicación. Recopila datos de los sensores de hardware del dispositivo: carga de CPU, estado de Wi-Fi y radio celular, uso de GPS, pantalla y Bluetooth. Energy Log muestra qué operaciones en la aplicación causan el mayor consumo de batería y las superpone en un gráfico de consumo de energía a lo largo del tiempo.

La herramienta clasifica las operaciones por nivel de consumo: bajo (trabajo normal de CPU), medio (transmisión Wi-Fi), alto (GPS, red celular, GPU). Si Energy Log muestra indicadores rojos de alto nivel durante un período prolongado — la aplicación está agotando la batería en segundo plano y será eliminada por el usuario.

Problemas típicos identificados por Energy Log: WakeLock sin límite de tiempo (la aplicación mantiene la CPU activa después de completar una tarea), Location Updates de alta precisión en segundo plano (solicitudes de coordenadas cada pocos segundos), anomalías de sesión de red (reconexiones frecuentes al servidor). Energy Log recomienda registrar cualquier incidente de este tipo y agregar una condición para deshabilitar la operación de alto consumo.

Para las pruebas de consumo energético, use un dispositivo real con alimentación de batería — las lecturas de consumo en el simulador son incorrectas. Ejecute Energy Log junto con pruebas de UI para automatizar la verificación del consumo de batería en CI.

Cómo ejecutar e interpretar los resultados de Instruments

El lanzamiento de Instruments se realiza desde Xcode de dos maneras: a través del menú Product → Profile (⌘I) o abriendo Instruments como una aplicación separada en Launchpad. El primer método es más conveniente: Xcode compila automáticamente la aplicación en modo de perfilado y la ejecuta en el dispositivo conectado con la plantilla seleccionada. Después de detener la sesión, Instruments guarda el trace en un archivo con extensión .trace.

La interpretación de los resultados depende de la plantilla. Para Time Profiler, mire el Call Tree ordenado por Self Weight — los métodos superiores son sus principales cuellos de botella. Para Allocations — mire # Living después de un escenario cíclico: si la cantidad de objetos aumentó, busque una fuga. Para Leaks — mire los marcadores rojos y el grafo Cycles & Roots. Compare los resultados antes y después de la optimización — esta es la única forma de confirmar la efectividad de los cambios.

// Línea de comandos para Instruments en CI
// Integración de Instruments en el pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Midiendo el tiempo de desplazamiento de la colección
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

En CI, puede ejecutar Instruments desde la línea de comandos usando xcodebuild -showBuildSettings y xcrun xctrace. Esto permite automatizar el perfilado en cada commit y no perder regresiones. Para el análisis, use la comparación con Baseline: si una métrica se degrada en un 5% con respecto al commit anterior, el pipeline debe detenerse.

Errores comunes al trabajar con Instruments: perfilar en el simulador en lugar de un dispositivo (los datos de CPU y GPU son incorrectos), recopilar datos sin un escenario (los resultados son aleatorios), ignorar el Call Tree (mirar solo el gráfico, no los métodos específicos). Corregir estos errores proporciona el 80% de la calidad del perfilado.