Журнал ошибок ios

Краткая инструкция по чтению и разбору логов мобильных устройств на Android и iOS, а также необходимые инструменты для Windows и MacOS.

Статья подготовлена red_mad_robot и «Альфа-Банком» на основе доклада Senior QA red_mad_robot Ольги Никитиной «Инструменты для снятия логов с Android / iOS устройств. Чтение и разбор» на митапе «QАчественное общение» при поддержке red_mad_robot.

Уровни логирования и что они означают

Для начала разберёмся с логами. Это текстовые файлы, в которых записываются все действия пользователя. Например, какие кнопки он нажимает в приложении и как на это оно реагирует в ответ.

Записи в логах формируются в хронологическом порядке. Самая свежая — внизу.

Есть два вида логов:

• Crash logs — файл, в котором хранятся записи только об ошибках экстренного завершения программы — по-простому, когда приложение крашнулось.

• Logs — простые логи, или журнал событий. Это файл, в котором хранятся системные записи и ответы устройства на действие пользователя.

Логи на мобильных устройствах бывают нескольких уровней:

• ERROR,

• WARN,

• INFO,

• DEBUG,

• VERBOSE.

Они представлены по уровню важности — от самого высокого к самому низкому, — и каждый следующий уровень включает в себя предыдущий. Например, VERBOSE содержит в себе логи всех остальных.

Примечание: уровни более применимы к логам на Android, потому что именно там такое разделение встречается чаще.

Рассмотрим подробнее каждый уровень.

Error (ERROR)

На этом уровне информируются ошибки работы системы.

Записи этого уровня требуют быстрого вмешательства разработчика — на такие ошибки нужно реагировать максимально быстро.

Как пример, такая запись в логе:

“ SpannableStringBuilder: SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length ”

Это ошибка, в которой говорится, что строковый элемент span не может быть пустым.

Или вот:

“ [ZeroHung]zrhung_get_config: Get config failed for wp[0x0008] ] ”

Эта системная ошибка сообщает, что происходит утечка памяти при взаимодействии с каким-то элементом или приложением.

Warning (WARN)

На этом уровне отображаются записи, сообщающие о каком-то неожиданном поведении, требующем внимания, или о ситуации, которая незнакома системе.

Например, сообщение ниже — запись из тестового приложения:

“ [OMX.hisi.video.decoder.avc] setting nBufferCountActual to 16 failed: -2147483648 “

Мы пытаемся декодировать запись в какой-то формат, но его нет. Ошибка сообщает о неуспешной попытке настройки видеоплеера в нужном формате.

Ещё пример:

“ BroadcastQueue: Permission Denial: broadcasting Intent ”

Эта системная ошибка говорит о сбое в работе одного из виджетов на устройстве.

Info (INFO)

На этот уровень приходят записи информационного характера, например о работе системы.

Допустим, такое сообщение об уровне заряда батареи на устройстве:

“ APwBatteryMonitor: screen off start battery: 100 ”

А это сообщение говорит о том, что экран устройства был выключен:

“ HwBatteryService: intent = Intent { act=android.intent.action.SCREEN_OFF flg=0x58200010 } ” 

Ещё в логи этого уровня входят запросы от клиента на сервер: хедеры, тело запросов, которые отправляет клиент, и ответы сервера.

“ okhttp.OkHttpClient: <— 200 https://domainname/api/v1/smth/deals (1691ms)

okhttp.OkHttpClient: server: nginx/1.15.9

okhttp.OkHttpClient: date: Thu, 23 Sep 2021 19:41:17 GMT

okhttp.OkHttpClient: content-type: application/json

okhttp.OkHttpClient: vary: Accept-Encoding

okhttp.OkHttpClient: strict-transport-security: max-age=15724800; includeSubDomains

okhttp.OkHttpClient: {«key»:{«key»:value,»name»:»»},»key»:value,»key»:value}

okhttp.OkHttpClient: <— END HTTP ”

Такие записи могут помочь вам в понимании какого-то бага или в разборе задачи при условии, что вы не можете перехватить трафик или не знаете, какие запросы отправляются на бэкенд.

Debug (DEBUG)

Это уровень сообщений, в которых передаётся информация о процессах отладки или шагах работы крупных процессов.

