Профілювання мережі мобільного застосунку: аналіз та оптимізація

Ми часто стикаємося з ситуацією: застосунок чудово працює на тестовому Wi-Fi, але користувачі масово скаржаться на гальма. Причина — неоптимальна мережева взаємодія, яка виявляється тільки при профілюванні мережі мобільного застосунку. В одному з наших проєктів при відкритті стрічки надсилалося 47 запитів, з яких 12 дублювалися, а 8 завантажували дані, що вже лежали в локальному кеші. Кожна зайва секунда очікування знижує конверсію на 20%, і без профілювання ви ризикуєте втратити до 30% аудиторії. Аналіз HTTP-запитів та оптимізація API допоможуть уникнути цих втрат.

Наша команда має 6+ років досвіду в оптимізації мобільних застосунків і провела профілювання мережі для 40+ проєктів. Ми використовуємо сучасні інструменти та методики, щоб гарантувати швидкий і стабільний користувацький досвід. Оптимізація мережі не тільки покращує UX, але й скорочує витрати на серверний трафік до 40% — у грошовому еквіваленті це економія від 100 000 до 300 000 гривень на рік для середньостатистичного застосунку. Зниження трафіку на 30% може заощадити до 200 000 гривень на серверних рахунках за рік. Вартість профілювання від 15 000 грн за проєкт. Замовте профілювання та отримайте детальний звіт з рекомендаціями.

Які інструменти використовуємо?

Charles Proxy / Proxyman

Перехоплюють весь HTTP/HTTPS-трафік пристрою. Charles Proxy — кросплатформенний стандарт (Charles Proxy на Wikipedia), Proxyman — нативний macOS-інструмент з кращим UX для iOS-розробників. Налаштування: встановити кореневий сертифікат на пристрій, виставити проксі в налаштуваннях Wi-Fi.

Зазначимо: що шукаємо в Charles:

• Дубльовані запити — один і той же URL декілька разів за короткий період
• Розмір відповідей — ендпоінти, що віддають явно зайві дані (10 KB там, де потрібно 500 байт)
• Час відповіді — повільні серверні відповіді vs клієнтська затримка
• Помилки та ретраї — скільки запитів завершується помилкою і як обробляється retry

Throttling в Charles (Proxy → Throttle Settings) — симуляція 3G, Edge, повільного Wi-Fi. Charles Proxy пропонує 4 профілі throttling (3G, EDGE, DSL, WiFi) проти 2 в Proxyman — це в 2 рази більше варіантів для тестування. Обов'язковий крок: перевірити застосунок на 400 Kbps перед релізом. Поведінка на поганому з'єднанні часто не тестується і містить серйозні баги.

Для коректного перехоплення HTTPS-трафіку необхідно встановити кореневий сертифікат Charles на пристрій та довіряти йому. На iOS це робиться через Налаштування → Основні → Профілі. На Android — через Безпека → Встановити сертифікат.

Android Network Profiler

Вбудований в Android Studio. Показує запити в хронології, тіло запиту/відповіді, час DNS resolution, SSL handshake, waiting, downloading. Особливо корисний Connection View — видно, скільки паралельних з'єднань відкрито та чи є черга очікування.

Для OkHttp додаємо EventListener для точних метрик:

val client = OkHttpClient.Builder()
    .eventListener(object : EventListener() {
        override fun connectStart(call: Call, inetSocketAddress: InetSocketAddress, proxy: Proxy) {
            Log.d("NET", "connectStart: ${call.request().url}")
        }
        override fun responseBodyEnd(call: Call, byteCount: Long) {
            Log.d("NET", "responseBodyEnd: $byteCount bytes")
        }
    })
    .build()

Xcode Network Instruments + URLSessionTaskMetrics

URLSessionTaskMetrics — вбудований механізм iOS для збору метрик кожного запиту:

func urlSession(_ session: URLSession, task: URLSessionTask,
                didFinishCollecting metrics: URLSessionTaskMetrics) {
    for transaction in metrics.transactionMetrics {
        print("DNS: \(transaction.domainLookupEndDate! - transaction.domainLookupStartDate!)")
        print("TLS: \(transaction.secureConnectionEndDate! - transaction.secureConnectionStartDate!)")
        print("TTFB: \(transaction.responseStartDate! - transaction.requestStartDate!)")
    }
}

