Что пишут в блогах

Подписаться

Конференции

Heisenbug 2022 Spring
Большая техническая конференция по тестированию
Online — с 30 мая по 1 июня. Offline-день — 21 июня

TestDriven Conf

Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

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

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

Привет, я Оля, 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

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

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