Например, в записи ниже сказано, что пользователь нажимал на кнопку уменьшения или увеличения громкости:

“ MediaSessionService: dispatchVolumeKeyEvent ”

Сначала мы видим запись о самом факте нажатия на кнопку, далее оно расшифровывается подробнее:

{ action=ACTION_DOWN, keyCode=KEYCODE_VOLUME_UP }

Ещё пример: если ваше приложение использует сокет-сессию, то на уровне DEBUG мы можем увидеть, когда сессия начинается и заканчивается:

“ b$b: WebSocket connected ”

Verbose (VERBOSE)

Сообщения такого уровня уточняют или раскрывают действия.

Например, у нас есть служба управления окнами на экране приложения. И на уровне Verbose мы можем увидеть подробности её работы.

Открытие окна:

WindowManager: addWindow

Закрытие окна:

WindowManager: Removing Window

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

GnssLocationProvider: reportLocation Location […] 

А меняя звук на устройстве, мы увидим, как растёт или падает значение:

AudioManager: getStreamVolume  streamType: 3 volume: 10

Каждое нажатие, то есть изменение звука, будет отражаться новым сообщением.

Verbose — уровень самого низкого приоритета. Выбирая такой уровень отображения логов, мы будем видеть записи и со всех предыдущих уровней.

Примечание: разработчики приложения самостоятельно покрывают действия логами, определяют уровни, а также какие сообщения какому из них соответствуют.

Инструменты для снятия логов: Android

Расскажем о трёх способах.

Первый — Logcat в составе Android Studio, самый известный и широко используемый.

Для снятия логов нам необходимо перевести устройство в режим разработчика/отладки. Для этого нужно:

• найти в настройках номер нашего билда или ОС (в зависимости от устройства),

• около десяти раз нажать на эту информацию,

• при появлении сообщения о том, не хотим ли мы перевести устройство в режим разработчика, нажать «Ок».

Примечание: алгоритм может отличаться в зависимости от производителя устройства, потому что у многих из них свои надстройки на ОС Android.

Дальше подключаем устройство по USB к ПК и устанавливаем Android Studio.
Следующие шаги на скрине:

1. Выбираем вкладку Logcat (переходим к сообщениям в реальном времени).

2. В окошке выбираем телефон, с которого снимаем логи.

3. На этой вкладке выбираем логи определённого приложения. Если нужно снять вообще все логи со всех приложений и системы, эту вкладку стоит не трогать. Рядом с ней можно выбрать уровень логирования (вкладка Verbose на скрине).

4. В поле поиска, где мы можем фильтровать выдачу, разрешено писать что угодно — от названия пакета до частей вроде fatal.

На скрине видно логи с подключенного устройства.

Второй способ — выгрузка логов с самого устройства. Кроме режима разработчика нам нужно подключить устройство к ПК через USB и установить ADB — Android Debug Bridge.

Открываем терминал и пишем две команды.

Первая — adb devices — показывает подключённые устройства, которые видит ADB. В терминале выглядит так:

Вводим вторую команду — adb -s название устройства logcat, — которая запускает утилиту Logcat для конкретного устройства. В терминале в реальном времени будут поступать логи.

Как их читать?

1. В первом столбце — дата и время поступления записи.

2. Во втором — обозначения уровней логирования. Например, D — это Debug.

3. В третьем показываются названия инструмента, утилиты, пакета, от которых поступает сообщение, а также расшифровка того, что вообще происходит.

Третий инструмент — SDK Platform Tools. Процесс его установки практически аналогичен предыдущим двум:

• переводим телефон в режим разработчика,

• подключаем к ПК по USB,

• скачиваем на ПК папку SDK PT (под свою ОС),

• открываем папку SDK PT в терминале.

Теперь пишем команду ./adb logcat –v threadtime > ./android-debug.log.

В терминале это выглядит так:

Прерываем выполнение команды (например, на Mac это Control+C). Лог добавляется в папку.

Открываем:

Очень похоже на предыдущий терминал, но файл обновляется, пока в терминале действует команда.

Инструменты снятия логов: iOS

В первую очередь нас интересует xCode — интегрированная среда разработки (IDE), в которую встроен нужный нам инструмент Simulator.

Как использовать инструмент:

1. Устанавливаем xCode.

