Привет, я Оля, QA iOS. Наша команда выкатывает обновления для мобильного 2ГИС и следит, чтобы у него не упала производительность.
Изначально мы отслеживали это уже после попадания приложения в стор, что, конечно, было не очень эффективно. Если происходила просадка, приходилось срочно чинить и перезаливать приложение. Естественно, нам хотелось улучшить процесс и проверять производительность до выхода приложения в стор, а ещё лучше — на каждом этапе создания приложения.
Для этого теоретически подходили два инструмента — MetricKit и Performance Monitoring. Мы решили присмотреться к ним, потому что:
MetricKit — продукт Apple, а значит будет поддерживаться, пока существует iOS;
Performance Monitoring — продукт Firebase от Google. У нашей команды есть опыт использования Firebase Crashlytics, значит перейти на продукт от этого же производителя будет легко.
В статье я расскажу, что из себя представляют эти инструменты — об их метриках, отчётах в режиме реального времени, документации и графическом представлении. И расскажу, какой из них мы выбрали.
MetricKit
Метрики
У MetricKit несколько групп метрик: производительности, аккумулятора, отзывчивости, доступа к диску. Ещё есть кастомные метрики, которые удобно настраивать под приложение. Коротко о том, что есть в каждой группе:
Производительность:
причины завершения работы приложения в бэкграунде и форграунде,
время, в течение которого приложение было активно,
использование памяти,
краши (diagnostic report).
Аккумулятор:
использование CPU/GPU,
затраты на отображение приложения,
использование отслеживания местоположения,
передача данных по сети,
состояние сотовой сети,
CPU exceptions (fatal/nonfatal).
Отзывчивость приложения:
отзывчивость анимации,
время запуска приложения,
отклик приложения на действия юзеров,
зависания.
Доступ к диску:
использование диска,
disk write exceptions.
Через кастомные метрики можно отслеживать продолжительность событий, их количество и влияние на производительность. Например, для нас такими метриками будут скорость отрисовки пинов и маршрута на карте, загрузки базы городов и фотографий, появления подсказок в поисковой строке.
Был случай, когда в боевой версии приложения пользователь искал что-то в Москве и пины с результатами появлялись на карте очень медленно. Чтобы разобраться в проблеме, мы замеряли скорость отрисовки на разных девайсах и осях вручную. Потратили несколько часов только на этот анализ. Если автоматизировать замеры этих метрик, то можно быстро сравнить метрики и определить — просели мы в производительности или нет. Нам это подходит.
Снимать метрики можно и для сборок, которые уже на бою, и для отправленных в TestFlight. Отчёты приходят раз в сутки в виде json-файлов — payloads.
Payloads выглядят как длинные портянки текста. Цветным показала, где собраны группы метрик:
Мы поддерживаем 2ГИС от iOS 12. Обычно отчёты о проблемах производительности поступают от пользователей именно со старыми версиями ОС. Большую часть метрик в MetricKit можно отследить с iOS 13, некоторые метрики — только с iOS 14. А значит, MetricKit не решает вопрос трекинга проблем производительности на более старых версиях ОС. Это нам не подходит.
Метрики и события в реальном времени
Отчёты о метриках приходят раз в сутки. Кроме метрик в MetricKit можно получать отчёты о сбоях и падениях. Для iOS 13 и 14 они приходят раз в сутки, а для iOS 15 — сразу, как только что-то случится. То есть о некоторых проблемах 2ГИС мы будем узнавать не сразу — это плохо.
Документация
Наиболее подробная информация была представлена на WWDC. Официальная документация крайне сдержанна и не дает подробностей об имплементации и использовании MetricKit. И в сети довольно мало статей от компаний с реальным опытом внедрения инструмента.
Графическое представление
Из минусов MetricKit, которые относятся не только к нашему приложению, отмечу такие:
не обеспечивает графическое представление метрик.
не агрегирует и не хранит payloads.
Как хранить, агрегировать и отрисовывать графики, предстояло подумать нам самостоятельно — без этого продукт терял смысл. Без графиков и таблиц не получится наглядной картины происходящего на бою. И отслеживать динамику показателей от релиза к релизу станет невозможно.
Вывод
Firebase Performance Monitoring
Метрики
Для простоты я буду называть Firebase Performance Monitoring — FPM. У FPM есть несколько групп метрик — метрики жизненного цикла, рендеринга экрана, характеристики сетевых запросов и кастомные метрики. Подробнее о каждой группе:
Жизненного цикла приложения:
время запуска приложения,
время работы приложения в форграунде/бэкграунде.
Рендеринга экрана:
медленный рендеринг экранов,
зависания экранов.
Характеристики сетевых запросов:
время ответа от сервера,
Request payload size,
Response payload size.
Спектр снимаемых метрик у FPM не так широк, как у MetricKit. Недостаток ли это — зависит от того, что в приложении планируется контролировать. Так как оба инструмента дают возможность добавлять кастомные метрики, FPM может быть вполне достаточно.
FPM позволяет собирать данные метрик производительности в режиме реального времени. Как самостоятельный инструмент он не собирает отчёты о сбоях и падениях, для этого есть отдельный инструмент — Firebase Crashlytics. Для справедливого сравнения с MetricKit это стоит отметить, так как имплементация одного инструмента от Firebase не предполагает автоматическую имплементацию другого.
Данные собираются в traces — отчёты с информацией о метриках, снятых за промежуток времени. Метрики можно получать не только со сборок на этапе beta- и public-релизов, но и на этапе локальной разработки. FPM можно применять для сбора метрик и с реального девайса, и с симулятора.
Документация
Подробная, с пошаговыми инструкциями по настройке метрик.
Графическое представление
В отличие от MetricKit, создатели FPM позаботились о готовом графическом представлении агрегируемых характеристик. Важные метрики можно добавить на дашборд. Для навигации среди отчётов можно использовать фильтры: версия приложения, ОС, регион и другие.
Вывод
Что мы выбрали
При выборе инструмента надо отталкиваться от целей снятия метрик.
Если у приложения широкий функционал и команда готова потратить силы на организацию хранения, агрегации и отрисовки графического представления метрик, можно использовать MetricKit. Мы решили, что у нас нет времени и сил на допиливание, и отказались от инструмента.
Если же приложение небольшое либо ресурсов команды недостаточно, то проще обратиться к Firebase Performance Monitoring. Так мы и сделали :)
Буду рада почитать в комментариях о том, как вы выбирали инструменты для тестирования приложений.