В каждом iPhone есть «чёрный ящик» под названием sysdiagnose — архив системной диагностики, к которому инженеры Apple обращаются в первую очередь при возникновении неполадок. Зажмите две кнопки громкости и боковую кнопку примерно на секунду, и iOS незаметно запишет один такой архив в фоновом режиме. Даже в сжатом виде он занимает сотни мегабайт и наполнен ioreg, smcDiagnose, taskinfo, отчётами о сбоях и данными о химическом составе батареи.

Но есть нюанс: он никогда не предназначался для вас. В распакованном виде это тысячи файлов и десятки тысяч строк обычного текста. Нужные вам данные сокрыты на 10 000-й строке IODeviceTree.txt или внутри какого-нибудь узла контроллера NVMe в IOService.txt. Даже опытному разработчику понадобится минут десять только на то, чтобы их найти.

Device Status⁺ превращает эту стену текста в экран с удобными для чтения карточками — и всё это полностью на устройстве, без загрузки ни единого байта. Это руководство подробно описывает, как работает Diagnostic Log Analyzer приложения: от захвата sysdiagnose до чтения карточек, и почему при этом ваш телефон не зависнет.

Что такое Device Status⁺?

Device Status⁺ — это бесплатное приложение для мониторинга системы от Space-Time Transformation Technology Co., Ltd. Оно требует iOS 17.0+ и работает на iPhone, iPad, Mac (серия M), Apple Vision Pro и Apple Watch. Помимо панелей мониторинга в реальном времени для CPU, памяти, хранилища, батареи и сети, в нём есть специализированный Diagnostic Log Analyzer для архивов sysdiagnose и Battery Log Analyzer для ежедневной аналитики батареи (рассматривается в отдельном руководстве).

Всё описанное ниже происходит локально. Экран импорта заявляет об этом прямо: "Вся обработка происходит на устройстве. Ничего не загружается."

Что именно представляет собой sysdiagnose?

sysdiagnose — это моментальный снимок всей системы в определённый момент времени. Активируемый комбинацией аппаратных кнопок, он собирает:

• дампы дерева устройств ioreg (IODeviceTree.txt, IOService.txt)
• показания SMC (System Management Controller) и smcDiagnose
• снимки процессов taskinfo
• агрегированные отчёты о сбоях (.ips)
• plist-файлы химии батареи и снимки износа NAND
• состояние сети, Wi-Fi и Bluetooth

Результатом является файл sysdiagnose_YYYY.MM.DD-...tar.gz, который в распакованном виде может содержать 2 400+ записей с расширенными заголовками PAX. На iPhone с ограниченной памятью очевидный подход — «считать всё в память, а затем распаковать» — завершается ошибкой OOM. Поэтому анализатор этого не делает.

Шаг 1: Захват sysdiagnose

Самая сложная часть — это не анализ. Самое сложное — получить сам файл. В Device Status⁺ есть иллюстрированное руководство (LogCollectionGuideView), которое проведёт вас через каждое нажатие:

1. Нажмите и удерживайте обе кнопки громкости + боковую кнопку около одной секунды, отпустите после виброотклика — это запустит создание sysdiagnose.
2. Продолжайте пользоваться телефоном как обычно и подождите примерно 10 минут для завершения сбора.
3. Откройте Настройки → Конфиденциальность и безопасность → Аналитика и улучшения → Данные аналитики и найдите sysdiagnose.
4. Откройте файл → Поделиться → Сохранить в Файлы → вернувшись в Device Status⁺, нажмите + для импорта.

Чтобы свести шаг «поиск записи» к нулю, руководство предлагает два быстрых действия в одно касание: установить ярлык (ссылка iCloud) и перейти прямо к панели «Аналитика и улучшения» через схему Shortcuts.

Шаг 2: Импорт без аварийного завершения из-за памяти

Именно здесь инженерная работа проявляет себя во всей красе. SysdiagnoseArchiveExtractor запускает двухэтапный потоковый конвейер, который «прогрызает» архив на 800 МБ, используя лишь несколько килобайт буферной памяти.