2. В системной строке нажимаем xCode → Open Developer Tools → Simulator.

3. Устанавливаем приложение.

4. В самом симуляторе выбираем Debug → Open System Log.

Мы будем видеть логи в реальном времени:

Подобное оформление логов мы уже где-то видели, но построение информации в выдаче немного отличается. Есть дата и время (1) и данные (2) о том, с какого устройства снята информация: имя компьютера, элемент системы, с которого пришло сообщение, и его расшифровка.

Но первый способ работает только с симуляторами. Если необходимо снимать логи с реального устройства, в этом может помочь раздел Devices and Simulators.

Записи можно отфильтровать по конкретному процессу (вашему приложению):

1. Устанавливаем xCode.

2. Подключаем устройство к ПК по USB.

3. Открываем xCode → Windows → Devices and Simulators.

Дальше нажимаем у устройства Open Console и видим панель с названием устройства, информацией о модели и ОС:

Логи поступают в реальном времени, но их удобно отслеживать:

У нас есть три столбца:

1. «Время» — время поступления сообщения.

2. «Процесс» — с какой части системы/приложения пришло сообщение.

3. «Сообщение» — описание события, сервисная информация.

В инструменте есть поиск для фильтрации выдачи. Ещё есть полезная кнопка «Приостановить» — она останавливает поток логов.

А вот утилита iMazing поможет снимать iOS-логи для тех, у кого установлен Windows. Приложение платное, но часть функциональности доступна бесплатно. Например, за снятие логов устройства платить не нужно.

В меню выбираем «Показать консоль устройства». В открывшемся окне приходят записи логов в реальном времени со всего устройства.

Ещё одно важное достоинство iMazing — возможность сохранять логи (разумеется, по кнопке «Сохранить»).

Статья подготовлена red_mad_robot и «Альфа-Банком» на основе доклада Senior QA red_mad_robot Ольги Никитиной «Инструменты для снятия логов с Android / iOS устройств. Чтение и разбор» на митапе «QАчественное общение» при поддержке red_mad_robot.

Перейти к содержимому

У вас когда-нибудь случались сбои, причину которых вы не могли определить и вообще не понимали, в чем дело? И никакое тестирование не позволяло воспроизвести проблему? Если да, то вы попали по адресу!

Впрочем, как вы увидите в этой статье, способность отлаживать сложные сбои не появляется мгновенно. Помните об этом: не существует волшебного инструмента, который вы запустите и который даст вам ожидаемый результат. Когда речь идет о сложных сбоях, вместо этого нам нужно подготовить нашу среду таким образом, чтобы эти проблемы при возникновении были более понятны, что поможет в их решении. Давайте посмотрим, как это сделать!

Что такое сложные сбои?

Одна вещь, которую я считаю полезной, — это рационализация проблемы. Легко посмотреть на странную проблему и просто отмахнуться от нее как от чего-то волшебного, что больше никогда не повторится, но это бессмысленно. Всегда есть вполне логичная причина возникновения проблемы (скорее всего, по вашей вине), и чем больше пользователей пострадали от нее, тем больше вероятность того, что это не случайность. Так как может получиться, что прямо сейчас вы сталкиваетесь с проблемой, которая затрагивает большое количество пользователей, и при этом не имеете ни малейшего представления о том, что происходит и как ее воспроизвести?

По моему опыту, неспособность понять суть сбоя всегда сводится к недостатку информации. Проблема не в том, что проблема «слишком сложная», а в том, что у вас недостаточно данных. Подумайте о самой странном креше, который вам когда-либо приходилось рассматривать: разве он не был бы намного менее сложным, если бы в отчете об сбое было точно указано, в чем была проблема и как ее решить? Неважно, насколько странным является сбой, именно ваша способность понять и воспроизвести проблему определяет вероятность ее решения.

Таким образом, если вы хотите быть в состоянии решить любой сбой, вам необходимо улучшить данные, которые его сопровождают. Давайте рассмотрим несколько способов сделать это!

Метаданные, специфичные для конкретного приложения

