Работа с метриками приложения: измеряем, анализируем, улучшаем производительноть приложения Появилась запись моего доклада с конференции 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 и инструмент тимлида для планирования работы с техдолгом.