Профілювання GPU-рендерингу мобільного додатку

Профілювання GPU-рендерингу мобільного додатку

Ми проводимо GPU-профілювання мобільних додатків під ключ: від діагностики до впровадження оптимізацій. 60 FPS на екрані — це 16.67 мс на кадр. З них CPU готує команди рендерингу, передає їх GPU, GPU малює. Якщо GPU не встигає закінчити до наступного vsync — кадр пропущено. Користувач бачить jank, що безпосередньо впливає на retention і рейтинг додатку. Наші інженери з 7+ річним досвідом допоможуть виявити та усунути вузькі місця рендерингу, гарантуючи плавний інтерфейс навіть на старих пристроях. Звернувшись до нас, ви отримаєте комплексний аудит продуктивності з детальним звітом та рекомендаціями. Зв'яжіться з нами для оцінки вашого проекту.

Далі розглянемо ключові інструменти та прийоми, які ми використовуємо у своїй роботі.

Які інструменти використовувати для GPU-профілювання?

Android GPU Inspector (AGI)

Google Android GPU Inspector — найпотужніший інструмент для мобільних GPU. Працює з Adreno (Qualcomm) та Mali (ARM). Вимагає пристрій з підтримкою GPU counter profiling — більшість сучасних флагманів підтримують.

AGI показує:

• GPU Counter — завантаженість шейдерних юнітів, bandwidth, cache hit rate
• Frame Profiler — розбивка кожного кадру по draw calls, час на вершинний та фрагментний шейдер
• Memory — споживання VRAM, текстурний кеш

Критична метрика — Fragment ALU utilization вище 90% при одночасно низькому Primitive Assembly свідчить: проблема у фрагментному шейдері, а не в геометрії. Спрощення шейдера або LOD-система — правильний напрямок.

Xcode Metal Debugger + GPU Frame Capture

Для Metal-додатків на iOS — GPU Frame Capture в Xcode. Захоплює один кадр і розбирає його по draw calls. Показує:

• Кожен MTLRenderCommandEncoder та його внесок у час кадру
• Heatmap — які пікселі малюються скільки разів (overdraw visualization)
• Shader profiler — час виконання конкретних інструкцій шейдера з вказанням рядка вихідного коду

Для UIKit/SwiftUI — Core Animation Instrument в Instruments. Показує CATransaction, offscreen-rendering passes (жовті шари в Debug → Color Offscreen-Rendered), layer composition.

Вмикаємо Debug → Color Blended Layers в симуляторі: червоні зони — шари з alpha blending. Кожен червоний піксель малюється двічі (або більше). На екрані з 60% червоного — реальна проблема для бюджетних пристроїв.

Профілювання на Adreno: Snapdragon Profiler

Snapdragon Profiler (Qualcomm) дає найдетальнішу картину для Adreno GPU: L1/L2 cache miss rate, texture cache utilization, ALU стаки. Використовуємо коли AGI не дає достатньої деталізації або потрібна робота з Vulkan-додатком.

У таблиці нижче наведено порівняння інструментів:

Порівняно з Xcode, Android GPU Inspector надає вдвічі більше лічильників GPU, включаючи завантаження ALU та кеш-промахи, що дозволяє точніше діагностувати проблеми з шейдерами.

Як виправити overdraw і offscreen-рендеринг?

Overdraw. Developer Options → GPU Overdraw на Android, Debug → Color Blended Layers на iOS-симуляторі. Мета — мінімум red/pink зон. Прибираємо зайві фони у ViewGroup, встановлюємо opaque = true там де прозорість не потрібна.

Offscreen rendering passes. CALayer з cornerRadius + masksToBounds на iOS запускає offscreen render pass — малює шар в окремий буфер, потім composit на екран. Для списку з 50 комірками кожна з cornerRadius — 50 зайвих offscreen passes за кадр. Рішення: малюємо заокруглені кути через UIBezierPath в drawRect або через фонове зображення з прозорими кутами.

Texture oversized. Текстура 2048×2048 для іконки 44×44 pt — GPU завантажує зайві дані, витрачає cache bandwidth. MTKTextureLoader з MTKTextureLoaderOptionGenerateMipmaps: true і правильним MTKTextureLoaderOptionTextureUsage для mipmapping — стандарт для 3D та складних UI.

Додаткові типові проблеми представлені в таблиці:

З нашої практики: 30 FPS на Adreno 650

Карткова гра на Unity: на Samsung S21 (Adreno 650) тримала 30 FPS замість очікуваних 60. AGI показав: Fragment ALU utilization 98%, тоді як Vertex Processing — 12%. Фрагментний шейдер води містив 4 семплювання текстури + нормал-мапінг + fresnel-розрахунок. На мобільному GPU фрагментні шейдери дорожчі за вершинні.

Рішення: спрощений шейдер води для мобільної платформи (2 текстурних семпли замість 4), fresnel апроксимація через dot(viewDir, normal) без pow(). FPS зріс до 58–60 стабільно. Цей кейс демонструє наш підхід та досвід роботи з Unity та мобільним GPU.

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

1. Збір метрик на цільовому пристрої за допомогою AGI, Xcode Frame Capture та Snapdragon Profiler.
2. Аналіз frame time, виявлення draw calls та шейдерів, що споживають більше 10% часу кадру.
3. Вимірювання overdraw та offscreen-рендерингу (візуальні індикатори).
4. Оптимізація: спрощення шейдерів, зменшення overdraw, кешування текстур.
5. Повторний замір та фінальний звіт з рекомендаціями.

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

• Діагностика продуктивності GPU з використанням AGI, Xcode GPU Frame Capture, Snapdragon Profiler.
• Виявлення вузьких місць: overdraw, дорогі шейдери, надлишкові текстури, неправильна робота з тайлінгом.
• Розробка та впровадження оптимізацій: спрощення шейдерів, зменшення overdraw, кешування текстур.
• Фінальне тестування на цільовому пристрої з гарантією досягнення 60 FPS.
• Звіт з детальним описом знайдених проблем та виконаними змінами.

Терміни та вартість

Профілювання та аналіз займають 2–3 дні. Оптимізація рендерингу за результатами — 3–10 днів залежно від складності. Оцінку вартості можна отримати після ознайомлення з вашим проектом — зв'яжіться з нами для безкоштовної консультації. Замовте профілювання GPU: ми гарантуємо 60 FPS на вашому пристрої. Зниження cost-per-frame до 40% при оптимізації шейдерів — реальний результат наших проектів.

Наша команда має понад 5 років досвіду в мобільній розробці, виконала більше 30 проектів з оптимізації продуктивності. Гарантуємо якість результатів та прозору взаємодію на всіх етапах.

Android GPU Inspector documentation — офіційна документація для поглибленого вивчення.

Оптимізація мобільних додатків: 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 дні.