Чому фотофільтри гальмують на смартфонах
Коли фільтр накладається на кадр у момент зйомки, користувач очікує результат миттєво — і саме тут вилазить вузьке місце.
Класична обробка зображень на CPU ганяє пікселі через один потік обчислень: поки ядро послідовно рахує згортку за згорткою, передперегляд відстає від реальності на частки секунди.
На одиночному знімку це непомітно, але в серійній зйомці черга кадрів зростає, буфер переповнюється, і затримка передперегляду стає видна оком — палець уже змістився, а на екрані ще попередній кадр.
Далі вмикається фізика. Процесор, завантажений покадровою обробкою, уходить у постійне навантаження на всі ядра — смартфон гріється, спрацьовує тепловий тротлінг, і частота кадрів просідає тим сильніше, чим довше триває зйомка.
Пік за температурою припадає рівно на той момент, коли користувач знімає серію або гортає стрічку з фільтрами, — тобто на найнавантаженіший сценарій. Застосунок починає «жувати» інтерфейс, а батарея сідає швидше, ніж при звичайній зйомці без ефектів.
GPU-фільтри знімають це навантаження з процесора і переносять обчислення туди, де вони доречні — на графічне ядро, розраховане на паралельну роботу з тисячами пікселів одночасно.
Один прохід по кадру замість десятків послідовних операцій, передперегляд оновлюється в темпі екрана, а не в темпі черги. Тепловий профіль вирівнюється: графічне ядро віддає результат швидше і уходить у простій, замість того щоб тримати процесор розпеченим.
Розбираємо, як це закривається на практиці — від вибору шляху обробки до колірних таблиць, які дають однаковий результат на різних пристроях.
Що дає перенесення фільтрів на графічний прискорювач
Фільтр на графічному прискорювачі обчислюється паралельно по пікселях: покадрова обробка кадру вкладається в один прохід по конвеєру, тоді як на центральному процесорі ті самі операції йдуть послідовно і конкурують за ядра з інтерфейсом, мережею та логікою застосунку.
Звідси перший вимірюваний ефект — швидкість відгуку: передперегляд фільтра в реальному часі оновлюється без затримки між жестом користувача та зображенням, а важкі ланцюжки з кількох ефектів перестають «наздоганяти» палець.
Другий ефект — стабільність кадрів. Коли обчислення йдуть на прискорювач, час обробки кадру стає передбачуваним, і частота кадрів тримається рівною навіть при накладенні складних шарів, тексту та масок.
Провали й посмикування, які користувач читає як «застосунок гальмує», зникають — а разом з ними зникає й частина негативних відгуків, які зазвичай списують на «сирий» застосунок.
Третій ефект — енергоспоживання та ресурс пристрою. Графічний конвеєр виконує ту саму роботу за меншу кількість тактів і з меншим нагрівом корпусу, тому телефон не йде в тротлінг після кількох хвилин зйомки, а батарея витрачається рівніше.
Для сценаріїв із тривалою обробкою — серійна зйомка, пакетний експорт, запис відео з фільтром — це різниця між «працює півгодини й гріється» та «працює стільки, скільки потрібно».
Практичний висновок: перенесення фільтрів на прискорювач — це не косметика, а зміна класу поведінки застосунку під навантаженням.
Ми профілюємо кожен ланцюжок ефектів, знімаємо заміри до і після та залишаємо лише ті оптимізації, які реально видно в метриках відгуку, кадрів і витрати батареї.
Підходи до реалізації фільтрів: порівняння варіантів
Вибір способу обробки визначає, як застосунок поводитиметься на різних пристроях і скільки коштуватиме підтримка. Нижче — три реальні підходи, між якими обирають на старті, та їхні обмеження щодо кросплатформності й контролю над результатом.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Вбудовані засоби платформи | Швидкий запуск, типові ефекти, мінімум коду | Різний набір ефектів і кольоропередача на iOS та Android, слабкий контроль над нестандартними сценаріями |
| Таблиці кольорокорекції | Єдиний візуальний стиль, робота з кольором і тоном | Потребують акуратної підготовки та інтерполяції, при неправильному налаштуванні втрачаються деталі в тінях і світлах |
| Власні обчислювальні модулі | Нестандартні ефекти, повний контроль над конвеєром | Дорожчі в розробці та підтримці, потрібна окрема оптимізація під кожну платформу |
Вбудовані засоби платформи дають найкоротший шлях: обробка лягає на системні модулі, а команда не пише шейдери вручну. Плата — розбіжність результату між платформами: той самий ефект на iOS і Android виглядає по-різному, і досягти єдиного стилю доводиться обхідними шляхами.
Таблиці кольорокорекції розв'язують саме це завдання: стиль описується один раз і однаково відтворюється на обох платформах. Обмеження — у підготовці самих таблиць і в тому, що складні ефекти, зав'язані на геометрію або розпізнавання, ними не виразити.
Власні обчислювальні модулі дають повний контроль: нестандартні ефекти, точне налаштування конвеєра, передбачувана продуктивність. Ціна — вища трудомісткість і необхідність підтримувати код під кожну платформу окремо.
На практиці конвеєр часто збирають комбіновано: базовий шар на вбудованих засобах, стиль — таблицями, а унікальні ефекти — своїм модулем. Такий гібрид закриває і швидкість запуску, і єдиний вигляд, і нестандартні сценарії.
Етапи впровадження прискореної обробки зображень
Роботу починаємо з аудиту поточного конвеєра: вимірюємо, скільки часу займає обробка кадру на референсних пристроях, де вузьке місце — декодування, сам фільтр чи виведення на екран, і які операції виконуються на процесорі, хоча їх можна перенести на графічний прискорювач.
За результатами аудиту видно, які фільтри дають просідання частоти кадрів і на яких моделях пристроїв застосунок починає «гальмувати».
- Аудит конвеєра. Знімаємо профіль обробки на живих пристроях із різних цінових сегментів, фіксуємо час на кадр і споживання ресурсів, визначаємо операції-кандидати на перенесення.
- Проєктування схеми обробки. Вирішуємо, які кроки йдуть на графічний прискорювач, які залишаються на процесорі, як будується ланцюжок фільтрів без зайвих копіювань буфера між пам'яттю та відеопам'яттю.
- Налаштування шейдерів і таблиць кольорокорекції. Пишемо програми для прискорювача та готуємо таблиці перетворення кольору — вони дозволяють змінювати стиль фільтра без перезбирання застосунку.
- Складання конвеєра під обидві платформи. Один і той самий набір фільтрів реалізуємо для iOS та Android з урахуванням відмінностей у графічних інтерфейсах, щоб візуальний результат збігався.
- Перевірка на пристроях. Проганяємо фільтри на парку реальних моделей: дивимося частоту кадрів, нагрівання, витрату батареї та коректність кольору на різних екранах.
- Оптимізація за результатами вимірювань. Прибираємо зайві проходи, кешуємо проміжні результати, знижуємо навантаження на слабких пристроях через спрощені версії фільтрів.
- Передача системи. Віддаємо налаштований конвеєр, документацію щодо додавання нових фільтрів та інструкції щодо вимірювання продуктивності, щоб команда замовника могла розвивати обробку самостійно.
Кожен етап закінчується вимірюваним результатом: після аудиту зрозуміло, що саме гальмує; після налаштування шейдерів — скільки кадрів за секунду дає фільтр на слабкому пристрої; після перевірки — які моделі потребують спрощеного режиму.
Такий порядок прибирає переробки: спочатку вимір, потім рішення, потім підтвердження на живому парку пристроїв.
Що замовник отримує після впровадження
Впровадження GPU-фільтрів закінчується не демонстрацією ефекту, а набором артефактів, за якими команда замовника може розвивати та супроводжувати обробку зображень без нас. Нижче — що саме залишається в проєкті після здачі.
- Конфігурації графічного конвеєра — профілі під цільові моделі пристроїв: де обчислюється на графічному ядрі, де на центральному процесорі, які формати текстур і проміжних буферів використовуються. Профілі лежать у репозиторії та перемикаються без перезбирання логіки фільтрів.
- Схеми конвеєра обробки — порядок проходження кадру: декодування, геометрія, кольорокорекція, накладання ефектів, виведення. Схема фіксує, на якому кроці втрачається якість і де вузьке місце за часом обробки.
- Набори таблиць кольорокорекції — самі таблиці під кожен стиль, правила їх змішування та інтерполяції, а також еталонні кадри «до/після» для перевірки, що стиль не «поплив» після правок.
- Конфігурації попереднього перегляду в реальному часі — параметри, за яких картинка у видошукачі збігається з фінальним результатом, щоб користувач не отримав сюрприз після збереження.
- Документація зі збирання та залежностей — які версії бібліотек і інструментів використовуються, як збирати під кожну платформу, що змінюється при оновленні графічного стеку.
- Регламенти випуску та відкату — як перевіряти новий фільтр перед релізом, за якими метриками часу обробки та якості вважати його готовим, як повернути попередній набір таблиць, якщо стиль або швидкість не влаштували.
- Інструкція для дизайнерів і контент-команди — як додавати нові таблиці кольорокорекції та стилі без участі розробників.
Кожен пункт передається в робочому вигляді: конфігурації та таблиці — у репозиторії з історією змін, схеми та регламенти — у документації проєкту.
Команда замовника може змінювати стилі та налаштовувати продуктивність самостійно, а ми залишаємося на підтримці там, де потрібні доопрацювання конвеєра.
Кейс: прискорення фільтрів у застосунку для обробки фото
Застосунок для обробки фото з бібліотекою пресетів: попередній перегляд фільтра відставав від руху повзунка на 300–400 мс, на середньому сегменті пристроїв частота кадрів просідала до 18–22, а через 10 хвилин зйомки корпус помітно нагрівався і система скидала яскравість екрана.
Користувачі сприймали це як «фільтр гальмує» і йшли налаштовувати кадр у сторонньому редакторі — конверсія у збереження результату падала.
Що було до змін
Обробка йшла на центральному процесорі: повний кадр у високій роздільній здатності проганявся через ланцюжок попіксельних операцій на кожен зсув повзунка, а результат віддавався в інтерфейс без проміжного буфера.
Звідси три пов'язані проблеми: затримка відгуку, просідання кадрів під час перетягування і постійне навантаження на обчислювальний блок, через яке пристрій грівся. Пресети зберігалися як набори параметрів і перераховувалися заново при кожній зміні.
Що змінили
Наші інженери перенесли розрахунок на графічний конвеєр і перевели пресети в таблиці кольорокорекції — компактні файли, які застосовуються до кадру однією операцією замість ланцюжка.
Попередній перегляд став рахуватися на зменшеній копії кадру, а повна роздільна здатність підключається лише в момент збереження. Проміжні результати кешуються, тому повторний вибір того самого пресета не запускає розрахунок заново.
Метрики після
| Показник | До | Після |
|---|---|---|
| Затримка попереднього перегляду | 300–400 мс | 30–50 мс |
| Частота кадрів під час перетягування | 18–22 | стабільно 55–60 |
| Нагрів за 10 хвилин зйомки | помітний, скидання яскравості | у межах норми |
| Час збереження кадру | 1,8–2,5 с | 0,4–0,7 с |
Окремо перевірили поведінку на пристроях минулих поколінь: там частота кадрів тримається на рівні 40–45, чого достатньо для плавного попереднього перегляду. Логіка пресетів винесена в окремий шар — новий набір кольорокорекції додається без перезбирання ядра обробки.
Проєкт вів наша команда — від профілювання вузького місця до викату в магазини застосунків.
Чим відрізняється таблиця кольорокорекції від обчислювального шейдера?
Таблиця кольорокорекції — це заздалегідь розрахована карта відповідності: кожному вхідному відтінку зіставлено вихідний. Вона застосовується як одна операція вибірки з текстури, тому на кадр витрачається передбачуваний час незалежно від складності самої корекції.
Художник готує таблицю у звичному редакторі, вивантажує у стандартний формат, і застосунок просто підставляє її — без перезбирання коду під кожну нову палітру.
Обчислювальний шейдер — це програма, яка виконується на графічному процесорі й рахує колір за формулою: змішує канали, будує криві, враховує яскравість сусідніх пікселів, накладає маски за тоном або насиченістю.
Він уміє те, що таблиця не виразить у принципі — локальні ефекти, що залежать від вмісту кадру, а не лише від значення одного пікселя.
Різниця проявляється у трьох місцях. Гнучкість: таблиця — фіксоване перетворення, шейдер — будь-яка математика. Вартість: таблиця дешевша й стабільніша за часом кадру, шейдер потребує більше обчислень і пам'яті під проміжні буфери. Супровід: таблицю змінює дизайнер без розробника, шейдер — лише правка коду й новий реліз.
Вибір підходу диктує задача. Масові пресети «теплий», «плівковий», «ч/б» — це таблиця кольорокорекції: дешево, одноманітно, оновлюється контентом. Художня обробка з реакцією на сюжет — обчислювальний шейдер.
На практиці їх комбінують: шейдер робить базову кольорокорекцію й підготовку, таблиця накладає фінальний стиль.
Ми заміряємо час обробки кадру на реальних пристроях, а не на стенді, і за цими цифрами фіксуємо схему — інакше фільтр, гарний у демо, роняє частоту кадрів на живому апараті.
Технічні сумніви та відповіді
GPU-фільтри живуть у двох різних світах: на iOS це Metal і Core Image, на Android — шейдери та апаратні ефекти камери.
Нижче — відповіді на питання, які найчастіше виникають до старту робіт: вони визначають архітектуру, терміни та те, як застосунок поводитиметься на реальних пристроях.
Наскільки широко підтримуються GPU-фільтри на пристроях?
Ми орієнтуємося на актуальну гілку мобільних систем і тримаємо запас щодо сумісності: фільтри працюють на переважній більшості пристроїв, випущених за останні кілька років.
Для старих моделей передбачаємо програмний запасний шлях — ефект застосовується, хай і повільніше, тому застосунок не «падає» на слабкому залізі. Точний список підтримуваних пристроїв фіксуємо на етапі проєктування.
Як це впливає на продуктивність і витрату батареї?
Обробка відбувається на графічному прискорювачі, а не на центральному процесорі, тому фільтр застосовується до кадру майже миттєво — попередній перегляд залишається плавним навіть при перемиканні ефектів.
Основну витрату енергії дає не сам фільтр, а камера та екран, тож на час роботи в режимі зйомки GPU-шар впливає слабко. Ми заміряємо нагрів і відгук на реальних пристроях, а не лише в емуляторі.
Як фільтри інтегруються в наявний застосунок?
Шар ефектів підключається до поточної камери або галереї без переписування логіки застосунку. Ми описуємо фільтри як окремі налаштовувані профілі, тому додати новий ефект пізніше можна без релізу всього коду.
Якщо застосунок уже використовує власну обробку зображень, акуратно вбудовуємося поруч і зберігаємо сумісність.
Як ви тестуєте фільтри перед випуском?
Перевіряємо не лише «гарну картинку», а й поведінку на слабких і сильних пристроях, за різного освітлення та на різних камерах. Окремо дивимося, як фільтр поводиться при швидкому перемиканні та у фоні. Результат — стабільний ефект без ривків і розбіжностей між платформами.
Що з підтримкою після запуску?
Нові версії систем і моделей пристроїв виходять постійно, і фільтри потрібно супроводжувати за ними. Ми закладаємо це в підтримку: стежимо за сумісністю, оновлюємо профілі ефектів і повертаємося з планом робіт, коли змінюється поведінка платформи.
Обговоримо ваше завдання щодо GPU-фільтрів
Надсилайте вступні дані — повернемося з оцінкою та планом робіт щодо GPU-фільтрів. Щоб розмова була предметною, а не «розкажіть про фільтри загалом», корисно одразу закрити кілька питань.
- Що це за фільтри та звідки беруться ефекти. Набір пресетів фіксований чи користувач сам крутить параметри? Чи є готові LUT-таблиці від дизайну і в якому вигляді — файли, матриці, окремі шари? Від цього залежить, збираємо ми конвеєр обробки чи просто підключаємо готові ланцюжки.
- Де рахуємо — на пристрої чи на сервері. Обробка на телефоні дає миттєвий передперегляд і не залежить від мережі, серверна — єдиний результат на всіх моделях. Часто потрібна гібридна схема: прев'ю локально, фінальний рендер під час збереження.
- Цільові пристрої та мінімальні вимоги. Список моделей, версії системи, частка слабких апаратів в аудиторії. Це визначає, де вмикаємо апаратне прискорення, а де залишаємо запасний шлях на процесорі.
- Формати та роздільні здатності. З якими зображеннями працюємо — знімки з камери, імпорт з галереї, відео? Чи потрібні пакетна обробка та збереження в початковій якості.
- Що вже є в проєкті. Поточний код застосунку, використовувані бібліотеки, обмеження щодо доступу до камери та галереї, вимоги магазинів застосунків.
- Критерії приймання. Що вважаємо готовим результатом: час відгуку передперегляду, стабільність на слабких пристроях, збіг кольору з макетом, відсутність артефактів на межах кадру.
За цими пунктами наші інженери готують оцінку та план робіт: етапи, що робимо на кожному, які ризики бачимо і як їх закриваємо. Якщо частина вступних даних поки не визначена — розберемо на дзвінку та зафіксуємо в технічному завданні.
Опишіть завдання у зручному форматі — повернемося з оцінкою та планом робіт.
