Проблемы с производительностью мобильной игры редко начинаются в момент, когда FPS впервые падает до некомфортного уровня. Обычно к этому моменту проект уже несколько месяцев постепенно выходит за технические ограничения.
Добавляется новый персонаж, потом более тяжёлый VFX, несколько дополнительных экранов, ещё один SDK, более детализированное окружение. Каждое изменение само по себе кажется небольшим. На устройствах разработчиков игра продолжает работать нормально, поэтому отдельной проблемы никто не видит.
А затем появляется почти готовая сцена, запускается тест на одном из слабых поддерживаемых устройств — и выясняется, что одновременно не помещаются CPU, GPU, память и загрузки.
После этого начинается знакомая финальная оптимизация: художники уменьшают текстуры, разработчики ищут дорогие Update, VFX упрощаются, часть объектов отключается, а QA снова проходит уже проверенные сцены.
Этого намного проще избежать, если производительность с самого начала воспринимать как ограниченный бюджет, который команда распределяет между системами проекта.
Особенно это важно при разработке игр для Android и разработке игр для iOS, где одна и та же версия должна стабильно работать на устройствах с заметно различающимися характеристиками.
Начинать нужно не с оптимизации, а с целевого устройства
Фраза «игра должна работать на мобильных» практически бесполезна для production.
На каких именно?
Современный флагман может скрыть множество технических проблем, которые станут критичными на устройстве нижней границы поддержки. Если вся команда ежедневно работает на мощных телефонах, проект очень долго может выглядеть здоровым.
Поэтому ещё до массового производства контента полезно определить реальный нижний уровень устройства, который команда собирается поддерживать.
Именно оно в значительной степени определяет технические рамки проекта.
Если игра должна стабильно работать там, арт-команда уже может принимать решения о сложности окружения и эффектов. Разработчики понимают допустимую нагрузку gameplay-систем. Technical art получает ориентиры для материалов и шейдеров. QA знает, на каком железе нужно регулярно проверять самые тяжёлые сценарии.
Это намного полезнее, чем сначала сделать игру для абстрактного «среднего смартфона», а ближе к релизу выяснять, какой парк устройств она вообще способна выдержать.
При этом одного телефона недостаточно. Особенно на Android, где устройства отличаются не только объёмом памяти и производительностью CPU, но и GPU, драйверами, разрешением экрана и поведением под продолжительной нагрузкой.
Нужна небольшая, но осмысленная линейка: слабая граница поддержки, типичный аппарат основной аудитории и более производительное устройство для контроля верхнего уровня. Такая выборка даёт намного больше полезной информации, чем десять случайных телефонов, которые просто оказались у сотрудников.
FPS — это следствие, а не бюджет
Самая очевидная performance-цель звучит как «держим 60 FPS».
Но сама цифра ещё не говорит команде, сколько ресурсов можно потратить.
При 60 FPS весь кадр должен укладываться примерно в 16,7 миллисекунды. При 30 FPS доступный интервал больше, но это всё равно не означает, что одна система может забрать его целиком.
Gameplay, animation, physics, rendering, UI, VFX, загрузки и фоновые процессы работают одновременно.
И если каждая команда ориентируется только на общий FPS, техническая проблема становится заметной слишком поздно.
Например, gameplay-программист добавляет систему, которая забирает ещё немного CPU. Отдельно она не ломает frame rate. Художники добавляют более тяжёлые материалы — тоже ничего критичного. Затем появляется несколько противников с VFX, включается сложный UI, и вся комбинация внезапно перестаёт помещаться в кадр.
Поэтому полезнее думать не только про конечные 30 или 60 FPS, а про frame-time budget.
Сколько может занимать gameplay? Сколько остаётся rendering? Какой запас нужен для пиковых состояний?
Здесь важен именно запас.
Если обычная сцена уже использует практически весь доступный frame time, любое следующее обновление будет превращаться в борьбу за миллисекунды.
Самая тяжёлая сцена важнее средней
Средняя производительность часто создаёт ложное чувство безопасности.
Большинство времени игра действительно может держать целевой FPS. Но игроку достаточно одного регулярного тяжёлого сценария, чтобы воспринимать проект как тормозящий.
Например, обычное перемещение по уровню работает идеально. Проблема появляется только во время большого боя, когда одновременно активируются несколько противников, частицы, анимации, интерфейс и система подсчёта урона.
Или FPS стабилен во время gameplay, но резко падает при открытии инвентаря.
Или первые пятнадцать минут всё нормально, а затем устройство нагревается и производительность начинает снижаться.
Поэтому performance budget нужно проверять не в «удобной тестовой сцене», а в сценариях, которые действительно создают нагрузку.
Хороший benchmark — это не пустая комната с одним персонажем. Это приближенное к худшему реальному состоянию игры сочетание контента и систем.
Для одного проекта таким тестом станет крупный бой. Для другого — насыщенная городская сцена. Для третьего — экран со сложным UI поверх активного gameplay.
Если самая тяжёлая ожидаемая ситуация укладывается в бюджет, остальные состояния обычно контролировать намного проще.
Пиковая память — отдельное ограничение
Производительность мобильной игры нельзя свести только к CPU и GPU.
Проект может держать стабильный frame rate и при этом вылетать из-за памяти.
Особенно неприятны ситуации, когда проблема появляется не внутри конкретной сцены, а во время перехода. Предыдущие ресурсы ещё не полностью выгружены, новые уже загружаются, создаются временные буферы — и на несколько секунд память поднимается значительно выше обычного уровня.
Именно поэтому мы отдельно разбирали бюджет памяти на мобильных. Смотреть нужно не только на среднее состояние gameplay, а на реальные пиковые сценарии и то, какие ресурсы одновременно оказываются загружены.
Это же показывает, почему performance budgets нельзя проектировать независимо.
Иногда ускорить загрузку можно, заранее удерживая больше данных в памяти. Иногда уменьшить GPU-нагрузку помогает решение, которое увеличивает объём ассетов. Иногда красивый эффект укладывается по GPU, но создаёт слишком много runtime-объектов и начинает влиять на CPU.
Оптимизация всегда происходит внутри системы компромиссов.
Поэтому задача не в том, чтобы сделать каждую метрику минимальной. Нужно добиться того, чтобы проект целиком стабильно помещался в технические ограничения целевых устройств.
UI тоже имеет собственную стоимость
Интерфейс часто долго не воспринимается как серьёзная performance-зона.
На экране вроде бы всего несколько панелей, иконок и надписей. По сравнению с 3D-сценой это выглядит незначительно.
Но сложный мобильный UI может создавать вполне заметную нагрузку: частые перестроения, большие и плохо организованные Canvas, лишние layout calculations, анимации, маски, overdraw, динамические списки.
Особенно это проявляется в проектах, где интерфейс со временем становится всё сложнее. Появляются LiveOps-баннеры, новые валюты, события, магазин, дополнительные уведомления — и экран, который когда-то был лёгким, постепенно превращается в одну из тяжёлых частей кадра.
Проблема снова возникает из-за отсутствия бюджета.
Если UI рассматривается как «то, что работает поверх игры бесплатно», его стоимость становится заметной только после появления просадок.
Поэтому интерфейс полезно профилировать в тех же реальных состояниях, что и gameplay. Особенно экраны, которые одновременно отображаются поверх активной игровой сцены.
Красивый VFX должен знать свою цену
VFX — ещё одна зона, которая очень легко масштабируется визуально быстрее, чем технически.
Один эффект выглядит отлично и почти не влияет на кадр. Затем в бою одновременно появляются десять таких эффектов, несколько персонажей используют способности, на экране работают transparency и post-processing — и результат уже совершенно другой.
Поэтому VFX стоит проверять не по одному в preview, а в реальной плотности gameplay.
Если в бою потенциально может одновременно появиться восемь одинаковых эффектов, именно такой сценарий и должен проходить performance-проверку.
Это относится и к окружению. Один красивый объект не является проблемой. Важно, сколько подобных объектов одновременно оказывается в кадре, какие материалы они используют и сколько дополнительных эффектов добавляет сцена целиком.
Именно поэтому performance budget лучше определить до массового art production. Тогда игровые художники работают не с абстрактной просьбой «делать оптимизированно», а с понятными техническими рамками проекта.
Загрузки тоже должны иметь измеримую цель
Иногда команда активно оптимизирует frame rate, но почти не контролирует время запуска и переходов между сценами.
В результате игра работает плавно, но пользователь ждёт слишком долго перед первым экраном или регулярно встречает тяжёлые загрузки между короткими игровыми сессиями.
Для мобильного продукта это особенно чувствительно.
Поэтому допустимое время запуска стоит определять так же заранее, как FPS.
Если startup должен укладываться в конкретный диапазон, команда может измерять его на одних и тех же устройствах и видеть регрессии между сборками.
То же касается переходов между ключевыми состояниями.
Проблема такого рода часто скрывается внутри структуры ассетов, Addressables, последовательности инициализации систем или собственного build pipeline. Поэтому при аудите Unity-проекта имеет смысл смотреть не только на качество кода, но и на реальную стоимость загрузки, ресурсов и runtime-процессов.
Температура меняет реальную производительность
Одна из особенностей мобильной разработки — короткого performance-теста бывает недостаточно.
Игра может первые десять минут стабильно держать целевой FPS. Затем устройство нагревается, система ограничивает производительность, и тот же сценарий начинает работать заметно хуже.
Разработчик, который запустил сцену на две минуты, проблему не увидит.
Игрок, который проводит в игре сорок минут, увидит.
Поэтому для тяжёлых мобильных проектов полезны длительные тестовые сессии. Особенно если игра постоянно нагружает GPU или рассчитана на долгие игровые циклы.
На странице разработки игр для iOS оптимизация именно поэтому включает не только FPS, но и память, загрузки и тепловой троттлинг: стабильность на всём диапазоне устройств важнее красивого benchmark в первые минуты работы.
Профилирование в конце проекта почти всегда запаздывает
Если performance test впервые проводится перед release candidate, технические варианты уже сильно ограничены.
К этому моменту готовы уровни. Ассеты утверждены. Gameplay зависит от множества систем. Любая существенная переделка требует дополнительного regression.
Поэтому регулярное профилирование намного дешевле финальной оптимизации.
Не обязательно каждую неделю проводить полный технический аудит всей игры. Достаточно иметь несколько контрольных сцен и одинаковые сценарии, которые команда регулярно запускает на целевых устройствах.
Тогда становится видна динамика.
Если в прошлом месяце тяжёлая сцена укладывалась в бюджет, а сейчас начала регулярно выходить за него, круг поиска значительно меньше. Можно посмотреть изменения последних недель и найти конкретный источник регрессии.
Без такого контроля команда обнаруживает проблему спустя полгода, когда поверх неё уже появилось множество других изменений.
Performance regression должен восприниматься как обычный баг
Есть полезная смена отношения: производительность — это не отдельный этап polish.
Если после новой функции frame time стабильно вырос настолько, что проект вышел за согласованный бюджет, это regression так же, как сломанная кнопка или ошибка сохранения.
То же относится к памяти и загрузкам.
Такой подход меняет production. Команда перестаёт говорить «оптимизируем перед релизом» и начинает защищать уже достигнутый уровень производительности.
Особенно хорошо это работает, когда технические метрики привязаны к регулярным сборкам.
Не всё можно полностью автоматизировать, особенно измерения на физических мобильных устройствах. Но хотя бы часть проблем стоит ловить ещё в CI и тестовых сценах.
И чем стабильнее сам процесс сборки, тем проще регулярно получать такие данные. Если новый build приходится ждать час, performance testing быстро превращается в редкую процедуру. В таком случае отдельно стоит разбирать узкие места build pipeline.
QA должен знать, что именно считать проблемой
Формулировка «посмотрите, не тормозит ли игра» почти бесполезна.
На одном устройстве тестировщик увидит 55 FPS и посчитает это нормальным. На другом заметит короткий spike и заведёт blocker. Результаты невозможно сравнивать.
Если же у команды есть согласованный бюджет, QA получает понятный ориентир.
На таком устройстве эта сцена должна держать выбранный target. После нескольких переходов память должна возвращаться примерно к baseline. Startup не должен регулярно выходить за установленную границу.
Тогда QA и тестирование игры становятся частью контроля производительности, а не субъективной оценкой плавности.
Причём подключать такие проверки полезно значительно раньше финального content lock. Когда одна тяжёлая сцена только начинает формироваться, изменить её структуру дёшево. После того как тот же подход использован в двадцати уровнях, проблема уже масштабирована на весь проект.
Бюджет должен оставлять место будущему контенту
Есть ещё одна типичная ошибка: команда добивается того, чтобы текущая версия ровно помещалась в лимит, и считает задачу закрытой.
Но production продолжается.
Появится новый персонаж. Затем сезонное событие. Потом ещё один SDK. После релиза может начаться LiveOps.
Если уже на середине разработки сцена использует почти весь CPU/GPU/memory budget, любое следующее обновление будет требовать оптимизации старого контента, прежде чем добавить новый.
Поэтому хороший бюджет содержит резерв.
Это особенно важно для проектов, которые должны жить долго. В LiveOps и поддержке игры после релиза команда постоянно добавляет контент и системы. Технический запас позволяет делать это без мини-кризиса перед каждым обновлением.
Точно так же performance budget нужно пересматривать, если меняется нижняя граница поддерживаемых устройств или сама продуктовая стратегия.
Бюджет — не число, записанное один раз в начале проекта. Это рабочее ограничение production.
Производительность должна быть общей ответственностью
Оптимизация часто воспринимается как задача программистов.
Но разработчик не может в одиночку удерживать performance budget, если арт регулярно производит слишком тяжёлые ассеты, UI не учитывает ограничения, а game design создаёт сценарии с неконтролируемым количеством объектов.
И наоборот, бессмысленно требовать от художников самостоятельно определять технические лимиты, если команда никогда их не сформулировала.
Рабочий процесс появляется тогда, когда все участники знают рамки своей зоны.
Art понимает, какой уровень сложности допустим.
VFX знает ожидаемую плотность эффектов.
Development контролирует стоимость систем и allocations.
QA проверяет реальные тяжёлые сценарии.
Technical lead видит картину целиком и оставляет запас на дальнейшее развитие.
Тогда производительность перестаёт быть «оптимизацией» и становится обычным ограничением дизайна продукта — таким же, как срок, бюджет команды или целевая платформа.
Не нужно оптимизировать всё
Обратная сторона performance budget — он помогает понять, где оптимизация вообще не нужна.
Если система стабильно укладывается в выделенный бюджет и не создаёт рисков, переписывать её только ради более красивой цифры необязательно.
Несколько дней инженера могут дать условные 0,2 миллисекунды там, где у проекта и так большой запас. Те же ресурсы могут принести намного больше пользы в действительно проблемной сцене.
Поэтому цель profiling — не получить минимально возможные цифры.
Цель — найти места, которые нарушают ограничения продукта.
Это особенно важно, когда работа ведётся с уже существующей игрой. При улучшении готового проекта сначала полезно найти настоящие bottlenecks, а уже затем решать, где требуется оптимизация, где изменение pipeline, а где проблему вообще не стоит трогать.
Бюджет нужен до того, как он закончился
Хороший performance budget почти незаметен в ежедневной работе.
Команда знает целевые устройства, регулярно проверяет тяжёлые состояния и замечает regressions достаточно рано. Поэтому перед релизом не требуется внезапно переписывать половину игры.
Плохой бюджет обнаруживается именно тогда, когда его уже нет.
Проект внезапно не помещается в память, тяжёлая сцена выходит за frame time, слабые устройства перегреваются, а сроки не позволяют существенно менять контент.
Поэтому самая полезная performance-работа начинается не с Profiler за две недели до релиза, а с нескольких конкретных ограничений ещё до массового production.
NoPanic Studio занимается мобильными проектами на разных стадиях: от разработки и портирования до профилирования уже работающих игр. Для Android и iOS проверяем CPU/GPU-нагрузку, память, загрузки и реальные сценарии на целевой линейке устройств, после чего определяем, где проект выходит за бюджет и какие изменения дадут наибольший эффект.
Если мобильная игра уже начинает терять FPS на части устройств или вы хотите определить технические рамки до массового производства контента — пришлите текущий билд, список целевых устройств и наиболее тяжёлые сцены. Разберём фактическую нагрузку и поможем сформировать performance budget, который можно контролировать на протяжении всего production.