Instruments — o que é, recursos do Time Profiler e Allocations

O que é Instruments?

Instruments — é um sistema de perfilamento e rastreamento que faz parte do Xcode e é baseado na tecnologia DTrace, desenvolvida pela Sun Microsystems. O Instruments combina dezenas de ferramentas de perfilamento (modelos) em uma interface unificada: basta selecionar um modelo, iniciar o aplicativo pelo Xcode e começar a coletar dados.

A arquitetura do Instruments é baseada no modelo cliente-servidor: um agente no dispositivo coleta dados e os envia ao Mac via conexão USB. Isso minimiza o impacto do profiler no desempenho do aplicativo — o Instruments opera principalmente no lado do host. De acordo com a WWDC 2022, a sobrecarga do Time Profiler com taxa de amostragem de 1 ms é inferior a 3%.

O Instruments suporta modelos personalizados — o desenvolvedor pode combinar várias ferramentas em uma única sessão de perfilamento. Por exemplo, inicie simultaneamente Time Profiler + Allocations + Leaks e veja a correlação entre picos de CPU e alocações de memória. Isso fornece uma visão holística do desempenho, indisponível na análise isolada de cada componente.

Quais modelos estão disponíveis por padrão

O Xcode vem com 16 modelos pré-instalados do Instruments: Time Profiler, Allocations, Leaks, Energy Log, Network, Core Animation, Metal System Trace, File Activity, System Trace e outros. Cada modelo é otimizado para uma tarefa específica e pré-configurado com as configurações corretas de disparadores e filtros.

Time Profiler: análise de desempenho da CPU

Time Profiler — é o modelo mais usado do Instruments. Ele funciona com base na amostragem da pilha de chamadas: a cada 1-10 milissegundos, o sistema registra a pilha de chamadas de todas as threads do aplicativo. Após interromper a sessão, o Instruments soma as amostras e mostra quais métodos e funções consumiram mais tempo. O resultado é apresentado como uma Call Tree — árvore de chamadas ordenada por Self Weight.

A métrica chave do Time Profiler é o Self Weight (tempo gasto diretamente no método, excluindo chamadas a métodos filhos). É o Self Weight que mostra quais funções realmente estão sobrecarregando o processador. O Weight (tempo total com métodos filhos) pode ser enganoso: um método com Weight alto pode estar apenas chamando outro método lento, sendo ele próprio rápido.

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler mostrará que cellForItemAt tem Self Weight = 40%
    // dentro dele, decodeImage ocupa 35% — este é o gargalo

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

Ao analisar o Time Profiler, preste atenção aos métodos executados na com.apple.main-thread. Se o Self Weight na thread principal exceder o limite de 16 ms por quadro — a UI ficará lenta. A solução para esses problemas é transferir a decodificação de imagens, cálculos de layout e processamento de dados da thread principal para uma thread em segundo plano via Grand Central Dispatch (GCD).

Como ler a Call Tree no Time Profiler

Call Tree — é uma representação hierárquica de todas as chamadas de métodos, ordenada por Self Weight. O método mais pesado na Call Tree é a primeira linha. Expandindo a linha, você vê quais métodos filhos esse método chamou e quanto tempo eles levaram. Procure métodos onde o Self Weight (tempo próprio) excede significativamente o Weight (tempo total) — isso é um sinal de bloqueios síncronos e espera.

Allocations: rastreamento de memória em tempo real

Allocations — é uma ferramenta para monitorar todas as alocações de memória do aplicativo. Ela mostra quais objetos, em que quantidade e com que tamanho total estão sendo criados a cada momento. Ao contrário do Memory Profiler do Android Studio, o Allocations suporta Heapshot — um instantâneo dos objetos vivos com capacidade de comparação entre dois instantâneos.

A interface do Allocations consiste em duas seções principais: All Allocations (estatísticas totais por tipo de objeto) e Call Trees (árvore de chamadas com detalhamento por métodos que criam objetos). Para encontrar vazamentos, use Heapshot Analysis: tire um instantâneo antes de executar um cenário, execute o cenário, tire outro instantâneo depois — e compare quais novos objetos permaneceram na memória.

De acordo com a Apple Developer Documentation, o padrão de vazamento mais comum detectado pelo Allocations é a criação excessiva de UIView e CALayer durante a rolagem de coleções. Se a cada rolagem o número de UIView vivas aumenta, mas a coleção reutiliza células — em algum lugar views adicionais estão sendo criadas sem liberar as antigas. O Allocations mostra a pilha de chamadas exata onde essas views estão sendo criadas.

Heapshot Analysis: comparação de instantâneos de memória

Heapshot — é um instantâneo dos objetos vivos no Allocations. Tire um Heapshot antes de executar o cenário, execute o cenário e tire um segundo Heapshot. A diferença entre os instantâneos mostrará quais objetos foram criados e não liberados. O resultado ideal — aumento apenas de objetos temporários (Autorelease pool). Para análise precisa, use a combinação Allocations + Leaks em uma única sessão. O Allocations mostra quais objetos não estão sendo liberados, e o Leaks — por quê (qual referência forte os está retendo). Inicie uma sessão dupla sempre que suspeitar de um vazamento.

