Уявіть: користувач відкриває ваш застосунок, бачить білий екран 4 секунди, а потім — завислий список. Це не баг, а системна проблема продуктивності. У App Store застосунок із повільним запуском отримує оцінки нижче 4.0, а утримання падає на 20% за першу хвилину. Аудит продуктивності — не разова перевірка, а методологія збору та аналізу метрик: час старту, рендеринг, пам'ять, мережа, батарея. Ми, інженери з понад 5-річним досвідом, проводимо аудит на реальних пристроях і даємо пріоритизований звіт із вимірними рекомендаціями. Без даних ви гадаєте — зі звітом ви точно знаєте, що виправляти і який ефект отримаєте.
Наприклад, в одному проєкті ми скоротили cold launch з 4.2 с до 380 мс, видаливши синхронну ініціалізацію чотирьох SDK в AppDelegate. Це збільшило реєстрації на 7%. Хочете те саме для вашого застосунку? Продовжуйте читати.
Які метрики ми вимірюємо?
Ми фокусуємося на п'яти аспектах, які безпосередньо впливають на утримання користувачів і рейтинг у сторах.
Час запуску (Launch Time)
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.
Мережа
Charles Proxy або mitmproxy. Перевіряємо: дублюючі запити, відсутність кешування, великі payload (JSON без пагінації, нестиснуті зображення), відсутність HTTP/2.
Батарея
iOS: Xcode Energy Impact + MetricKit. Android: Battery Historian (adb bugreport).
Чому аудит продуктивності вигідний?
Зниження часу запуску на 300 мс збільшує конверсію в реєстрацію на 3-5% (галузеві дослідження). Зменшення slow frames з 10% до 1% підвищує оцінки в Store на 0.3-0.5 бала. Аудит дає вимірний ROI: ви вкладаєте 3-10 днів команди та отримуєте приріст метрик, конкурентоспроможність та зниження навантаження на підтримку. Середня економія бюджету на доопрацювання — від 15%. Окупність аудиту становить від 3 до 6 місяців за рахунок скорочення часу на баг-фіксинг та підтримку.
Як проходить аудит: покроково
- Збір базових метрик. Автоматизовано збираємо Firebase Performance, Sentry Performance або власний інструментарій. Дивимося P50/P75/P95 за launch time, screen render, HTTP latency на реальних користувачах.
-
Аналіз коду. Статичний аналіз ключових шляхів:
onCreate/viewDidLoad, методи рендерингу, мережевий шар, робота з БД. Шукаємо синхронні операції в UI thread, неоптимальні запити, відсутність debounce. - Відтворення на пристроях. Два-три пристрої: флагман, mid-range, low-end. Проблеми на флагмані часто невідтворювані, а у 30–40% аудиторії саме mid-range та старші.
- Формування звіту. Складаємо таблицю проблем із пріоритетами, кроками відтворення, скріншотами та рекомендаціями. Додаємо графіки розподілу метрик та порівняння до/після.
Що входить у звіт?
За підсумками аудиту — документ із таблицею проблем:
| Проблема | Метрика | Пристрій | Пріоритет |
|---|---|---|---|
Синхронний DB read в onCreate |
+340 мс до cold start | Samsung A54 | Високий |
| 8 паралельних запитів на старті | 600 мс TTFR | Всі | Високий |
| Retain cycle в ProfileViewController | +12 МБ витік за сесію | iOS | Середній |
| Overdraw в FeedCell | 15% slow frames | Pixel 6a | Середній |
Кожна проблема — з кроками відтворення, скріншотами та рекомендацією. Додатково додаємо: вихідний код із вимірюваннями, графіки розподілу метрик, порівняння до/після.
Типові проблеми продуктивності
- Статична ініціалізація SDK в головному потоці - Відсутність пагінації при завантаженні списків - Retain cycles через замикання в iOS - Синхронні операції з БД на Android - Надмірні перемальовки вкладених RecyclerViewТерміни аудиту
| Розмір застосунку | Термін |
|---|---|
| 10–30 екранів | 3–5 робочих днів |
| Великий (кілька модулів) | 7–10 робочих днів |
Точний термін розраховується індивідуально після знайомства з проєктом. Замовте аудит зараз — отримайте звіт із пріоритетами через 3-5 днів. Зв'яжіться з нами для попередньої оцінки вашого проєкту.
Гарантуємо конфіденційність коду та даних. Досвід роботи із застосунками з фітнесу, банкінгу, маркетплейсів, edtech. Замовте аудит, і ми покажемо, наскільки швидше може працювати ваш застосунок.
Згідно з iOS Performance Guidelines від Apple, cold launch не повинен перевищувати 400 мс.