Вы, наверное, заметили, что такие платформы, как Firebase, всегда включают некоторые полезные метаданные, связанные с устройствами, например, наиболее распространенную версию iOS, вызвавшую крах, были ли пользователи в foreground или background режиме, был ли у устройства jailbrake, сколько места на диске оставалось у каждого пользователя, когда произошел крах, и так далее. Эти данные чрезвычайно полезны, но их недостаточно. Что вам действительно необходимо, так это включить метаданные вашего приложения, которые помогут вам точно определить, что делал пользователь в момент сбоя. Вот некоторые примеры того, что вы должны добавить:

• Экран, на который смотрел пользователь
• «Тип» пользователя, если применимо (бесплатный? премиум? logged out?)
• Последнее действие пользователя (пытался ли он куда-то перейти?)
• Правильно ли завершился запуск приложения?
• Получил ли пользователь предупреждение о нехватке памяти?
• Завершается ли работа приложения?
• Есть ли у пользователя активное подключение к Интернету?
• Какой язык видит пользователь?

Трудно представить полный список, учитывая, что он будет совершенно разным для разных приложений, но то, что вам нужно сделать здесь, это собрать все о вашем приложении, что может повлиять на его выполнение, и включить это в ваши отчеты о сбоях.

Вы можете добавить эту информацию в Firebase через API SDK с парами ключ/значение, но для того, чтобы увидеть эту информацию в процентах, вам, вероятно, придется абстрагировать Firebase в своем собственном бэкенде с  отчетами о сбоях.

Аналитика

Помимо метаданных, еще одним важным компонентом является наличие в вашем приложении надежной инфраструктуры аналитики. В большинстве приложений она уже есть, хотя, возможно, вам потребуется внести некоторые изменения, чтобы сделать ее пригодной для использования в целях составления отчетов о сбоях.

Суть в том, что если у вас есть надежная аналитическая реализация, вы должны иметь возможность использовать ее для воспроизведения шагов пользователя до креша. Таким образом, для этого вам необходимо убедиться, что ваш аналитический SDK получает как можно больше информации о взаимодействии с пользователем, например:

• «Пользователь коснулся кнопки X»
• «Пользователь увидел баннер Y»
• «Пользователь перешел на экран Z».

Для обеспечения воспроизводимости большинство сторонних SDK сегодня включают функцию «временной шкалы», которая показывает все события, отправленные конкретным пользователем в определенное время.

Использование этой информации для решения проблем о сбоями

Наконец, получив как можно больше информации о состоянии приложения в момент сбоя, вы можете следовать созданному мной пошаговому руководству, которое поможет вам отследить и решить подавляющее большинство случаев.

Проверьте сбойный поток

Если вы читаете это руководство, это, вероятно, означает, что вы уже пробовали это сделать и ничего не получилось, но в любом случае стоит упомянуть, что в подавляющем большинстве случаев ответ лежит непосредственно в трассировке сбоя. Проверив путь, пройденный кодом, вы сможете найти и воспроизвести проблему.

Проверьте метаданные о сбое

Если трассировка расплывчата, то просмотр добавленных метаданных может выявить проблему. При просмотре метаданных обратите внимание на значения, близкие к 100% или 0%. Это может показать, что сбой связан с конкретным устройством или условием внутри приложения.

Проверьте фоновые потоки

Если метаданные также расплывчаты, это может означать, что сбойный код — это не сама проблема, а скорее косвенное следствие проблемы, которая произошла асинхронно где-то еще. В этой ситуации вы можете обнаружить проблему, посмотрев, что происходит в других потоках, в которых произошел сбой. Попробуйте исследовать много случаев сбоя и сравните их потоки друг с другом. Есть ли у них что-то общее, чего нет в других задачах? Если да, то это может быть причиной проблемы.

Сопоставить среду пользователей, у которых произошел сбой

Если после глубокого анализа трассировки и метаданных вы все еще не можете понять, в чем дело, возможно, сбой связан с конкретным устройством и/или A/B-тестом. Если это так, то вы должны быть в состоянии воспроизвести сбой, сопоставив его с окружением пользователя. Помимо того, что вы должны использовать именно тот смартфон/версию ОС, на которой произошел сбой, убедитесь, что вы также используете флаги A/B-тестирования пользователя (если они есть у вашего приложения).

Что касается флагов, то очень полезно сравнить флаги пользователей с проблемой и флаги пользователей без проблемы. Если проблема связана с флагом, то составление списка общих флагов в этих группах покажет, какой флаг (или его отсутствие, если проблема была вызвана удалением эксперимента) вызывает проблему.