Этап 1 — gunzip. Используя zlib с inflateInit2(16 + MAX_WBITS) для декодирования с учётом gzip, входной файл отображается в память через mmap (постраничная подгрузка по требованию, никогда не находится в памяти целиком), а вывод записывается во временный файл .tar блоками по 64 КБ. Пиковое потребление памяти — это всего лишь буфер.

Этап 2 — untar. Самописная конечная машина (state machine) поэтапно анализирует заголовки USTAR / GNU / PAX и записывает каждый файл на диск. Поддерживаются длинные имена файлов GNU (тип L), расширенные заголовки PAX для каждой записи и глобальные (x / g), а также поля размера в формате base-256. Архив никогда не хранится в памяти целиком.

Детали, отвечающие за надёжность, не менее важны:

• Предварительная проверка места на диске. После gunzip, как только становится известен точный размер файла .tar, анализатор проверяет volumeAvailableCapacity на наличие «одного tar + запас прочности» перед продолжением — никакая наполовину распакованная папка не переполнит ваше хранилище.
• Безопасность путей. isSafeRelativePath отклоняет абсолютные пути, встроенные \0 и обход через ... Ничто не записывается за пределы песочницы.
• Проверки целостности. Проверка CRC и ISIZE оставлена zlib; усечённый или повреждённый gzip отображается как читаемая ошибка (inflateFailed / truncatedArchive), а не вызывает бесконечное зависание.
• Временный .tar всегда очищается. defer удаляет его в любом случае, поэтому после себя не остаётся мусора на сотни мегабайт.

Во время извлечения в интерфейсе отображается индикатор прогресса, который различает «распаковка gzip (распаковано N МБ)» и «извлечено N файлов» — что даёт вам уверенность в том, что процесс действительно идёт.

Импорт в одно касание через Share Extension

Вы можете полностью миновать путь через приложение «Файлы». Расширение sharelog распознаёт файл sysdiagnose_*.tar.gz прямо из списка «Данные аналитики». Что крайне важно, расширение не выполняет никакого анализа — его бюджет памяти слишком мал для распаковки sysdiagnose. Оно лишь копирует файл в контейнер App Group (ShareInbox/), записывает статус ожидания в UserDefaults группы App Group и будит основное приложение через схему URL devicestatus. Затем основное приложение выполняет извлечение, требующее ресурсов памяти. В результате всё ощущается как действие в одно касание.

Шаг 3: Чтение обзора устройства

SysdiagnoseOverviewParser собирает воедино идентичность устройства из трёх источников:

• Первый блок Properties: {…} в remotectl_dumpstate.txt → модель, ОС, серийный номер, UDID, ChipID, платформа SoC, код региона…
• "product-name" в ioreg/IOService.txt → коммерческое название (например, iPhone 17), со встроенным механизмом определения имени по ProductType в качестве запасного варианта.
• Имя корневой папки → временная метка захвата (поддерживаются как смещение +0800, так и форматы местного времени).

Каждое поле сохраняет как свой исходный ключ, так и понятную метку (например, ChipID / 33104), поэтому вы можете легко сопоставить карточку с исходной строкой лога.

Шаг 4: Изучение семи категорий

Это основное продуктовое решение: никаких дампов необработанного текста, только ключевые метрики, извлечённые из каждого файла в виде карточек. SysdiagnoseCategoryConfig распределяет тысячи файлов по семи непересекающимся категориям, перечисляя только те файлы, для которых есть выделенный экстрактор. Именно поэтому цифра на значке равна количеству карточек, которые вы реально увидите — вы никогда не нажмёте на категорию и не обнаружите пустоту.

Подробности, которые извлечёт только инсайдер

• Химия батареи (ACAM). Анализатор разбирает com.apple.batteryintelligence.batteryalgorithms-OnDeviceACAM-state.plist на три карточки:
  • Идентичность батареи — серийный номер элемента, является ли он оригинальным, предел напряжения зарядки.
  • Активный материал — удержание активного материала (QLi / Qn / Qp: полезная доля ионов лития / анода / катода).
  • Старение и сопротивление — рост SEI, потери из-за трещин / фазовых переходов, сопротивление электродов. Это метрики микроскопического состояния, которые обычно доступны только во внутренних инструментах Apple.
