Как стать автором
Обновить
85.01
Рейтинг
2ГИС
Главные по городской навигации

Чем измерить метрики производительности приложения

Блог компании 2ГИС Тестирование мобильных приложений *

Привет, я Оля, 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 можно применять для сбора метрик и с реального девайса, и с симулятора.

Traces из Firebase Performance Monitoring
Traces из Firebase Performance Monitoring

Документация

Подробная, с пошаговыми инструкциями по настройке метрик.

Графическое представление

В отличие от MetricKit, создатели FPM позаботились о готовом графическом представлении агрегируемых характеристик. Важные метрики можно добавить на дашборд. Для навигации среди отчётов можно использовать фильтры: версия приложения, ОС, регион и другие. 

Дашборд
Дашборд
Раздел проблем за последний месяц
Раздел проблем за последний месяц
Детализация метрик
Детализация метрик
Детализация сетевого запроса
Детализация сетевого запроса

Вывод

Что мы выбрали

При выборе инструмента надо отталкиваться от целей снятия метрик. 

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

Если же приложение небольшое либо ресурсов команды недостаточно, то проще обратиться к Firebase Performance Monitoring. Так мы и сделали :)

Сравнение MetricKit и FRM
Сравнение MetricKit и FRM

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

Теги:
Хабы:
Всего голосов 11: ↑11 и ↓0 +11
Просмотры 2.1K
Комментарии Комментарии 1

Информация

Дата основания
Местоположение
Россия
Сайт
2gis.ru
Численность
1 001–5 000 человек
Дата регистрации