Traceview: o que é, ferramenta de rastreamento e criação de perfil Android

O que é Traceview no Android

Traceview é um profileador gráfico integrado ao Android Studio que exibe rastros de execução de métodos de aplicativos Android como uma linha do tempo e uma tabela de chamadas. Faz parte do SDK Android e está disponível através do Android Profiler a partir do Android Studio 3.0, bem como através do utilitário de linha de comando dmtracedump.

Propósito da ferramenta

A principal tarefa do Traceview é ajudar os desenvolvedores a encontrar os métodos que consomem mais tempo de CPU. Ao contrário do registro simples, Traceview registra o tempo exato de entrada e saída de cada método, constrói um Call Chart e uma árvore Top-Down, permitindo a detecção visual de anomalias de desempenho. A ferramenta é especialmente útil ao criar perfil da thread de UI, onde um atraso de 16 ms causa a perda de um quadro.

História e desenvolvimento

Traceview apareceu pela primeira vez nas primeiras versões do SDK Android como um utilitário independente para visualizar arquivos .trace. Com o lançamento do Android Studio 3.0 (2017), tornou-se parte do Android Profiler, ganhando integração com linhas do tempo ao vivo de CPU, memória e rede. De acordo com o Google I/O 2018, a equipe do Android Studio continua desenvolvendo o profileador, adicionando suporte para código nativo através de systrace e perfetto. Nas versões atuais do Android Studio, o Traceview funciona sobre o formato Perfetto, mas mantém compatibilidade retroativa com o formato .trace clássico.

Como o Traceview funciona

Traceview recebe dados do mecanismo System Tracing no Android Runtime (ART). Quando um aplicativo é iniciado com rastreamento ativado, o ART registra os carimbos de data/hora de início e fim de cada método executado, incluindo o nome da classe, nome do método e ID da thread.

// Início da rastreabilidade no código do aplicativo
Debug.startMethodTracing("app_trace")

// Trecho crítico de código para perfilamento
loadHeavyData()

// Parada da rastreabilidade — arquivo salvo no dispositivo
Debug.stopMethodTracing()

System Tracing opera no nível da máquina virtual ART e registra cada chamada de método com precisão de microssegundos. Os dados são gravados em um buffer circular para minimizar o impacto no desempenho do aplicativo. Após a parada do rastreamento, o buffer é liberado para um arquivo .trace no armazenamento interno do dispositivo.

Formato do arquivo .trace

Um arquivo .trace contém um cabeçalho com a versão do formato e a hora de início, seguido por registros para cada chamada: ID da thread, ID do método, carimbo de data/hora de entrada e carimbo de data/hora de saída. O Android Studio carrega automaticamente o arquivo .trace e cria duas visualizações principais: o Painel de linha do tempo para cronologia e o Painel de perfil para hierarquia de chamadas. Por padrão, o tamanho máximo do buffer é de 8 MB, mas pode ser aumentado através de Debug.startMethodTracing(filename, maxSize).

Principais recursos do Traceview

Traceview fornece várias visualizações de dados complementares, cada uma abordando uma tarefa específica na análise de desempenho.

Call Chart (gráfico de chamadas)

Call Chart é uma linha do tempo horizontal onde cada thread é exibida como uma faixa separada. Os métodos são mostrados como retângulos coloridos: a largura do retângulo é proporcional ao tempo de execução e o aninhamento reflete a hierarquia de chamadas. Se um método chama outro método, o retângulo filho é desenhado dentro do retângulo pai. Esta visualização permite a identificação instantânea de operações que bloquearam a thread.

Árvores Top-Down e Bottom-Up

A árvore Top-Down mostra o tempo de execução de um método incluindo todas as suas chamadas aninhadas — Inclusive Time. A árvore Bottom-Up, por outro lado, mostra quais métodos pai chamaram um determinado método — útil para encontrar a origem de uma operação pesada. A diferença entre Inclusive e Exclusive Time é crítica: um método pode executar rapidamente, mas chamar um método filho lento, e isso só é visível no Inclusive Time.

Pesquisa e filtragem

Traceview suporta pesquisa por nome do método, pacote ou classe. Os resultados são destacados na linha do tempo e o Painel de perfil exibe estatísticas apenas para os métodos encontrados. A filtragem por threads também está disponível — você pode ocultar threads em segundo plano e focar na thread principal (UI), onde os atrasos são mais críticos.

Exportação de dados

Traceview permite exportar rastros no formato CSV para análise adicional em planilhas ou gráficos. No Android Studio, você também pode copiar um fragmento selecionado da linha do tempo como imagem — para inserir em relatórios de bugs ou documentação. Para CI/CD, a exportação no formato Perfetto está disponível através do utilitário cmdline-tools.

Como usar o Traceview no Android Studio

A criação de perfil através do Traceview está disponível de duas maneiras: através do Android Profiler com captura ao vivo e através de chamadas programáticas à API Debug. O primeiro método é conveniente para análise ad-hoc, o segundo para testes de desempenho reproduzíveis.

Captura através do Android Profiler

No Android Studio, abra a guia Profiler (View → Tool Windows → Profiler), selecione seu dispositivo e processo do aplicativo. Clique no segmento CPU, depois selecione o modo “Trace Java Methods” e clique em Record. Após interagir com o aplicativo, clique em Stop — Traceview abrirá automaticamente o rastro gravado. A duração padrão da gravação é limitada a 30 segundos, mas o limite pode ser alterado nas configurações do profileador.

