Разработка
Символизация логов сбоев с помощью Xcode
Когда вы получаете нечитаемый отчет о сбое, вы можете символизировать логи с помощью Xcode. Для разработчика очень важно определить точную ошибку в коде и убедиться, что вы сможете исправить сбой, который потенциально может затронуть многих пользователей вашего приложения.
Многие из нас могут воспользоваться онлайн-платформой, такой как Firebase или Datadog, которая сама символизирует логи сбоев. Однако бывают случаи, когда вы получаете ips-файлы, извлеченные из консоли после того, как один из ваших коллег столкнулся с ошибкой. Прежде чем читать эти журналы, необходимо символизировать записи. В этой статье мы расскажем о двух важнейших форматах файлов, необходимых для этого процесса: IPS- и DSYM-файлы.
Что такое файлы ips?
Файлы IPS — это отчеты о сбоях, создаваемые приложениями, которые хранят данные в формате JSON в файлах с расширением .ips. Этот формат файлов был впервые представлен в iOS 15 и macOS 12. JSON содержит два основных объекта:
- Метаданные IPS, описывающие аварию на более высоком уровне
- Данные отчета о сбое, подробно описывающие сбой с информацией о потоках.
Если вы хотите узнать больше об этом формате файлов, рекомендую вам прочитать статью “Интерпретация отчета о сбое в формате JSON”.
Что такое файлы dSYM?
Файл dSYM — это Debug Symbole File (отсюда и название), создаваемый Xcode и содержащий всю необходимую отладочную информацию для символизации вашего журнала аварий. Другими словами, вам нужно использовать файл dSYM, который соответствует версии приложения, чтобы преобразовать отчет об аварии в читаемый формат.
Экспорт отчетов о сбоях из Xcode
Прежде чем погрузиться в символическую обработку логов ошибок, я хотел бы объяснить, как вы можете воспользоваться техникой, которая помогла мне решить множество проблем со сбоями. Время от времени мне звонит коллега и говорит, что наше приложение упало на его устройстве. В идеале отчеты о сбоях можно найти на онлайн-платформе вроде Datadog. Однако бывают случаи, когда приходится просить коллегу извлечь отчет о сбое вручную.
Экспорт отчетов о сбоях с помощью Xcode
Те коллеги, у которых установлен Xcode, могут выполнить следующие шаги для экспорта отчетов об авариях:
- Откройте Xcode
- Перейдите в строку меню и выберите Window → Devices and Simulators
- Нажмите на Open Recent Logs
После нажатия кнопки «Open Recent Logs» откроется окно Finder, в котором будут показаны все ips-файлы логов сбоев, относящиеся к устройству. Ваш коллега должен щелкнуть правой кнопкой мыши на самом последнем файле для вашего приложения и выбрать «Показать в Finder», чтобы иметь возможность поделиться файлом с вами напрямую.
Поиск журналов сбоев устройства без Xcode
Если у вашего коллеги не установлен Xcode, вы можете попросить его выполнить следующие шаги:
- Подключите устройство к компьютеру Mac
- Откройте Finder и в строке меню выберите Go → Go to Folder
- Введите ~/Library/Logs/CrashReporter/
- Откройте папку, обозначенную именем вашего устройства
- Выберите логи, названные по имени вашего приложения
Обратите внимание, что этот метод не всегда работает так, как ожидалось, поэтому я всегда стараюсь использовать Xcode, если это возможно.
Экспорт отчетов о сбоях в приложениях Mac
Для Mac-приложений экспорт отчетов о сбоях можно выполнить с помощью приложения Console:
- Откройте приложение Console
- Выберите Crash Reports на боковой панели
- Экспортируйте сообщения о сбоях, названные по имени вашего приложения
Вот как выглядит это окно для меня:
Вашему коллеге нужно найти отчет о сбоях, в котором имя процесса совпадает с именем вашего приложения.
Как вручную символизировать журнал аварий
В свое время я бы начал объяснять, как вручную символизировать журнал аварий с помощью терминала. Однако, к счастью, сейчас мы можем воспользоваться фантастическим приложением с открытым исходным кодом под названием MacSymbolicator.
Приложение позволяет выбрать отчет об аварии с левой стороны и файлы dSYM с правой. Оно поддерживает старые расширения файлов .crash
и новые форматы .ips
и .txt
. Самое приятное, что программа автоматически просканирует ваш Mac в поисках подходящего файла dSYM для отчета об аварии.
Например, я смог превратить лог сбоев RocketSim:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001026574e4 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [7689] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 RocketSim 0x1026574e4 0x102500000 + 1406180 1 RocketSim 0x10265727c 0x102500000 + 1405564 2 SwiftUI 0x1bbcebd50 0x1bac1b000 + 17632592 3 RocketSim 0x10265671c 0x102500000 + 1402652 4 RocketSim 0x102655a28 0x102500000 + 1399336
В более удобный для чтения формат:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001026574e4 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [7689] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 RocketSim 0x1026574e4 closure #1 in GridView.thinGridLines(geometry:) (in RocketSim) (GridView.swift:50) + 1406180 1 RocketSim 0x10265727c closure #1 in GridView.thinGridLines(geometry:) (in RocketSim) (GridView.swift:50) + 1405564 2 SwiftUI 0x1bbcebd50 0x1bac1b000 + 17632592 3 RocketSim 0x10265671c GridView.thinGridLines(geometry:) (in RocketSim) (GridView.swift:65) + 1402652 4 RocketSim 0x102655a28 closure #1 in GridView.body.getter (in RocketSim) (GridView.swift:27) + 1399336
Символизированный отчет говорит мне, что я должен изучить метод GridView.thinGridLines(geometry:)
, чтобы решить проблему.
Исправление символизированного отчета о сбое
Теперь, когда мы вывели символы в отчете об аварии, очень важно сделать шаг назад и подумать, хотите ли вы тратить время на решение этой проблемы. Как и в случае с другими задачами, вам необходимо определить приоритеты и количество пользователей, которые могут пострадать от одного и того же сбоя. В идеале нужно устранять все сбои, но, по моему опыту, это никогда не возможно.
Поэтому я всегда открываю Xcode Organizer, чтобы определить, есть ли еще пользователи с похожим сбоем. Это отлично работает, поскольку Xcode будет собирать и символизировать отчеты о сбоях для пользователей, которые согласились на отправку логов:
В моем примере я решил сосредоточиться на другом сбое, который затрагивает гораздо больше пользователей.
Дополнительным преимуществом поиска сбоя в Xcode является то, что вы можете перейти непосредственно к коду, связанному с ним. Это может значительно сократить время, которое вы тратите на поиск места и способа возникновения сбоя.
Наконец, я рекомендую всегда смотреть на код, в котором произошел сбой. Если вы можете довольно быстро определить причину сбоя, вы сможете быстро решить эту проблему.
Пометьте сбой как решенный и добавьте примечание для себя на будущее, чтобы было легче отслеживать регрессии:
Заключение
Знание того, как вручную символизировать отчет о сбое — важный навык для разработчика приложений. Он позволяет повысить стабильность работы приложения и улучшить пользовательский опыт. Xcode предоставляет несколько инструментов, которые помогут вам решать проблемы и управлять входящими отчетами о сбоях.
Спасибо!
-
Интегрированные среды разработки2 недели назад
Лучшая работа с Android Studio: 5 советов
-
Новости4 недели назад
Видео и подкасты о мобильной разработке 2024.43
-
Новости3 недели назад
Видео и подкасты о мобильной разработке 2024.44
-
Исследования2 недели назад
Поможет ли новая архитектура React Native отобрать лидерство у Flutter в кроссплатформенной разработке?