Как оптимизировать 2D-игру для мобильных устройств
2D-игра, которая плавно идёт на десктопе, на телефоне может захлёбываться, потому что мобильное железо отказывает иначе, чем настольное. Мобильные GPU построены по тайловой схеме и ограничены по скорости заливки, поэтому прозрачные частицы и полноэкранные эффекты обходятся дороже, чем кажется; у устройства меньше памяти, и несжатые текстуры съедают бюджет; а длительная нагрузка греет телефон и заставляет его снижать частоты, так что пиковая частота кадров ничего не значит. Решение — последовательность для мобильных: сжимать текстуры в ETC2 или ASTC, сокращать заливку и перерисовку, держать число вызовов отрисовки низким, уменьшать объём памяти, профилировать собственными средствами устройства и рассчитывать на устойчивую производительность, а не на короткий всплеск. Руководство проходит каждый шаг с оглядкой на реалии мобильных GPU — без выдуманных бенчмарков, только то, как на самом деле работают PowerVR, Adreno, Mali и Apple GPU и форматы сжатия текстур.
2D-игра, которая держит 60 FPS на вашем рабочем ПК, на телефоне может подтормаживать, потому что телефон отказывает по иным причинам, чем десктоп. У десктопа с запасом памяти и скорости заливки; у телефона их нет. Десктоп работает на полной нагрузке без перегрева; телефон греется и снижает частоты. Оптимизация для мобильных означает оптимизацию под три конкретных ограничения — скорость заливки, память и нагрев — поверх универсальных правил, действующих везде.
Универсальные правила разобраны в общем руководстве по производительности 2D: сократите вызовы отрисовки через батчинг и атласы, уберите выделения памяти в каждом кадре с помощью пула объектов, отсекайте то, что не попадает в камеру, и ведите симуляцию с фиксированным шагом. Начните с него. Эта статья — слой поверх: приёмы, которые важны именно потому, что цель лежит у кого-то в кармане.
Почему мобильные иначе: тайловые GPU и три ограничения
Мобильные GPU — Apple, Adreno от Qualcomm, Mali от Arm, PowerVR от Imagination — построены по принципу тайловой отложенной отрисовки (TBDR). Вместо того чтобы рисовать весь кадр за один проход в память, они разбивают экран на небольшие тайлы, отрисовывают каждый тайл в быстрой внутрикристальной памяти и лишь однажды записывают готовый тайл наружу. Такая схема экономит пропускную способность памяти, которая на телефоне дефицитна и энергозатратна.
У этой архитектуры есть следствие, определяющее большую часть производительности мобильной 2D: она ограничена по скорости заливки. Стоимость закрашивания пикселя, и особенно закрашивания одного и того же пикселя несколько раз, оказывается узким местом куда чаще, чем геометрия. Из него вытекают три ограничения.
| Ограничение | Что означает | Симптом |
|---|---|---|
| Скорость заливки | Пикселей, записанных за секунду | Частицы и полноэкранные эффекты роняют кадры |
| Память | ОЗУ и бюджет текстур | Крупные текстуры замедляют загрузку и приводят к выгрузке приложения из фона |
| Нагрев | Длительная нагрузка греет устройство | Частота кадров падает через несколько минут игры |
Десктоп скрывает все три; телефон их обнажает. Ниже — как пробить каждое.
Сжимайте текстуры: ETC2 и ASTC
Самый большой рычаг, специфичный для мобильных, — сжатие текстур. Несжатая RGBA-текстура занимает 4 байта на пиксель: атлас спрайтов 2048×2048 обходится в 16 МБ видеопамяти, и каждый кадр GPU читает его через пропускную способность памяти. Сжатая текстура остаётся сжатой в видеопамяти и разворачивается аппаратно по мере отрисовки, сокращая и память, и пропускную способность примерно в четыре-восемь раз.
| Формат | Где работает | Примечания |
|---|---|---|
| ETC2 | Универсальная база для Android | Аппаратная поддержка практически на всех современных Android; безопасный выбор |
| ASTC | Современные Apple и Android | Выше качество на байт, гибкие битрейты; предпочтительный формат при поддержке |
| PVRTC | Устаревшие iOS / PowerVR | Старый формат, в основном вытеснен ASTC |
Практическое правило: поставляйте ASTC там, где устройство его поддерживает, и ETC2 как универсальный запасной вариант, а на GPU никогда не отправляйте несжатые данные или PNG для спрайтов в рантайме. PNG — хороший формат распространения для веб-сайта, но не формат исполнения на телефоне. Большинство движков позволяет настроить сжатие текстур отдельно по платформам — задавайте его сознательно, а не оставляйте по умолчанию.
Защищайте бюджет заливки: перерисовка — тихий убийца
Поскольку мобильные GPU ограничены по скорости заливки, перерисовка — закрашивание одного пикселя больше одного раза за кадр — чаще всего оказывается той статьёй расхода, которая больше всего удивляет разработчиков, пришедших с десктопа. Каждая перекрывающая прозрачная частица, каждый крупный светящийся спрайт за действием, каждый полноэкранный проход размытия или свечения (bloom) записывает пиксели, которые затем записываются снова. Сцена, которая кажется простой, может закрашивать каждый экранный пиксель пять-десять раз.
Средства защиты прямые:
- Урежьте число и размер частиц. Сто мелких частиц стоят меньше заливки, чем двадцать крупных во весь экран, а визуальная разница часто незаметна.
- Ограничьте полноэкранные эффекты. Один полноэкранный проход умножает работу над всеми пикселями кадра; два-три быстро складываются. Применяйте их умеренно или запекайте что можно.
- Сокращайте прозрачную область. Прозрачность требует смешивания, а оно дороже непрозрачной отрисовки. Где позволяет арт, выбирайте непрозрачные спрайты.
- Уменьшайте целевой буфер для дорогих эффектов вроде размытия, а затем масштабируйте вверх: проход свечения в половинном разрешении стоит четверти пикселей.
Скорость заливки — тот бюджет, за которым на мобильных нужно следить пристальнее всего. Если единственное число должно направлять ваши художественные решения, пусть это будет оно.
Держите вызовы отрисовки низкими — мобильные ещё чувствительнее
Общее правило остаётся в силе: каждый вызов отрисовки несёт фиксированные накладные расходы на CPU, а батчинг спрайтов с общей текстурой в один вызов — лекарство. На мобильных правило острее, ведь у мобильных CPU меньше запаса и фиксированная стоимость вызова съедает большую долю кадра. Атлас спрайтов, сворачивающий пятьсот отрисовок тайлов в один вызов, — на телефоне не приятное дополнение, а часто граница между плавным уровнем и подтормаживающим.
Цельтесь в несколько десятков вызовов отрисовки для типовой 2D-сцены и считайте всё, что измеряется сотнями, проблемой, которую надо разбирать. Батчите по атласу, избегайте разрыва батчей переключением текстур или режимов смешивания посреди сцены и позвольте профайлеру подсказать, когда один неожиданный вызов срабатывает сотню раз.
Уменьшайте память: текстуры — это бюджет
У телефона куда меньше ОЗУ, чем у вашей машины разработки, и оно разделено с операционной системой, фоновыми приложениями и вкладкой браузера, из которой пришёл игрок. Когда памяти не хватает, ОС выгружает фоновые приложения — а иногда и само активное приложение. Текстурная память обычно крупнейшая статья бюджета 2D-игры, поэтому то же сжатие, что помогает пропускной способности, помогает и здесь.
- Сжимайте всё (см. ETC2 и ASTC выше) — это крупнейшая единовременная экономия памяти.
- Подбирайте разрешение текстур. Спрайту не нужен лист 2048×2048, если на экране он рисуется размером 256×256. Согласуйте разрешение текстуры с экранным размером.
- Стримьте или подгружайте крупный контент. Загружайте ассеты текущего уровня, а не всей игры, и освобождайте то, что уровень оставил позади.
- Следите и за размером загрузки. Размер установки влияет на конверсию в магазине и на сотовые загрузки; та же дисциплина сжатия, что уменьшает память, уменьшает и пакет.
Рассчитывайте на устойчивую производительность, а не на пиковую
Самый контринтуитивный факт о мобильных состоит в том, что высокая частота кадров может оказаться хуже низкой. Игра, выжимающая 60 FPS в начале, выделяет тепло, и через несколько минут устройство снижает частоты для защиты — частота кадров падает до 30 с рывками между ними. Игра, изначально нацеленная на стабильные 30 или 45 FPS, может вообще не перейти к троттлингу и ощущаться плавнее на реальной сессии.
Считайте устойчивую производительность настоящей целью. Тестируйте на устройстве среднего класса после того, как оно поработало с игрой пять минут, а не только на холодном флагмане тридцать секунд. Если выбирать между ярким эффектом, провоцирующим троттлинг, и более простым, который держит кадр, на телефоне побеждает простой.
Профилируйте на реальном устройстве правильными средствами
Оптимизация без измерений — угадывание, а на мобильных единственное честное измерение — на реальном железе. Используйте собственные профайлеры платформы.
| Средство | Платформа | Что показывает |
|---|---|---|
| Xcode Instruments / отладчик Metal | iOS (Apple GPU) | Время CPU, стоимость кадра на GPU, детали шейдеров и перерисовки |
| CPU-профайлер Android Studio | Android | Стоимость CPU по функциям, тайминг потоков |
| Android GPU Inspector / Frame Profiler | Android | Вызовы отрисовки, стоимость шейдеров, перерисовка |
| Snapdragon Profiler | Android (Adreno) | GPU-счётчики, покадровый анализ на устройствах Qualcomm |
| RenderDoc | Android (Vulkan) | Покадровая инспекция захваченного кадра |
Десктоп, симулятор или эмулятор не воспроизведут потолок памяти, ограничение заливки или тепловой режим телефона, поэтому игра, которая кажется плавной в симуляторе, может захлёбываться в руке. Профилируйте на реальном устройстве среднего класса рано и снова после каждого крупного изменения в арт или эффектах.
Ошибки, которые сводят мобильную оптимизацию на нет
- Оставить текстуры несжатыми. Крупнейший и самый лёгкий выигрыш по памяти и пропускной способности упущен.
- Гнаться за пиковой частотой кадров. Число, падающее после троттлинга в рывки, хуже низкой, но устойчивой.
- Профилировать только на флагмане. Большинство ваших игроков — на железе среднего класса; оптимизируйтесь под него.
- Тяжёлая перерисовка от частиц и постобработки. Та стоимость заливки, которую мобильные GPU хуже всего переваривают.
- Игнорировать размер загрузки. Размер установки влияет на то, установят ли игру вовсе.
- Оптимизировать до измерений на устройстве. Десктопная интуиция о стоимости на телефоне ошибается.
Где уместен Egmatic
Egmatic — 2D-редактор и движок на базе MonoGame, и этот выбор помогает на мобильных двумя честными способами. Во-первых, MonoGame — лёгкий рантайм на C# с прямым контролем над конвейером отрисовки и без тяжёлой редакторской абстракции между вами и железом, поэтому, когда бюджет кадра на телефоне в обрез, узким местом служит ваш контент и логика, а не движок, который с вами борется. Во-вторых, живой предпросмотр Egmatic позволяет поменять сжатие текстуры, число частиц или значение в шейдере и сразу увидеть эффект на реальном устройстве, что превращает мобильное профилирование из медленного цикла «правка — сборка — запуск» в быструю обратную связь, которую остальная часть статьи рекомендует.
Egmatic нацелен на десктоп, мобильные и консоли через базу на MonoGame, поэтому описанная здесь дисциплина оптимизации действует на всех платформах. Если вы выбираете движок для мобильной 2D-игры в первую очередь, сравнение мобильных игровых движков расставляет варианты; а универсальные приёмы, на которые опирается эта статья, разобраны в общем руководстве по производительности 2D — вызовы отрисовки, выделения памяти, отсечение и фиксированный шаг симуляции.
Вывод
Производительность мобильной 2D — это десктопная производительность плюс три дополнительных ограничения: скорость заливки, память и нагрев. Сжимайте текстуры в ETC2 или ASTC, защищайте бюджет заливки от перерисовки и тяжёлых эффектов, держите вызовы отрисовки в пределах десятков, уменьшайте текстурную память и нацеливайтесь на устойчивую производительность на реальном устройстве среднего класса, а не на всплеск на флагмане. Профилируйте собственными средствами платформы и никогда — в симуляторе. Делайте это поверх универсальных правил батчинга, пула объектов, отсечения и фиксированного шага — и игра удержит частоту кадров в руке игрока, а не только на вашем столе.