Todo iPhone carrega uma "caixa-preta" chamada sysdiagnose — um arquivo de diagnóstico do sistema que os engenheiros da Apple procuram primeiro quando algo dá errado. Pressione os dois botões de volume e o botão lateral por cerca de um segundo, e o iOS registra um silenciosamente em segundo plano. Mesmo compactado, ele ainda possui centenas de megabytes, repleto de ioreg, smcDiagnose, taskinfo, relatórios de falhas e dados de química da bateria.

O problema: isso nunca foi feito para você. Descompactado, são milhares de arquivos e dezenas de milhares de linhas de texto puro. O valor que você procura está enterrado na linha 10.000 de IODeviceTree.txt ou dentro de algum nó do controlador NVMe em IOService.txt. Até mesmo um desenvolvedor experiente precisa de dez minutos apenas para encontrá-lo.

O Device Status⁺ transforma essa parede de texto em uma tela de cartões legíveis — inteiramente no próprio dispositivo, sem fazer o upload de um único byte. Este guia percorre como funciona o seu Diagnostic Log Analyzer, desde a captura de um sysdiagnose até a leitura dos cartões, e por que ele não fará o seu telefone travar no processo.

O que é o Device Status⁺?

O Device Status⁺ é um aplicativo gratuito de monitoramento do sistema feito pela Space-Time Transformation Technology Co., Ltd. Ele requer o iOS 17.0+ e é executado no iPhone, iPad, Mac (série M), Apple Vision Pro e Apple Watch. Juntamente com os painéis em tempo real de CPU, memória, armazenamento, bateria e rede, ele traz um Diagnostic Log Analyzer dedicado para arquivos sysdiagnose e um Battery Log Analyzer para análises diárias de bateria (coberto em um guia separado).

Tudo o que é descrito abaixo acontece localmente. A tela de importação afirma claramente: "Todo o processamento ocorre no dispositivo. Nada é carregado."

O que exatamente é um sysdiagnose?

Um sysdiagnose é um instantâneo de todo o sistema em um momento específico. Acionado pela combinação de botões de hardware, ele coleta:

• Descarregamentos (dumps) da árvore de dispositivos do ioreg (IODeviceTree.txt, IOService.txt)
• Leituras do SMC (System Management Controller / Controlador de Gerenciamento do Sistema) e smcDiagnose
• Instantâneos de processos do taskinfo
• Relatórios de falhas agregados (.ips)
• Arquivos .plist de química da bateria e instantâneos de desgaste da NAND
• Estado da rede, Wi-Fi e Bluetooth

O resultado é um sysdiagnose_YYYY.MM.DD-...tar.gz que, quando extraído, pode conter mais de 2.400 entradas com cabeçalhos estendidos PAX. Em um iPhone com restrição de memória, a abordagem óbvia — "ler tudo na memória e depois descompactar" — falha com um erro de OOM (Out of Memory). É por isso que o analisador não faz isso.

Passo 1: Capturar o sysdiagnose

A parte mais difícil não é a análise. É conseguir o arquivo. O Device Status⁺ traz um guia ilustrado (LogCollectionGuideView) que o orienta a cada toque:

1. Pressione e segure os dois botões de volume + o botão lateral por cerca de um segundo, solte após a vibração tátil — isso aciona o sysdiagnose.
2. Continue usando o telefone normalmente e espere cerca de 10 minutos para a coleta terminar.
3. Abra Ajustes → Privacidade e Segurança → Análises e Melhorias → Dados de Análise e procure por sysdiagnose.
4. Abra o arquivo → Compartilhar → Salvar nos Arquivos → de volta no Device Status⁺, toque em + para importar.

Para reduzir a etapa de "encontrar a entrada" a nada, o guia oferece dois atalhos de um toque: instalar um Atalho (link do iCloud) e ir direto para o painel Análises e Melhorias por meio de um esquema de Atalhos.

Passo 2: Importar sem travar a memória

É aqui que o trabalho de engenharia mostra seu valor. O SysdiagnoseArchiveExtractor executa um pipeline de streaming em dois estágios que processa um arquivo de 800 MB com apenas alguns quilobytes de memória de buffer.