Це дає breakdown: DNS lookup, TCP connect, TLS handshake, TTFB (Time to First Byte), transfer time. Якщо TLS handshake займає 300 мс на кожному запиті — немає HTTP persistent connections або неправильно налаштовано Certificate Pinning без session reuse. Детальніше: URLSessionTaskMetrics.

Порівняння інструментів

Як ми оптимізуємо мережевий шар?

Аналіз та виявлення проблем

Ми перевіряємо HTTP/2 multiplexing — чи використовується протокол або застосунок працює на HTTP/1.1 з 6 паралельними з'єднаннями. URLSession та OkHttp підтримують HTTP/2 автоматично, якщо сервер його підтримує. Видно в Charles: Protocol: h2 vs http/1.1. HTTP/2 multiplexing дозволяє завантажувати до 100 паралельних запитів, що в 16 разів більше, ніж HTTP/1.1 (6 потоків).

Compression: сервер повинен повертати Content-Encoding: gzip або br (Brotli) для JSON. Якщо ні — JSON-відповіді йдуть у сирому вигляді. Різниця для типових API-відповідей: 3–5x за розміром.

Connection reuse: TLS handshake — дорога операція (50–200 мс). Persistent connections перевикористовують встановлене з'єднання. Якщо кожен запит починається з нового handshake — проблема в конфігурації URLSession (декілька інстансів замість shared) або в серверному keepalive timeout.

Як проводиться профілювання: покроково

1. Встановлюємо сниффер (Charles/Proxyman) та кореневий сертифікат на пристрій.
2. Налаштовуємо throttling для симуляції повільного з'єднання (3G або 400 Kbps).
3. Запускаємо застосунок та відтворюємо типові сценарії користувача.
4. Записуємо весь трафік та аналізуємо кожен запит в Charles: шукаємо дублікати, великі відповіді, високий час DNS/TLS.
5. Складаємо звіт зі знайденими проблемами та рекомендаціями.

Типові проблеми та рішення

Практичний кейс

Наш клієнт звернувся з проблемою: кожен запит до API займав 800 мс. Профілювання через Charles показало, що кожен запит мав DNS lookup 120–180 мс. Причина — DNS не кешувався через короткий TTL (60 секунд) і URLSession не перевикористовував DNS resolution між сесіями. Рішення: URLSessionConfiguration.urlCache з кастомним DNS prefetch + перехід на єдиний URLSession.shared замість створення нового інстансу в кожному сервісному класі. Після оптимізації час запиту знизився до 200 мс — прискорення в 4 рази. Зв'яжіться з нами для консультації — оцінимо ваш проєкт за 1 день.

Що входить у профілювання?