Leaks: busca automática de vazamentos de memória

Leaks — é uma ferramenta especializada para detecção de vazamentos de memória em aplicativos iOS e macOS. Ao contrário do Allocations, que apenas mostra alocações, o Leaks escaneia ativamente o heap em busca de retain cycles — situações em que dois ou mais objetos se seguram mutuamente com referências fortes.

O Leaks trabalha em conjunto com Cycles & Roots — um visualizador do grafo de retenção de objetos. Quando um vazamento é detectado, o Leaks mostra todos os objetos no ciclo, seus retain counts e os campos exatos através dos quais as referências são passadas. O desenvolvedor só precisa olhar o grafo e entender qual referência precisa ser substituída por weak.

A ferramenta destaca automaticamente os vazamentos com um marcador vermelho na linha do tempo. O Leaks funciona em tempo real: assim que o sistema detecta um vazamento, ele sinaliza imediatamente ao desenvolvedor. Isso permite corrigir problemas “no local”, sem esperar por dump e pós-análise.

De acordo com a WWDC 2022, o Leaks é capaz de detectar até mesmo retain cycles complexos de múltiplos níveis — por exemplo, quando três ou mais objetos formam uma cadeia fechada de referências fortes. Para diagnosticar tais ciclos, o grafo Cycles & Roots é indispensável: ele mostra visualmente como os objetos se fecham uns sobre os outros.

Como ler o grafo Cycles & Roots

Cada nó do grafo é um objeto, cada seta é uma referência forte. Um ciclo é um contorno fechado de setas. A cor do nó mostra o status: vermelho — objeto vazado, verde — raiz (GC Root), cinza — objeto intermediário. Para corrigir o vazamento, encontre uma seta que possa ser tornada weak sem quebrar a lógica — e altere o tipo de referência no código.

Energy Log: análise de consumo de energia

Energy Log — é um modelo do Instruments para medir o consumo de energia do aplicativo. Ele coleta dados dos sensores de hardware do dispositivo: carga da CPU, estado do Wi-Fi e rádio celular, uso de GPS, display e Bluetooth. O Energy Log mostra quais operações no aplicativo causam o maior consumo de bateria e as sobrepõe em um gráfico de consumo de energia ao longo do tempo.

A ferramenta classifica as operações por nível de consumo de energia: baixo (operação normal do processador), médio (transmissão Wi-Fi), alto (GPS, rede móvel, GPU). Se o Energy Log mostrar indicadores vermelhos de nível alto por um período prolongado — o aplicativo está descarregando a bateria em segundo plano e será removido pelo usuário.

Problemas típicos identificados pelo Energy Log: WakeLock sem limite de tempo (aplicativo mantém o processador ativo após concluir a tarefa), Location Updates com alta precisão em segundo plano (solicitação de coordenadas a cada poucos segundos), anomalias em sessões de rede (reconexões frequentes ao servidor). O Energy Log recomenda registrar qualquer incidente desse tipo e adicionar uma condição para desligar a operação de alto consumo.

Para testar o consumo de energia, use um dispositivo real com alimentação por bateria — no emulador, os indicadores de consumo de energia são incorretos. Execute o Energy Log junto com testes de UI para automatizar a verificação do consumo de bateria no CI.

Como iniciar e interpretar os resultados do Instruments

A inicialização do Instruments é feita no Xcode de duas maneiras: através do menu Product → Profile (⌘I) ou abrindo o Instruments como um aplicativo separado no Launchpad. O primeiro método é mais conveniente: o Xcode compila automaticamente o aplicativo em modo de perfilamento e o executa no dispositivo conectado com o modelo selecionado. Após interromper a sessão, o Instruments salva o trace em um arquivo com extensão .trace.

A interpretação dos resultados depende do modelo. Para o Time Profiler, observe a Call Tree ordenada por Self Weight — os métodos no topo são seus principais gargalos. Para o Allocations — observe # Living após um cenário cíclico: se o número de objetos aumentou, procure um vazamento. Para o Leaks — observe os marcadores vermelhos e o grafo Cycles & Roots. Compare os resultados antes e depois da otimização — esta é a única maneira de confirmar a eficácia das mudanças.

// Linha de comando para Instruments no CI
// Integração do Instruments no pipeline CI/CD
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // Medindo o tempo de rolagem da coleção
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

No CI, é possível executar o Instruments pela linha de comando através de xcodebuild -showBuildSettings e xcrun xctrace. Isso permite automatizar o perfilamento a cada commit e não perder regressões. Para análise, use comparação com Baseline: se a métrica piorou 5% em relação ao commit anterior — o pipeline deve parar.

Principais erros ao trabalhar com Instruments: perfilamento no simulador em vez do dispositivo (dados de CPU e GPU incorretos), coleta de dados sem cenário (resultados aleatórios), ignorar a Call Tree (olhar apenas o gráfico, não os métodos específicos). Corrigir esses erros proporciona 80% da qualidade do perfilamento.