• Аппаратная часть хранилища (NVMe + NAND). Из узла контроллера NVMe в IOService.txt извлекаются тип ячеек памяти (SLC / MLC / TLC / QLC), размер страницы, версия прошивки, а также операции чтения/записи и ошибки. Из ASPSnapshots/asptool_snapshot.log извлекаются счетчики загрузок / циклов включения NAND, объёмы чтения/записи за всё время, выравнивание износа и распределение Band. Иными словами: какой тип ячеек NAND у вас установлен, сколько данных на них уже записано и сколько ресурса осталось.
• Идентификация чипа. chip-id в IODeviceTree представлен в виде little-endian hex; экстрактор преобразует его в удобное для инженеров «T-число» (например, T8130), переводя непрозрачное шестнадцатеричное значение в читаемое кодовое имя кремния.

Методы извлечения, о которых стоит знать

• Большие файлы обходят ограничение предпросмотра. taskinfo, IODeviceTree.txt, IOService.txt и asptool_snapshot.log находятся далеко за пределами ограничения предпросмотра в 4 000 строк. Экстракторы считывают файл целиком перед анализом, поэтому ранжирование энергопотребления, узлы чипов, контроллер NVMe и состояние NAND никогда не упускаются.
• Объединение нескольких файлов. Ежедневные CSV-файлы циклов батареи (BDC_Daily_*.csv) сворачиваются в одну карточку «циклы батареи» (с последним значением); каждый отчёт о сбое .ips объединяется в одну общую карточку «отчёты о сбоях».
• Перекрёстная корреляция файлов. Количество циклов считывается как из текущего значения B0CT SMC, так и из истории BDC, после чего они сравниваются.

История и сохранение данных

Каждый импорт попадает в Application Support/SysdiagnoseCases/<serial_timestamp>, а метаданные сохраняются в SysdiagnoseHistoryStore. Повторный импорт того же архива повторно использует существующую распаковку (дедупликация по caseId). Список поддерживает смахивание для удаления и функцию очистки всего списка, а также открывается мгновенно — поскольку он заново анализирует только обзор, но никогда не выполняет извлечение повторно.

Три встроенных обещания

1. Полностью офлайн и на устройстве. От распаковки до извлечения данных не выполняется ни одного сетевого запроса.
2. Читаемость важнее производительности. Конечным результатом каждого анализа является карточка, а не сырой текст. Исходные поля сохраняются для возможности cross-check, но по умолчанию скрыты.
3. Надёжность производственного уровня:
   • Защита от обхода путей (path traversal), предварительная проверка дискового пространства, валидация заголовков tar, гарантированная очистка временных файлов.
   • Защитные ограничители рендеринга файлов: SysdiagnoseFileContent ограничивает текст до 512 КБ / 4 000 строк, а CSV — до 1 000 строк; экстракторы считывают полные файлы в качестве запасного механизма, поэтому один файл никогда не сможет переполнить память.
   • Преобразование ошибок в читаемый человеком вид (превращение inflateFailed в «архив повреждён или загрузка была незавершённой»).
   • Совместимость путей между запусками (обрабатываются как новые относительные пути, так и унаследованные абсолютные пути песочницы).

Заключение

Diagnostic Log Analyzer не пытается показать все 2 000+ файлов из sysdiagnose. Он отвечает на вопросы, которые вы реально задаёте — Какое у меня оборудование? Здорова ли моя батарея? Насколько изношено хранилище? Почему недавно произошёл сбой? — и даёт вам чистые, доступные для передачи и проверки ответы.

Захват осуществляется с подсказками, импорт происходит в одно касание, распаковка никогда не исчерпывает память, а на экране отображаются только карточки. Чтобы узнать о долгосрочном помощнике — ежедневных трендах состояния батареи из логов Analytics — читайте руководство по Battery Log Analyzer.