Home

Автор: Пермякова Ольга
Ссылка на оригинальную публикацию

Привет, я Оля, 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, которые относятся не только к нашему приложению, отмечу такие:

1. не обеспечивает графическое представление метрик. 

2. не агрегирует и не хранит 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. Так мы и сделали :)

<

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

Обсудить в форуме