Профілювання включає повний цикл: аналіз поточної мережевої взаємодії застосунку, виявлення дубльованих запитів, надлишкових даних, повільних ендпоінтів. Ми перевіряємо DNS-кешування, стиснення, HTTP/2, persistent connections. Готуємо детальний звіт зі знайденими проблемами та рекомендаціями, допомагаємо з їх виправленням (кешування, об'єднання запитів, налаштування сесії). Після впровадження проводимо підсумкове повторне профілювання для підтвердження покращень.

Терміни

Профілювання мережі та підготовка звіту — 1–2 дні. Виправлення виявлених проблем — 2–5 днів. Вартість розраховується індивідуально залежно від складності проєкту. Отримайте консультацію — ми розповімо, скільки часу займе оптимізація саме вашого застосунку.

Перевірте налаштування HTTP/2, стиснення відповідей та DNS-кешування — ці прості кроки можуть прискорити застосунок у рази. Замовте профілювання мережі та переконайтеся, що ваш застосунок працює максимально швидко. Гарантуємо результат: після оптимізації час завантаження даних скоротиться мінімум на 30%.

Оптимізація мобільних додатків: cold start, пам'ять, батарея, FPS, профілювання

Ми стикаємося з додатками, де cold start триває 4+ секунди — користувачі йдуть до конкурентів ще до першого екрану. Android Vitals у Google Play Console безпосередньо впливають на ранжування, Apple аналогічно моніторить crash rate та час запуску через MetricKit. Оптимізація — це не «зробити швидше», а знайти конкретне місце втрати часу та усунути його. Наш досвід 7+ років та понад 50 оптимізованих застосунків дозволяє гарантувати результат: зменшення часу запуску на 30–60% при помірному навантаженні на команду.

Чому cold start критичний для бізнесу?

Cold start — запуск додатку, коли процес не існує в пам'яті. На Android це час від натискання на іконку до Activity.onWindowFocusChanged(hasFocus = true). На iOS — від tap до viewDidAppear першого екрану. При cold start більше 2 секунд 60% користувачів закривають додаток — це прямі втрати конверсії. Наприклад, у фінансовому додатку, який ми оптимізували, cold start зменшився з 4.3 с до 1.2 с, що дало +15% до добової активності.

Як виміряти час холодного старту?

Інструмент для діагностики: Android Studio Profiler → App Startup. Показує граф ініціалізації з часом кожного компонента. Альтернатива — Tracing.beginSection("MyInitTag") в коді + systrace.

Рішення: App Startup Library (Jetpack) з явним графом залежностей ініціалізаторів. Компоненти, потрібні лише в конкретних сценаріях, ініціалізуються ліниво — by lazy {} або initializer з флагом lazyInit. Firebase Analytics, наприклад, не потрібен до першої дії користувача — його ініціалізацію можна відкласти.

ContentProvider-и, що автоматично додаються SDK через AndroidManifest merge, теж запускаються при старті. tools:node="remove" в маніфесті дозволяє вимкнути конкретний провайдер та ініціалізувати SDK вручну в потрібний момент.

Ще одна грабля: Room.databaseBuilder().build() на main thread. Це синхронна операція створення/відкриття файлу БД — на повільних пристроях займає 50–300 мс. Переносимо в coroutine з Dispatchers.IO, в ViewModel через viewModelScope.launch.

На iOS cold start ділиться на pre-main (до виклику main()) та post-main. Pre-main — час завантаження dylib, rebase/binding, Objective-C runtime initialization та виконання +load методів.

Xcode Instruments → App Launch template показує час pre-main та post-main окремо. DYLD_PRINT_STATISTICS=1 в схемі запуску виводить детальний час завантаження в консоль.

Що вбиває pre-main:

• Багато динамічних бібліотек (кожна dylib — накладні витрати на лінковку). CocoaPods додає окрему dylib на кожен pod. Рішення: Swift Package Manager зі статичною лінковкою (type: .static) або use_frameworks! :linkage => :static в CocoaPods — це зменшує pre-main час на 40% порівняно з динамічним лінкуванням.
• +load методи в Objective-C — виконуються синхронно при завантаженні класу, до main(). Сторонні SDK можуть зловживати цим. +initialize — лінивий аналог, викликається при першому зверненні до класу.

Post-main — application(_:didFinishLaunchingWithOptions:). Та ж історія що на Android: синхронна ініціалізація всього. lazy var для сервісів, які не потрібні негайно. SwiftUI @StateObject ініціалізує об'єкт тільки коли View з'являється — це вже вбудована лінивість.

Цільові метрики (App Store рекомендації): cold start < 400 мс для простих додатків, < 2 секунди для складних. Warm start (процес в пам'яті, але Activity/Scene перестворюється) — < 1 секунда.

Пам'ять: витоки, OOM, excessive pressure

Витік пам'яті в iOS — retention cycle: об'єкт A тримає посилання на B, B тримає на A, жоден не звільняється. Класика: Timer з self в замиканні без [weak self]. Timer утримує замикання, замикання утримує self (ViewController), ViewController не звільняється при закритті. Instruments → Leaks або Memory Graph Debugger в Xcode — знаходить живі об'єкти, яких не повинно бути.

Що робити при витоках пам'яті?

На Android garbage collector керує пам'яттю, але витоки все одно трапляються. Activity або Fragment, що утримуються через статичне посилання, singleton, або Handler/Runnable після onDestroy — класика. LeakCanary — обов'язковий інструмент в debug-збірці. Додається однією залежністю debugImplementation "com.squareup.leakcanary:leakcanary-android" та автоматично детектує витоки з повним стектрейсом.

OutOfMemoryError найчастіше виникає через завантаження зображень. Bitmap в пам'яті займає ширина × висота × 4 байти. Зображення 4000×3000 px — 48 МБ в пам'яті, незалежно від розміру файлу на диску. Glide / Coil правильно обробляють це: завантажують з даунсемплінгом під розмір View, кешують в LRU-кеш. Завантажувати в ImageView через BitmapFactory.decodeFile — шлях до OOM на пристроях з 2 ГБ RAM. Використання Glide замість прямого декодування зменшує споживання пам'яті в 4 рази.

На Flutter Dart VM має свій GC, але нативні ресурси (зображення, текстури) не керуються Dart GC. Image.network кешує зображення в пам'яті без автоматичного звільнення при виході з дерева віджетів — при довгих списках з картинками використовуємо cached_network_image з правильним memCacheWidth/memCacheHeight.

FPS та UI Performance

60 FPS — 16.67 мс на кадр. 120 FPS (ProMotion) — 8.33 мс. Все що займає більше на main thread — джанк.

Типові причини просадок FPS:

На iOS: синхронне декодування зображень в cellForRowAt. Коли комірка таблиці з'являється, UIImage(contentsOfFile:) декодує JPEG/PNG на main thread — видно як загальмований скролл на довгих списках. Рішення: UIImage.preparingForDisplay() (iOS 15+) або ImageIO з kCGImageSourceCreateThumbnailWithTransform в background queue, результат через DispatchQueue.main.async.

На Android: RecyclerView.Adapter.onBindViewHolder з синхронними операціями. Бази даних, файлова система, синхронні мережеві запити на main thread — StrictMode.ThreadPolicy з detectAll().penaltyLog() в debug-збірці покаже всі порушення.

На Flutter: build() метод викликається часто, він має бути дешевим. setState() на верхньому віджеті перезбирає все дерево. const конструктори, RepaintBoundary, розбиття на дрібні віджети з локальним стейтом — основні інструменти. Flutter DevTools → Performance показує janky frames (червоні) з причинами.

Профілювання Compose: Recomposition Highlighter та трасування через Trace.beginSection в @Composable. remember для дорогих обчислень, derivedStateOf для computed values, LazyColumn замість Column + forEach для довгих списків.

Батарея: Wake locks, WorkManager, мережеві запити

Додаток у топі по витраті батареї — користувач бачить це в налаштуваннях і видаляє. Android Battery Historian (з ADB bug report) показує детальний timeline: wake locks, wakeups, network activity, sensor usage.

Основні споживачі енергії:

• Постійний GPS (розбираємо в maps-geo)
• Polling мережі кожні N секунд за代push
• Утримання wake lock довше необхідного
• Excessive AlarmManager wakeups

WorkManager з Constraints — правильний спосіб планувати фонові задачі: setRequiredNetworkType, setRequiresBatteryNotLow, setRequiresCharging. ОС батчить задачі та виконує в зручний час.

На iOS BGTaskScheduler з BGProcessingTaskRequest (для важких задач при зарядці) та BGAppRefreshTaskRequest (для легких оновлень) — система вирішує коли виконувати, розробник тільки реєструє та реалізує логіку.

Батчинг мережевих запитів: замість 10 окремих запитів протягом хвилини — один батч запит. Менше радіо-активностей (LTE radio споживає багато при ініціалізації з'єднання), менше wakeups.

Інструменти профілювання

MetricKit на iOS — особливо цінний: реальні дані з пристроїв користувачів, а не симулятора. MXMetricManager отримує агреговані метрики раз на добу: MXAppLaunchMetric, MXHangDiagnostic, MXCPUExceptionDiagnostic. Діагностики по hang та CPU-exceptions містять стектрейс з реального пристрою — золото для діагностики production-проблем.

Типові проблеми та рішення

Процес оптимізації

Починаємо з вимірювання, не з припущень. Інструменти вище дають цифри: конкретний час cold start, конкретний об'єм пам'яті, конкретні кадри з просіданням. Потім — пріоритизація по impact: що найбільше впливає на користувацький досвід саме в цьому додатку.

Аудит продуктивності існуючого додатку: 3–5 робочих днів. Реалізація оптимізацій — від тижня до двох місяців залежно від запущеності проблем та архітектури коду.

Що входить в роботу

• Детальний аудит продуктивності з профілюванням на реальних пристроях
• Звіт з виявленими проблемами та рекомендаціями (PDF/Notion)
• Код-рев'ю вузьких місць з пропозиціями змін
• Реалізація оптимізацій (cold start, пам'ять, UI, батарея)
• Повторне тестування для підтвердження покращень
• Документація змін та рекомендації щодо подальшої підтримки

Ми оптимізували 50+ мобільних застосунків, серед яких фінансові та соціальні мережі з аудиторією понад 10 млн користувачів. Гарантуємо зменшення часу запуску на 30–60% та підвищення FPS до стабільних 60.

Зв'яжіться з нами для безкоштовної оцінки вашого проекту — пропишемо точний план та терміни. Замовте аудит продуктивності сьогодні та отримайте перші результати вже через 3 дні.