Estágio 1 — gunzip. Usando zlib com inflateInit2(16 + MAX_WBITS) para decodificação com suporte a gzip, o arquivo de entrada é mapeado em memória via mmap (carregado por demanda, nunca residente) e a saída é gravada em um arquivo .tar temporário em blocos de 64 KB. O pico de memória é apenas o buffer.

Estágio 2 — untar. Uma máquina de estados escrita à mão analisa os cabeçalhos USTAR / GNU / PAX entrada por entrada e grava cada uma no disco. Ela suporta nomes de arquivos longos no padrão GNU (o tipo L), cabeçalhos estendidos PAX por entrada e globais (x / g) e campos de tamanho base-256. O arquivo completo nunca é mantido inteiramente na memória.

Os detalhes de robustez importam tanto quanto:

• Verificação prévia de espaço em disco. Após o gunzip, quando o tamanho exato do .tar é conhecido, o analisador verifica o volumeAvailableCapacity por "um arquivo tar + uma margem de segurança" antes de prosseguir — nenhum arquivo extraído pela metade vai explodir seu armazenamento.
• Segurança de caminho. isSafeRelativePath rejeita caminhos absolutos, caracteres nulos \0 embutidos e travessias de diretório com ... Nada é gravado fora do sandbox.
• Verificações de integridade. A validação de CRC e ISIZE é deixada para o zlib; um gzip truncado ou corrompido aparece como um erro legível (inflateFailed / truncatedArchive), e não como um congelamento silencioso.
• O .tar temporário é sempre limpo. Um defer o remove, tendo sucesso ou falhando, de modo que nenhum lixo de centenas de megabytes seja deixado para trás.

Durante a extração, a interface do usuário mostra uma sobreposição de progresso que distingue "descompactando gzip (expandido N MB)" de "extraídos N arquivos" — dando a você a certeza de que o processo está realmente funcionando.

Importação com um toque através da Extensão de Compartilhamento

Você pode pular completamente o vai e vem pelos Arquivos. A extensão sharelog reconhece um sysdiagnose_*.tar.gz direto da lista de Dados de Análise. O mais importante: a extensão não faz nenhuma análise — o seu limite de memória é pequeno demais para inflar um sysdiagnose. Ela apenas copia o arquivo para o contêiner do App Group (ShareInbox/), grava um sinal de pendente no UserDefaults do App Group e acorda o aplicativo principal através do esquema de URL devicestatus. O aplicativo principal, então, executa a extração que consome muita memória. O resultado parece com um único toque.

Passo 3: Ler a visão geral do dispositivo

O SysdiagnoseOverviewParser reúne a identidade do dispositivo a partir de três fontes:

• O primeiro bloco Properties: {…} em remotectl_dumpstate.txt → modelo, sistema operacional, número de série, UDID, ChipID, plataforma SoC, código de região...
• O "product-name" em ioreg/IOService.txt → nome comercial (ex: iPhone 17), com um fallback embutido de ProductType → nome.
• O nome da pasta raiz → carimbo de data/hora da captura (suportando tanto o formato com deslocamento +0800 quanto o de hora local).

Cada campo mantém tanto a sua chave bruta quanto um rótulo amigável (ex: ChipID / 33104), para que você possa verificar um cartão em relação à linha original do log.

Passo 4: Explorar as sete categorias

Esta é a decisão principal do produto: nenhum despejo de texto bruto, apenas as métricas-chave extraídas de cada arquivo como cartões. O SysdiagnoseCategoryConfig mapeia os milhares de arquivos em sete categorias mutuamente exclusivas, listando apenas arquivos que possuem um extrator dedicado. É por isso que o número no emblema é igual ao número de cartões que você verá — você nunca clica em uma seção e não encontra nada.

Os detalhes que apenas um iniciado extrairia

• Química da bateria (ACAM). Ele analisa o com.apple.batteryintelligence.batteryalgorithms-OnDeviceACAM-state.plist em três cartões:
  • Identidade da Bateria — número de série da célula, se é original, limite de tensão de carga.
  • Material Ativo — retenção do material ativo (QLi / Qn / Qp: a fração utilizável de íons de lítio / ânodo / cátodo).
  • Envelhecimento e Resistência — crescimento de SEI, perda por trinca / mudança de fase, resistência do eletrodo. Essas são as métricas de saúde microscópicas que normalmente existem apenas nas ferramentas internas da Apple.
