Чому мобільна гра не тримає стабільні 60 кадрів/с
Просадки кадрів майже ніколи не пов'язані із «залізом» — вони є наслідком того, як гра використовує графічний конвеєр.
Оптимізація рендерингу мобільної гри починається з пошуку вузького місця: те саме падіння з 60 до 40 кадрів/с дають перемальовування інтерфейсу поверх сцени, зайві виклики відрисовування на кожен об'єкт, витоки пам'яті під текстури та важкі ефекти на кшталт прозорості й постобробки. Поки причину не локалізовано, будь-які правки — це вгадування.
Перемальовування інтерфейсу — найчастіший прихований винуватець. Кожен елемент HUD, що оновлюється в ігровому циклі, змушує перезбирати шар поверх сцени, і вартість зростає лінійно з кількістю таких елементів.
Зайві виклики відрисовування дають схожий ефект: сотні окремих об'єктів замість об'єднаних у пакети навантажують процесор сильніше, ніж сама геометрія.
Витоки пам'яті під текстури та буфери проявляються не одразу — перші хвилини гра тримає кадри, а до середини сесії починаються ривки та примусове вивантаження.
У гравця це виглядає передбачувано: нагрівання пристрою, тротлінг через 10-15 хвилин, просадки в динамічних сценах і скарги на «гальмує на моєму телефоні». Розбираємо, як кожне з цих вузьких місць закривається на рівні рендерингу, а не костилями в ігровій логіці.
Що дає оптимізація рендерингу мобільної гри
Оптимізація рендерингу — це не «прискорити картинку», а прибрати зайву роботу з критичного шляху кадру. Коли бюджет кадру дотримується, рушій встигає відрендерити сцену й підготувати наступний кадр, а не наздоганяти пропущене.
На практиці це виглядає так: замість просідань на складних сценах — рівний графік, де час кадру тримається в межах, заданих частотою оновлення екрана.
Перше, що бачить гравець, — стабільна частота кадрів і передбачувана плавність анімації. Друге, що він відчуває, — час відгуку керування: натискання обробляється в тому самому кадрі, а не через два-три.
Це прямо впливає на утримання — у динамічних сценах затримка в пару кадрів сприймається як «гра гальмує», навіть якщо середній показник високий.
Далі — енергоспоживання гри. Коли рендер не робить зайвої роботи, пристрій менше нагрівається й рідше скидає частоти під навантаженням.
Це знімає головну причину «пливучої» продуктивності: телефон не йде в тротлінг через десять хвилин гри, і кадри не починають просідати до середини сесії.
І останнє за порядком, але не за важливістю — підтримка слабких пристроїв. Оптимізований рендер розширює список моделей, на яких гра йде комфортно, без окремого урізаного збірника під кожен клас.
Ми працюємо на Unity і профілюємо реальні сцени на цільових пристроях, а не лише в редакторі, — тому ефект від оптимізації видно на живих замірах, а не в теорії.
Підходи до рендерингу: що вибрати під задачу
Вибір конвеєра рендерингу визначає стелю продуктивності всієї гри: змінити його на середині проєкту дорожче, ніж закласти правильний одразу.
Прямий конвеєр малює кожен об'єкт по черзі — передбачувано й дешево на сцені з сотнею об'єктів, але на щільній сцені впирається в кількість викликів відрисовки.
Пакетна відрисовка об'єднує однотипні об'єкти в один виклик і знімає це обмеження, а відкладена відрисовка переносить розрахунок освітлення в окремий прохід і тримає стабільний кадр там, де багато джерел світла.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Прямий конвеєр | Прості сцени, 2D, ранній прототип | Зростає кількість викликів відрисовки, просідання на щільних сценах |
| Пакетна відрисовка | Багато однотипних об'єктів, мобільні 3D-сцени | Потребує спільних матеріалів і текстур, складніше з прозорістю |
| Відкладена відрисовка | Багато динамічного світла, складні сцени | Вище навантаження на пам'ять, слабше на слабких пристроях |
Рівень деталізації працює поверх будь-якого конвеєра: дальні об'єкти отримують спрощену геометрію і текстури, і це звільняє бюджет кадру під те, що гравець бачить зблизька.
Обмеження рендерингу на мобільних задає не лише чіп, а й тепловий тротлінг — стабільні 60 кадрів важливіші за пікові 120, які тримаються перші хвилини.
Розбираємо, як підібрати конвеєр під конкретну сцену й утримати частоту кадрів без просідань.
Як проходить оптимізація рендерингу мобільної гри
Оптимізація рендерингу — це не «поправити шейдери і стало швидше», а цикл: замір, пошук вузького місця, правка, повторний замір на живому пристрої. Нижче — як проходить така робота у наших інженерів.
- Знімаємо базові метрики. Заміряємо частоту кадрів і час відмалювання кадру на референсних пристроях — від бюджетних до флагманських. Фіксуємо не середній показник, а розподіл: просідання в 90-й перцентилі помітні гравцеві сильніше, ніж рівний середній кадраж.
- Профілюємо рендеринг. Розбираємо кадр за стадіями: підготовка сцени, відмалювання геометрії, робота з прозорістю, постобробка. Профілювальник показує, яка стадія з'їдає бюджет кадру, — далі працюємо точково, а не «оптимізуємо все».
- Шукаємо вузькі місця. Типові причини просідань: надлишкові виклики відмалювання, перемальовування пікселів поверх один одного, важкі шейдери, зайві джерела світла, неоптимальні текстури. Кожне підтверджуємо заміром, а не здогадкою.
- Правимо шейдери й матеріали. Спрощуємо обчислення в шейдерах, прибираємо зайві проходи, об'єднуємо матеріали, щоб скоротити число викликів відмалювання. Мета — укласти кадр у бюджет за цільової частоти.
- Перевіряємо на пристроях. Проганяємо збірку на реальному парку пристроїв: різні чипи, обсяги пам'яті, версії системи. Емулятор не покаже тепловий тротлінг і реальну деградацію — тільки живий прогін.
- Повторюємо цикл. Після правок знову знімаємо метрики й порівнюємо з базовими. Якщо просідання залишилися — повертаємося до профілювання, поки розподіл кадрів не стане рівним.
- Передаємо результат. Віддаємо заміри до/після, список правок і рекомендації, щоб команда могла підтримувати продуктивність при додаванні нового контенту.
Такий цикл закриває задачу не разово, а як процес: кожна правка підтверджена заміром, а не відчуттям «наче стало плавніше».
Що замовник отримує за підсумками робіт
За підсумками оптимізації рендерингу замовник отримує не звіт, а робочий комплект, з яким проєкт живе далі без нашої участі. Нижче — що саме залишається в репозиторії та в документації.
- Профілі якості графіки — набір перемиканих конфігурацій від «енергозбереження» до «максимум»: дальність промальовування, щільність тіней, рівень згладжування, роздільна здатність рендера. Кожен профіль прив'язаний до класу пристрою, тому на слабких моделях гра не провалюється в просідання, а на флагманах не виглядає урізаною.
- Схема сцени — карта того, що і коли потрапляє в кадр: статична геометрія, динамічні об'єкти, ефекти, шари інтерфейсу. За нею видно, які вузли можна вимикати або підміняти на спрощені, не ламаючи картинку.
- Політики якості — правила, за якими рушій сам знижує навантаження: пріоритети відмальовування, бюджети на кадр, поведінка при перегріві та розряді батареї. Гра тримає цільові 60 кадрів/с і не йде в перегрів на довгих сесіях.
- Документація рендерингу — опис конвеєра, точок заміру та того, як кожне налаштування впливає на кадрову частоту. Інженер, який прийде в проєкт пізніше, розбереться без звернень до нас.
- Регламент перевірки — чек-лист приймання: на яких пристроях і сценах замірюємо, які пороги вважаємо нормою, що фіксуємо у звіті. Регрес за кадрами ловиться до релізу, а не у відгуках.
- Налаштовані налаштування графіки в меню — зрозумілі користувачеві перемикачі з чесними підписами, щоб він сам вибирав баланс між картинкою та часом роботи від батареї.
- Скрипти замірів — автоматичний прогін сцен із записом кадрової частоти та часу кадру, щоб кожну збірку можна було порівняти з попередньою.
Комплект передаємо з розбором: показуємо, де були вузькі місця, що змінили і як перевірити результат своїми руками. Опишіть задачу — повернемося з оцінкою та планом робіт.
Кейс: як гра перестала втрачати кадри на середніх пристроях
Проєкт — казуальна гра з ізометричною сценою та десятками анімованих об'єктів. На середньому сегменті пристроїв частота кадрів просідала до 40–45, а на масових сценах — до 30, з регулярними пропусками: частка кадрів, відрендерених довше за бюджет, сягала чверті. Гравці скаржилися на «рване» керування, а не на графіку — просідання били по чутливості введення.
Ми почали з профілювання на реальних пристроях середнього сегмента, а не на флагманах: вимірювали час кадру, розподіл пропусків і навантаження на рендеринг по кадрах.
Виявилося, що вузьке місце — не кількість об'єктів, а надлишкові виклики рендерингу та перемальовування статичного фону кожен кадр.
Зібрали сцену в пакети за матеріалами, статику винесли в окремий шар, анімації перевели на спільний атлас, а фізику й логіку відв'язали від частоти рендерингу — тепер вони рахуються з фіксованим кроком і не «пливуть» при просіданнях.
Unity дав інструменти для пакетного рендерингу та профілювання, але вирішував не платформа, а порядок роботи: спочатку замір, потім зміна, потім повторний замір на тому самому наборі пристроїв.
Після оптимізації частота кадрів на середніх пристроях вийшла на стабільні 58–60 у масових сценах, частка пропущених кадрів упала з чверті до поодиноких відсотків, а розкид між найкращим і найгіршим кадром скоротився в рази — рендеринг перестав «смикатися». На слабкому сегменті втримали 45–50 без візуальних спрощень, які помітив би гравець.
Окремо перевірили стабільність рендерингу під навантаженням: тривалі сесії, нагрівання, фонові процеси. Просідання, які раніше накопичувалися до десятої хвилини гри, зникли — час кадру тримається рівним протягом усієї сесії.
Чим відрізняється відкладене відображення від прямого?
Пряме відображення надсилає команди малювання на графічний прискорювач одразу, щойно сцену оновлено в поточному циклі. Застосунок сам вирішує, що і коли малювати, і тримає повний контроль над порядком викликів.
Це дає мінімальну затримку між зміною стану та появою зображення — критично для чутливого керування в динамічних сценах, де важлива реакція на дотик у межах одного циклу.
Відкладене відображення спочатку збирає список команд у буфер, сортує та групує їх за матеріалом і станом, і лише потім надсилає пакетом.
Виграш — у скороченні перемикань станів і кількості викликів: однотипні об'єкти малюються підряд, прискорювач рідше простоює між змінами текстур і шейдерів. На сценах із сотнями однотипних об'єктів це помітно підвищує продуктивність рендерингу та стабілізує час кадру.
Вибір підходу впирається в профіль сцени, а не в «найкращий» метод. Пряме відображення виграє там, де об'єктів мало, але вони часто змінюють стан, або де потрібна передбачувана затримка введення.
Відкладене — де об'єктів багато, вони статичні за матеріалом і їх можна ефективно згрупувати. Змішаний варіант трапляється найчастіше: інтерфейс і ефекти малюються напряму, а фон і масові об'єкти — через буфер.
Обмеження методів теж дзеркальні. Пряме відображення впирається в стелю за кількістю викликів: чим більше об'єктів, тим вище навантаження на процесор і тим частіше кадр не вкладається в бюджет.
Відкладене додає пам'ять під буфер команд і затримку в один-два кадри, а також ускладнює роботу з прозорістю та порядком накладання — сортування за станом може конфліктувати із сортуванням за глибиною.
На практиці підхід не фіксують раз і назавжди: його обирають під конкретну сцену та перемикають між режимами за її профілем. Спочатку знімають заміри — де саме втрачається час кадру, на процесорі чи на прискорювачі, — і вже під це підбирають метод.
Так оптимізація рендерингу мобільної гри спирається на дані, а не на звичку, і утримання стабільних 60 кадрів стає керованою задачею.
Часті технічні сумніви щодо оптимізації рендерингу
Перед стартом робіт замовники ставлять одні й ті самі питання: чи не зламається гра на старих пристроях, скільки це займе, що буде з геймплеєм. Нижче — прямі відповіді, без загальних слів.
Оптимізація не зламає рендеринг на слабких пристроях?
Ні, якщо будувати її на профілях якості, а не на єдиному пресеті.
Ми знімаємо заміри на реальних пристроях з вашої аудиторії, визначаємо бюджет кадру для кожного класу та розводимо налаштування: десь знижуємо щільність частинок і роздільну здатність тіней, десь перемикаємо матеріал на дешевший.
Слабкі пристрої отримують стабільний кадр без просідань, флагмани — повну картинку. Сумісність перевіряємо до релізу, а не після скарг.
Скільки часу займає оптимізація рендерингу?
Залежить від масштабу сцени та кількості платформ. Первинний аудит із замірами та планом — кілька днів, далі ітерації по вузьких місцях. Якщо проблема в одному важкому ефекті, правки займають дні; якщо перебудовується весь конвеєр відмальовування — тижні. Точний термін називаємо після замірів, а не «на око».
Які ризики у змін і чи можна відкотитися?
Основний ризик — візуальні артефакти при агресивному зниженні якості. Тому кожна зміна йде окремою гілкою із заміром до та після, а не одним великим комітом. Будь-який крок відкочується без втрати попередніх покращень, а еталонні збірки зберігаємо для порівняння.
Оптимізація змінить геймплей чи картинку?
Мета — зберегти ігровий досвід, прибравши зайве навантаження. Ми не ріжемо те, що гравець помічає: ключові ефекти, читабельність сцени, чутливість керування залишаються. Прибираємо приховані витрати — зайві виклики відмальовування, дублюючі матеріали, невидиму геометрію. Візуально гра виглядає так само, а йде рівніше.
Чи потрібно переписувати проєкт під нову платформу?
Зазвичай ні. Оптимізація рендерингу — це точкова робота з наявним кодом і налаштуваннями, а не переписування. Ми підлаштовуємо конвеєр під поточну архітектуру, тому релізний цикл не розтягується, а команда продовжує випускати оновлення паралельно.
Якщо залишилися сумніви щодо вашого проєкту — опишіть задачу, повернемося з оцінкою та планом робіт.
Обговоримо ваше завдання з оптимізації рендерингу
Щоб повернутися з оцінкою та планом оптимізації, нам потрібен не абстрактний запит «гра гальмує», а зріз поточного стану рендера. Чим конкретніші вхідні дані, тим точніша оцінка робіт і менше ітерацій на узгодження.
Що надіслати для старту:
- Профіль кадрів: запис із профайлера за типовою сценою — де саме просідає час кадру (відмальовування, логіка, фізика, завантаження ресурсів).
- Цільові пристрої: моделі, на яких застосунок зобов'язаний тримати стабільні кадри, і поточні показники на них.
- Список важких місць: сцени з максимальною кількістю об'єктів, ефектами, прозорістю, динамічним світлом.
- Вихідні коди та доступи: репозиторій, гілка, збірка, доступ до систем аналітики та звітів про збої.
- Обмеження: терміни, платформи, вимоги до сумісності зі старими пристроями.
Далі працюємо за етапами. Спочатку відтворюємо просідання на стенді та фіксуємо базові метрики — без цього будь-яка оптимізація перетворюється на вгадування.
Потім розбираємо вузькі місця: батчинг викликів відмальовування, перевикористання ресурсів, розвантаження головного потоку, рівні деталізації. Після — план оптимізації з пріоритетами: що дає ефект одразу, що потребує переробки сцен.
Узгоджуємо план, стартуємо роботи короткими ітераціями з заміром після кожного кроку. На виході — не лише прискорений рендер, а й передача проєкту: документація щодо змін, правила для команди, щоб просідання не повернулися з наступним контентом. Опишіть завдання та надішліть вхідні дані — повернемося з оцінкою та планом.
