Представь что ты скачал крутое приложение, открыл - и тишина😱 Экран черный уже 8 секунд, после которых ты быстро удаляешь и пытаешься найти альтернативу Так что в 2026 году производительность уже вопрос выживания приложения на рынке! Ниже метрики, которые стоит проверять перед релизом, иначе пользователи будут удалять быстрее, чем ты успеешь сказать “подождите, сейчас оптимизируем”:

1. Время запуска приложения Cold Start (приложение было выгружено из памяти) Ты нажал иконку > сколько секунд до того момента, когда можно уже тыкать кнопки? Оптимально: 1,5–2 секунды, если больше, то Google с Apple уже понижают тебя в поиске и рекомендациях, медленный старт = меньше людей вообще увидят приложение Причины долгого запуска: - В Application.onCreate() делают кучу тяжелой работы, сразу начинает грузить аналитику, базу, настройки, погоду на Марсе и курс биткоина - все на главном потоке - Нет Baseline Profiles (когда мы заранее просим компилятор скомпилировать часто используемые участки кода) - Много библиотек (47 библиотек, каждая по 2 сек на загрузку итого 1.5 минуты) - Старый сплеш-экран или сложный первый экран - Читают/пишут файлы или тянут данные с сервера на главном потоке

Warm Start (приложение уже в памяти, разворачивается) Ожидается мнгновенный отклик и отрисовка Причины долгого запуска: - Заново строит весь экран без кэш - Снова инициализирует все подряд (Firebase, рекламу и тд) - В onResume сразу лезет в сеть за свежими данными (а вдруг что-то новенькое появилось?)

Где посмотреть: Android - Firebase Performance, так же профайлер в android studio может зафиксировать время от запуска процесса до отображения первого кадра (Time to Initial Display) и до полной интерактивности (Time to Full Display) iOS - Xcode Product - Profile - App Launch

2. ANR (Application Not Responding) Ситуация когда система показывает «Приложение не отвечает» и предлагает убить его, обычно когда главный поток заблочен или UI не отвечает ~5 секунд Причины ANR: - Блокировка главного потока тяжёлыми операциями (например парсишь 5-мегабайтный JSON) - Deadlocks - Сложный рендер, из-за которого UI просто замер - Системные траблы (железо/ОС)

Условные показатели: <0,1–0,3% сессий с ANR

Где посмотреть: Android - Firebase Crashlytics → вкладка Crashes → фильтр по ANR (+ Embrace, Sentry, New Relic) iOS - Firebase Crashlytics, Embrace, Sentry

3. Crash Free Users Представь что ты заказываешь пицу с картошкой, жмякаешь Оплатить - бац! Вылет Дальше клиенты могут просто не пользоваться вашим приложением Причины вылетов: - Проблемы с памятью (OOM, утечка памяти) - Необработанные исключения (где-то забыли try-catch и прилетело необработанное исключение) - Несовместимость с версией ОС/SDK (приложение работает на Android 8, а ты используешь API из Android 16) - Недостаточно места на устройстве (напр бюджетные Android-приложение пытается распаковать что-то тяжелое, а система убивает) - Траблы с сетью и тд

Условные показатели: менее 0,5% - 1% сессий с крашем

Где посмотреть: Firebase Crashlytics + Firebase Performance

4. Плавность UI Jank rate (Android) процент кадров, которые опоздали и вызвали заметные подергивания, будто на ручнике едешь, пользователь видит эти подергивания при скролле, анимациях, переходах Hitch (iOS) похожая штука -задержки в рендере. Кадр опаздывает далее система пропускает 1–неск кадров и интерфейс дергается Обе метрики измеряют не плавность в среднем, а плохие моменты которые пользователь может заметить Причины лагов: - Долгие вычисления на главном потоке (делаешь тяжелые вычисления, парсишь JSON, считаешь зарплаты за 10 лет вперед) - Перегруженный рендер (слишком много прозрачности, огромные картинки без сжатия, overdraw (рисуешь один и тот же пиксель 12 раз) - Анимации, которые блокируют кадры - Низко-производительные устройства + высокая частота обновления //В Xcode 26 добавили XCTHitchMetric в тесты, можно ловить hitches автоматически

Условные показатели: меньше 5 ms hitch на секунду -отлично 10 ms -заметно больше 10 ms -все плохо

Где посмотреть: Android - библиотека от google -JankStats iOS - Instruments (Core Animation)