• Hardware de armazenamento (NVMe + NAND). Do nó do controlador NVMe em IOService.txt, ele extrai o tipo de célula (SLC / MLC / TLC / QLC), tamanho da página, versão do firmware, Operações e Erros de leitura/gravação. De ASPSnapshots/asptool_snapshot.log, ele extrai as contagens de inicialização / ciclos de energia da NAND, quantidades de leitura/gravação durante a vida útil, nivelamento de desgaste e distribuição de Band. Em outras palavras: qual tipo de célula NAND você possui, o quanto ela já foi gravada e quanta vida útil resta.
• Identificação do chip. O chip-id no IODeviceTree está em formato hexadecimal little-endian; o extrator o converte no amigável "número T" da engenharia (ex: T8130), traduzindo um hex opaco em um nome de código de silício legível.

Técnicas de extração que valem a pena conhecer

• Arquivos grandes ignoram o limite de visualização. taskinfo, IODeviceTree.txt, IOService.txt e asptool_snapshot.log estão muito além do limite de visualização de 4.000 linhas. Os extratores leem o arquivo inteiro antes de analisá-lo, para que o ranking de consumo de energia, os nós do chip, o controlador NVMe e a saúde da NAND nunca sejam perdidos.
• Dobramento de múltiplos arquivos. Os arquivos CSV de ciclos diários de bateria (BDC_Daily_*.csv) colapsam em um único cartão de "ciclos de bateria" (último valor); todas as falhas .ips são agrupadas em um único cartão consolidado de "relatórios de falhas".
• Correlação entre arquivos. A contagem de ciclos é lida tanto do valor atual B0CT do SMC quanto do histórico do BDC, sendo então comparados.

Histórico e persistência

Cada importação vai para Application Support/SysdiagnoseCases/<serial_timestamp>, com os metadados no SysdiagnoseHistoryStore. Reimportar o mesmo arquivo reutiliza a extração existente (com deduplicação por caseId). A lista suporta o gesto de deslizar para excluir e limpar tudo, e é reaberta instantaneamente — porque ela apenas analisa novamente a visão geral, sem nunca reexecutar a extração.

Três promessas embutidas

1. Totalmente offline, no dispositivo. Desde a descompactação até a extração, nenhuma requisição de rede é feita.
2. Legibilidade em vez de desempenho. O ponto final de cada análise é um cartão, não o texto bruto. Os campos originais são mantidos para verificação cruzada, mas ficam ocultos por padrão.
3. Robustez de nível de produção:
   • Proteção contra travessia de caminhos, verificação prévia de espaço em disco, validação de cabeçalho tar, limpeza garantida de arquivos temporários.
   • Proteções na renderização de arquivos: O SysdiagnoseFileContent limita o texto a 512 KB / 4.000 linhas e os arquivos CSV a 1.000 linhas; os extratores leem os arquivos completos como contingência, então um único arquivo nunca fará a memória explodir.
   • Tradução de erros legíveis para humanos (transformando inflateFailed em "o arquivo está danificado ou o download foi incompleto").
   • Compatibilidade de caminhos entre inicializações (lidando tanto com novos caminhos relativos quanto com caminhos legados absolutos no sandbox).

Considerações finais

O Diagnostic Log Analyzer não tenta mostrar todos os mais de 2.000 arquivos existentes em um sysdiagnose. Ele responde às perguntas que você realmente faz — Qual hardware estou usando? Minha bateria está saudável? Quão desgastado está o meu armazenamento? Por que ele travou recentemente? — e fornece respostas limpas, compartilháveis e verificáveis.

A captura é guiada, a importação exige apenas um toque, a descompactação nunca esgota a memória e a tela mostra apenas cartões. Para o seu companheiro de longo prazo — tendências diárias de saúde da bateria a partir de logs de Análise — veja o guia do Battery Log Analyzer.