ДОБАВЛЕНИЕ: Дэйв Вервер также упомянул кое-что важное, что я забыл добавить — убедитесь, что вы также запустили точную сборку приложения, на котором произошел сбой у пользователей! Не исключено, что изменения в вашей ветке повлияют на условия возникновения сбоя, поэтому всегда убедитесь, что вы находитесь именно в том коммите, который использовался в сборке. Вы можете получить эту возможность, заставив свой CI создавать git-метку каждый раз, когда он загружает новую сборку — назвав метку соответствующим номером сборки, вы получите возможность откатиться к любому релизу, который вы когда-либо создавали.

Проследите шаги пользователя

Если все оказалось бесполезным, вы должны быть в состоянии воспроизвести проблему, подражая действиям пользователя до того, как произошел сбой. Иногда это может быть что-то абсурдно специфическое, например, открыть/закрыть приложение несколько раз, перевернуть его вверх ногами, открыть плейлист, а затем бросить устройство об стену. Если это так, то вы сможете найти эти действия, просмотрев таймлайн вашего аналитического SDK для этого пользователя.

Важно отметить, что условия возникновения проблемы могут охватывать несколько сессий, например, проблема связана с контентом, который был загружен несколько дней назад. В таких случаях для понимания проблемы необходимо просмотреть данные не только сессии, в которой произошел сбой, но и сессий, которые предшествовали ей.

Инструмент для поиска проблем в безопасности потоков/памяти

Если вы все еще не можете понять, что происходит, то, возможно, вы имеете дело с недетерминированной проблемой, вызванной либо проблемами безопасности потоков, такими как условия гонки, либо проблемами памяти, такими как повреждение кучи. К сожалению, простого способа выяснить это не существует, и для их обнаружения вам потребуется глубокое понимание кода. В iOS некоторую помощь могут оказать инструмент Zombies и средства санации потоков/памяти.

Лучшее, что вы можете сделать в данном случае, — это предотвратить возможность их возникновения. Если вы работаете с асинхронным кодом, всегда будьте на 100% уверены, что ваша реализация безопасна для потоков для всех сценариев использования, прежде чем мерджить ее. Хотя проблемы, связанные с потоками, очень легко создать, их чрезвычайно трудно отлаживать. Выбирайте всегда более безопасный вариант, чтобы избежать подобных проблем в будущем.

Проверьте, что нового в релизе, в котором произошел сбой

В некоторых случаях, особенно при очень старых проблемах, может быть полезно отследить точную версию, в которой возникла проблема, и зайти на GitHub, чтобы посмотреть, что именно было введено в этом выпуске. Если ничего не помогло, то отмена подозрительных пул реквестов может помочь.

Добавьте больше логов

Если вы совершенно не понимаете, что происходит, то добавление дополнительных логов может принести некоторое облегчение. Firebase позволяет прикреплять общие журналы к отчету о сбое, и один из способов их использования — это регистрация информации о состоянии пользовательского приложения в месте, где произошел сбой. Постарайтесь придумать что-нибудь странное или незапланированное, что может происходить вокруг кода, который дает сбой, и запишите это в Firebase — в следующем выпуске вы сможете увидеть новую информацию рядом со сбоями. Логи также могут быть полезны еще до внедрения новой фичи — если вы думаете, что новая функция может вызвать проблемы, вы можете обезопасить ее с помощью логов еще до выпуска. В случае возникновения проблемы у вас уже будет дополнительная информация, необходимая для ее отладки.

Что еще?

Если вы дошли до этого момента, то вполне возможно, что ваши первоначальные мысли верны: вы имеете дело с какой-то странной аппаратной проблемой, вызванной солнечным излучением в определенное время суток для конкретного пользователя в Латвии.

Чтобы избежать подобных ситуаций, я лично стараюсь не рассматривать проблемы до тех пор, пока они не будут постоянно возникать у достаточно большого количества пользователей. Всегда есть вероятность того, что проблемы могут быть вызваны ситуативными факторами, но если они не постоянны или не имеют большого влияния, лучше игнорировать их, чтобы не тратить время на выяснение того, в чем, как оказалось, нет вашей вины.

Источник

Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.