Как искать краш в логах?
Что проверяют
Есть ли у вас метод, а не надежда на поиск по слову «error». Интервьюеру важно, чтобы вы нашли первопричину, собрали доказательства для разработчика и знали, где лежат логи на вашей платформе. Следом часто спрашивают, что делать, если краш не воспроизводится.
Как отвечать
Опишите путь по шагам:
- сузить окно: время падения, версия сборки, устройство или окружение, идентификатор пользователя или сессии. Без этого вы читаете тысячи чужих строк;
- взять нужный источник: на Android это
adb logcat, у падения Java или Kotlin кода есть маркерFATAL EXCEPTIONс тегомAndroidRuntime, аadb logcat -b crashпоказывает только буфер падений. На iOS это отчёты о сбоях в Xcode Organizer и Console, их символизируют через dSYM, иначе вместо имён методов будут адреса. В вебе это консоль DevTools и серверные логи; - найти первую ошибку, а не последнюю: краш часто следствие. Перед ним бывает таймаут,
nullв ответе API или нехватка памяти, и показать нужно именно это; - прочитать стек: тип исключения, сообщение, верхние кадры из кода приложения, а не системных библиотек;
- связать клиент и сервер: по
trace-idилиrequest-idв Kibana, Grafana Loki или аналоге найти, что вернул бэкенд в тот момент; - сравнить с успешным сценарием и воспроизвести.
Если в проекте подключены Firebase Crashlytics или Sentry, начните с них: они группируют падения, показывают частоту, версии и цепочку действий пользователя перед сбоем. В баг-репорт кладите фрагмент лога с контекстом, версию, окружение и шаги, а не весь файл на мегабайты.
Где спотыкаются
Ищут только по ERROR. Падение из-за нехватки памяти или убийство процесса системой может обойтись без этого слова, а ANR на Android вообще не исключение, а зависание главного потока.
Прикладывают к задаче весь лог без пометки, где проблема. Разработчик тратит время на работу, которую должен был сделать тестировщик.
Путают причину и следствие: показывают последний NullPointerException, хотя за секунду до него упал сетевой запрос, и чинить надо обработку ошибки сети.