Аудит продуктивності мобільного додатка
Аудит продуктивності — це не "посмотреть, що тормозит". Це систематичне вимірювання конкретних метрик на конкретних пристроях з конкретними результатами. Без вимірювань будь-які оптимізації — здогадування. З вимірюваннями — приоритизований список проблем з зрозумілим ефектом від кожного виправлення.
Що вимірюємо
Час запуску
iOS: XCTest з measure(metrics:) + XCTApplicationLaunchMetric. Розділяємо cold launch (перший запуск після перезагрузки) та warm launch (повторний запуск). Apple рекомендує cold launch < 400 мс до першого відрисованого кадру. Типова проблема: статична ініціалізація в AppDelegate (SDK, базі даних, аналітика) — все синхронно на main thread.
Android: adb shell am start -W com.package/.MainActivity — показує TotalTime та WaitTime. Firebase Performance Monitoring автоматично збирає app_start метрики з реальних пристроїв. Частова причина повільного старту: занадто рання ініціалізація Room/Realm у Application.onCreate(), синхронний SharedPreferences read.
Розмір та споживання пам'яті
iOS: Xcode Memory Graph + утиліта leaks. Ищемо retain cycles (часто: closure захоплює self, self тримає closure). os_signpost для позначення часових міток у профайлері.
Android: Memory Profiler у Android Studio → Heap Dump. Дивимось на Leaked Activities (Activity не знищується через static reference), великі Bitmap об'єкти (неправильний inSampleSize при завантаженні зображень).
Швидкість рендеринга
iOS: Instruments → Core Animation. Offscreen-rendered content (червона підсвітка) — зайві CALayer операції. Color blended layers — overdraw прозорих шарів.
Android: adb shell dumpsys gfxinfo com.package framestats — статистика по кадрам. Slow frames > 5% — проблема. Також: systrace або Perfetto для детального trace.
Мережеві запити
Charles Proxy або mitmproxy — перехоплюємо всі запити додатка. Дивимось:
- Дублюючі запити за одними даними
- Відсутність кешування там, де воно доцільне
- Занадто великі payload (JSON без pagination, зображення без стиску)
- Відсутність HTTP/2 (особливо помітно при багатьох дрібних запитах)
Витрата батареї
iOS: Xcode Energy Impact gauge + MetricKit у продакшені. Android: Battery Historian (adb bugreport → аналіз у Battery Historian web tool).
Методологія аудиту
Аудит проводимо у три етапи:
1. Автоматизований збір базових метрик. Firebase Performance, Sentry Performance, або власний instrumentation. Дивимось P50/P75/P95 по launch time, screen render time, HTTP latency на реальних користувачах. Це показує, де проблема в масштабі.
2. Воспроизведення на пристроях. Два-три пристрої: флагман (останній iPhone/Pixel), mid-range (щось типу Samsung A54 / iPhone 12), low-end (4-річний mid-range Android). Проблеми на флагмені часто невоспроизводимі, а у 30–40% аудиторії саме mid-range та старіше.
3. Статичний аналіз коду. Ручний review ключових шляхів: onCreate/viewDidLoad, методи рендеринга, мережевий шар, робота з БД. Ищемо синхронні операції у UI thread, неоптимальні запити, відсутність debounce на user input.
Формат результатів
За підсумками аудиту — документ з таблицею проблем:
| Проблема | Метрика | Пристрій | Пріоритет |
|---|---|---|---|
Синхронний DB read у onCreate |
+340 мс до cold start | Samsung A54 | Високий |
| 8 паралельних запитів на старті | 600 мс TTFR | Всі | Високий |
| Retain cycle у ProfileViewController | +12 МБ витоку за сесію | iOS | Середній |
| Overdraw у FeedCell | 15% slow frames | Pixel 6a | Середній |
Кожна проблема — з воспроизводимими кроками, скриншотами з профайлера та конкретною рекомендацією по виправленню.
Терміни аудиту: три-п'ять робочих днів для додатка середнього масштабу (10–30 екранів). Великий додаток з кількома модулями — сім-десять днів.