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

Появилась запись моего доклада с конференции Merge 2025 в Иннополисе, где я поделился опытом внедрения метрик производительности в мобильное приложение Звук. В прошлом году мы уделили много времени именно качеству работы приложения и его производительности. В докладе рассказал, какие инструменты рассматривали для анализа, как в итоге разработали собственный Performance-tracer, и какие метрики получилось улучшить. Тут опишу основные тезисы:

📌Зачем собирать метрики производительности?
Стабильность – ловим баги до пользователей.
UX – ускоряем старт и рендеринг.
Ресурсы – экономим трафик и батарею.
Бизнес – рост конверсии и удержания.
Техдолг - проще анализировать и планировать работу

🛠 Из каких инструментов выбирали:
Firebase Crashlytics: Простота, детальные отчеты о сбоях
Firebase Performance: Удобные дашборды, автоматически собирается статистика о работе приложения. Но немного замедляет старт приложения и нет гибкой настройки.
Sentry: Мониторинг ошибок + перфоманс, из минусов дорого, сложная настройка self-hosted решения
OpenTelemetry: Гибкость, open-source. Но изначально это решение для backend-разработки, не нашел ни одного примера кто использовал бы в мобильных приложениях и нет документации для Android.
В итоге, мы как настоящие разработчики решили сделать свое кастомное решение на базе Redash + кастомные трейсы

📌 Какие метрики собирали?
Холодный/горячий старт
Отрисовка экранов
Скорость сетевых запросов
Парсинг JSON, инициализация DI
Бизнес-логика и воспроизведение контента

🚀 В итоге, используя все доступные инструменты для оптимизаций мы добились
Холодный старт: -20%
DI-инициализация: -15%
Inflate-методы: стали в 2-20 раз быстрее

Выводы:
1. Собирайте метрики до того как заметили проблемы в проде
2. Начинайте с бесплатных инструментов (Firebase, Profiler).
3. Дашборды – мощный аргумент для построения roadmap и инструмент тимлида для планирования работы с техдолгом.