Início programático do rastreamento

Para criação de perfil precisa de uma seção específica de código, use Debug.startMethodTracing e Debug.stopMethodTracing. O arquivo é salvo no armazenamento externo do aplicativo no caminho retornado por context.getExternalFilesDir(null). Após a conclusão, transfira o arquivo .trace para seu computador através do Android Studio Device Explorer e abra-o através de File → Open no Android Studio.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

Configuração de parâmetros de rastreamento

Debug.startMethodTracing aceita três parâmetros: o nome do arquivo (sem extensão), o tamanho máximo do buffer (padrão 8 MB) e flags. A flag TRACE_COUNT_ALLOCS adiciona contagem de alocações de objetos — útil para encontrar vazamentos de memória. Traceview não é adequado para criar perfil de código nativo — use SimplePerf ou Perfetto. Para testes longos (mais de 30 segundos), é recomendado aumentar o buffer para 64–128 MB através do parâmetro maxSize.

Lendo a linha do tempo do Traceview

A linha do tempo do Traceview consiste em dois painéis: o Painel de linha do tempo superior com retângulos de chamadas coloridos e o Painel de perfil inferior com uma tabela de estatísticas. O Painel de linha do tempo mostra a execução das threads da esquerda para a direita, onde cada retângulo é uma única chamada de método. As cores dos retângulos são codificadas por tipo de método: chamadas do sistema Android (verde), métodos do aplicativo (azul), chamadas de bibliotecas (laranja).

Como ler o Painel de perfil

No Painel de perfil, cada linha é um método com colunas para Inclusive Time, Exclusive Time, Calls + Recur e CPU Time. Ordene a tabela por Inclusive Time (decrescente) para ver primeiro os métodos que levaram mais tempo total. Se um método com Inclusive Time alto tiver Exclusive Time baixo — o problema está em suas chamadas filhas, e você precisa expandir a árvore. Por exemplo, ListView.getView pode ter Inclusive Time alto devido a chamadas de carregamento de imagem.

Identificação de gargalos

Procure métodos com Real Time anormalmente alto, mas CPU Time baixo — isso indica bloqueio (espera de E/S, operação de rede, contenção de bloqueio). Métodos com CPU Time alto requerem otimização do algoritmo. Para a thread de UI, cada método deve ser concluído em 16 ms — se qualquer chamada exceder esse limite, o aplicativo perde um quadro e o usuário vê instabilidade. De acordo com as recomendações do Google, o tempo total de todas as chamadas na thread de UI por quadro não deve exceder 8–10 ms, deixando uma margem para operações do sistema.

Traceview vs Systrace: comparação de ferramentas

Embora tanto Traceview quanto Systrace sejam ferramentas de rastreamento Android, eles resolvem tarefas diferentes e são usados em diferentes estágios de criação de perfil. A principal diferença é o nível de detalhe: Traceview opera no nível de métodos Java/Kotlin, Systrace no nível de processos do sistema (CPU, GPU, Binder, SurfaceFlinger).

Na prática, ambas as ferramentas se complementam: primeiro Systrace ajuda a identificar qual componente do sistema está causando o problema (por exemplo, GC frequente ou bloqueios Binder), depois Traceview permite aprofundar em um método específico dentro do aplicativo. No Android Studio, ambas as ferramentas estão combinadas no Android Profiler — CPU Profiler seleciona automaticamente o modo de gravação ideal. Em dispositivos com Android 12+, Systrace e Traceview funcionam sobre Perfetto, fornecendo um formato de dados unificado para todos os tipos de criação de perfil.

Exemplos de código com Traceview

A criação de perfil eficaz requer mais do que apenas iniciar o rastreamento — você precisa colocar corretamente os pontos de captura e interpretar os resultados. Abaixo estão dois exemplos práticos: criação de perfil de carregamento do RecyclerView e comparação de dois algoritmos em um teste de desempenho.

Criação de perfil de carregamento do RecyclerView

O primeiro exemplo é o rastreamento do caminho crítico durante a rolagem da lista. RecyclerView chama onBindViewHolder para cada item visível e, se este método levar mais de 16 ms, a rolagem se torna instável. O rastreamento em torno de onBindViewHolder mostrará quais operações específicas dentro dele estão consumindo tempo.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

Comparando dois algoritmos

O segundo exemplo é um teste de velocidade A/B de duas implementações: carregamento de imagens via Glide versus BitmapFactory manual. Este rastro permite comparação objetiva do Inclusive Time de ambas as estratégias e seleção da ideal. É importante executar cada teste em um dispositivo aquecido (após 3–5 ciclos) sob condições idênticas (carga em segundo plano, temperatura).

fun compareImageLoadingStrategies() {
        // Teste A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

        // Teste B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

Após a execução, abra ambos os arquivos .trace no Android Studio e compare o Inclusive Time no Painel de perfil. Se o Glide mostrar 3x menos Inclusive Time para a mesma tarefa — esta é uma base objetiva para escolher a biblioteca. De acordo com Tony John (desenvolvedor do Glide, 2023), a biblioteca usa cache e um pool de threads, proporcionando um ganho de até 40% em carregamentos repetidos.