Оптимизация графики под мобильные платформы

На Android mid-range устройстве GPU Profiler показывает 18 мс на кадр при целевых 16.6 мс — игра не держит 60 FPS. Комбинация из 340 draw calls, overdraw-тяжёлых эффектов и текстур 2048×2048, которые на экране занимают 64×64 пикселя — каждый фактор по отдельности терпим, вместе — катастрофа.

Почему оптимизация графики под мобильные платформы требует комплексного подхода?

Мобильные GPU — tile-based: они разбивают кадр на тайлы и рендерят последовательно. Это делает их чувствительными к overdraw и fill rate. В отличие от десктопа, где immediate mode GPU прощает больше, на мобильном устройстве каждый лишний draw call или пиксельный шейдер бьёт по производительности. Мы объединяем профилирование, сжатие текстур, настройку батчинга и шейдеров в единый процесс — иначе результата не будет.

Как измерить и сократить draw calls?

Draw Call — это команда CPU отрисовать группу треугольников с определёнными настройками. Каждый draw call требует синхронизации CPU-GPU и передачи данных. На мобильных устройствах с tile-based GPU (PowerVR, Mali, Adreno) это дороже, чем на десктопных immediate mode GPU.

Инструменты: Unity Profiler (GPU Usage), Frame Debugger, а для детального анализа — RenderDoc на Android или Xcode Instruments на iOS. GPU Profiler прямо в редакторе показывает количество batch'ей и SetPass calls. Хорошая цель для мобильного проекта — до 100 draw calls на кадр, реалистичная для mid-core — 150–200.

Основные источники лишних draw calls:

• Static Batching объединяет статические объекты с одинаковым материалом в один mesh при старте сцены. Условие: объекты должны быть помечены Static в Inspector и использовать одинаковый Material — один ассет материала, не одинаковые настройки. Если у двух объектов Material с идентичными параметрами, но это разные Material Instance — батчинг не работает.
• GPU Instancing масштабируется лучше при большом количестве копий одного объекта (деревья, камни, враги одного типа). Dynamic Batching для мелких объектов (до 900 вертексов) работает автоматически, но на практике его отключают ради Instancing.
• Canvas Overlay режим в uGUI: Canvas в Screen Space - Overlay рендерится поверх всего, и каждое изменение в любом UI-элементе помечает весь Canvas Dirty, пересчитывает mesh и делает отдельный draw call. Для UI с анимированными элементами обязательно разносить статичные и динамические элементы по разным Canvas'ам.

Как текстуры влияют на производительность мобильных игр?

Мобильные устройства используют Unified Memory Architecture: GPU и CPU делят одну память. 512 MB RAM — не редкость для бюджетных Android-устройств. Некомпрессированная RGBA32 текстура 2048×2048 = 16 MB. 10 таких текстур на уровне = 160 MB только на текстурах.

Форматы сжатия с аппаратной поддержкой — оптимизация графики под

ASTC — лучший вариант для iOS и современных Android (Adreno 400+ серии, Mali G7x и выше). На старых Android устройствах с OpenGL ES 2.0 ASTC не поддерживается — нужен ETC2 fallback. Unity позволяет задать разные форматы для разных платформ через Texture Importer.

Мипмапы — обязательны для 3D-объектов, не нужны для UI. Мипмап добавляет 33% к размеру текстуры в памяти, но для UI-элементов, которые всегда рендерятся в нативном разрешении, это бесполезный расход. Проверяем через Texture Importer → Generate Mipmaps → отключить для всех UI-спрайтов.

В одном из проектов — мобильная 3D стратегия — при запуске кампании игра падала с OOM на устройствах с 512 MB RAM. Memory Profiler показал 380 MB только на текстурах. Аудит выявил: 60% текстурного бюджета занимали текстуры terrain и environment в формате RGBA32 без сжатия (разработчик отключил сжатие на этапе прототипирования и забыл вернуть), ещё 15% — UI-текстуры с включёнными мипмапами. Решение: перевод всех terrain/environment текстур в ASTC 6×6, UI-текстуры в ASTC 8×8 без мипмапов, для эффектов с альфой — ASTC 4×4. Итог: 142 MB. OOM-крэши прекратились, освободилось 240 MB для игровой логики и звука.

Почему overdraw особенно критичен на мобильных GPU?

Overdraw — это рендеринг одного пикселя несколько раз. Полупрозрачные партикулы, сложные постпроцессинговые эффекты, перекрывающиеся UI-элементы — всё это overdraw. На tile-based мобильных GPU overdraw особенно дорог: каждый раз, когда тайл памяти читается и записывается повторно, это дополнительная работа.

Визуализировать overdraw в Unity: Scene View → Render Mode → Overdraw. Белые пятна — проблема. Особенно следим за particle systems — партиклы часто рендерят десятки полупрозрачных квадов поверх друг друга в одной точке.

Для партикульных систем: ограничивать Max Particles, использовать непрозрачные или cutout шейдеры где это визуально допустимо (cutout дороже прозрачного по fill rate, но дешевле по overdraw в глубину), сортировать партиклы по Sorting Layer чтобы минимизировать пересечение с геометрией.

Для шейдеров: простые Unlit шейдеры в 3–5 раз дешевле Lit на мобильных устройствах. Для декораций дальнего плана, теней на земле, billboard-объектов Unlit достаточен. Lit шейдер с per-pixel lighting только для ближнего плана и ключевых объектов.

Какие инструменты использовать для профилирования?

Начинаем с Unity Profiler подключённым к устройству через USB (Build → Development Build + Autoconnect Profiler). GPU Usage Profiler показывает время рендера по категориям. Frame Debugger — детальный разбор draw calls. Memory Profiler — снимок памяти с разбивкой по категориям.

Для Android дополнительно: Android GPU Inspector (AGI) для устройств с Adreno, Mali Performance Counters для Mali GPU. Они показывают fill rate utilization, texture bandwidth и cache hit rate — метрики, недоступные в Unity Profiler. Проверить поддержку ASTC на устройстве можно через SystemInfo.SupportsTextureFormat(TextureFormat.ASTC_6x6).

Что входит в нашу работу по оптимизации?

• Детальный аудит производительности с полным отчётом и рекомендациями
• Пережатие текстур с выбором оптимальных форматов для каждой платформы
• Настройка батчинга, инстансинга и шейдеров
• Профилирование и устранение узких мест (draw calls, overdraw, memory)
• Консультация и обучение команды заказчика
• Гарантия результата: FPS и стабильность на целевых устройствах

Мы более 5 лет занимаемся оптимизацией мобильных игр, реализовали 20+ проектов на Unity и Unreal Engine. Свяжитесь с нами для аудита вашего проекта. Закажите оптимизацию и получите стабильный FPS на целевых устройствах.

Типичные проблемы производительности игр

Проект запускается на топовых девайсах разработчика без вопросов. На mid-range Android пятилетней давности — 20 fps и перегрев через 5 минут. На iPhone 11 — стабильные 60, но на iPhone XR — просадки в тяжёлых сценах. Мы сталкиваемся с этим каждый день. Оптимизация — не «потом», а архитектурное решение с первого коммита. За 8 лет работы мы провели оптимизацию более чем для 50 игр — от гиперказуалки до AAA на консолях. Гарантируем: после нашего аудита вы получите не просто список проблем, а конкретный план с измеримыми целями и сроками. Закажите аудит производительности — оценим ваш проект за 3 дня и покажем, как снизить draw calls на 40% без потери качества.

Как профилировать производительность игр: инструменты и правила

Прежде чем оптимизировать — измерить. Оптимизация без профилирования — угадывание.

Профилируйте на целевом железе, а не в редакторе. Editor добавляет оверхед — цифры из Play Mode не репрезентативны. Разделяйте GPU и CPU bottleneck: на CPU много draw calls или тяжёлая логика, на GPU — сложные шейдеры или overdraw. Документация Unity: профилирование на устройстве — обязательный шаг для мобильных игр. Типичное время профилирования одного сценария — 5–8 часов, включая сбор метрик на 3–5 устройствах разных поколений.

Как уменьшить количество draw calls: от статического батчинга до SRP Batcher

Draw call — команда CPU к GPU «нарисуй это». Каждый вызов имеет overhead независимо от сложности геометрии. На мобильных 200–300 draw calls за кадр — граница. Цель: минимизировать их количество, объединяя геометрию с одинаковым материалом.

Static Batching объединяет неподвижные меши при сборке. Требование: флаг Static на объекте и одинаковый материал. Эффективен для статичного окружения, но увеличивает потребление памяти — объединённый меш хранится отдельно. В сценах с тысячами статичных объектов следите за памятью через Memory Profiler.

Dynamic Batching объединяет меши в рантайме с жёсткими ограничениями: меньше 900 вертексных атрибутов на меш, одинаковый материал и масштаб. На практике эффективен только для мелких объектов (партиклы, UI). В URP по умолчанию отключён — его вытеснил SRP Batcher.

SRP Batcher — не классический батчинг, а оптимизация CPU-overhead при подготовке draw calls. Вместо того чтобы каждый кадр заново загружать uniform-данные шейдера, SRP Batcher кэширует их в GPU-памяти и обновляет только изменившиеся. Draw calls остаются прежними по количеству, но каждый занимает меньше времени CPU — иногда в 2–3x по CPU-времени рендера. Требование: шейдер должен быть совместим с SRP Batcher (декларировать per-object свойства в UnityPerDraw CBUFFER). Стандартные URP Lit/Unlit шейдеры совместимы. Кастомные — проверяем в Inspector материала: SRP Batcher compatible: Yes/No. Для включения убедитесь, что в URP Asset опция SRP Batcher активна, а для кастомных шейдеров используйте макрос UNITY_INSTANCING_BUFFER и объявляйте per-object свойства в блоке CBUFFER_START(UnityPerDraw). После включения в Profiler должно снизиться время RenderLoop.Draw на CPU.

GPU Instancing — для множества копий одного меша с одним материалом (деревья, трава, NPC). Отправляет один draw call с массивом per-instance данных. Включается на материале: Enable GPU Instancing. Ограничение: все инстансы в одном batch должны иметь одинаковый материал и меш. Graphics.DrawMeshInstanced / Graphics.DrawMeshInstancedIndirect — для процедурного рендеринга без GameObject overhead.

Выбор метода зависит от сценария: Static Batching подходит для статичного окружения, SRP Batcher выигрывает в проектах с множеством уникальных материалов, GPU Instancing незаменим для массовых объектов (лес, толпа), Dynamic Batching — только для мелких и редких случаев. На практике мы комбинируем всё, начиная с профилирования.

Подробнее о технологии — на Wikipedia.

Почему оптимизация памяти критична для мобильных игр?

Мобильные платформы — жёсткие ограничения по RAM. iOS убивает приложение при превышении памяти без предупреждения (memory pressure kill). Android — аналогично, но с onLowMemory callback. Целевые бюджеты: iOS — <1 GB для современных устройств, <512 MB для поддержки iPhone 8/X; Android — <800 MB для широкой совместимости (ОС занимает 400–600 MB). Типичная экономия после нашей оптимизации — 30–50% оперативной памяти при сохранении качества.

Addressables и Asset Bundles: как не превысить бюджет

Загружать всё сразу при старте — неприемлемо для больших проектов. Addressables (надстройка над Asset Bundles) — система адресуемой асинхронной загрузки ассетов. Явная выгрузка: Addressables.ReleaseInstance / Addressables.Release. Addressables не выгружают ассеты автоматически при уничтожении объекта. Типичная ошибка: Addressables.InstantiateAsync в цикле без Release — память растёт до краша. Reference counting: ассет выгружается только когда все его handles освобождены. Архитектурный паттерн: сервис/менеджер держит handle загруженного ассета, освобождает при переходе между сценами.

Groups и Bundle Strategy: группируем ассеты по логике загрузки. Например, все ассеты одного уровня — в один bundle, шаренные (UI, шрифты) — в отдельную группу с Prevent Updates. Такая стратегия экономит до 30% памяти.

Texture Memory: откуда берётся 70% занимаемого объёма

Текстуры — основной потребитель памяти. Анализ через Memory Profiler: вкладка All Of Memory → Texture2D — сразу виден список самых тяжёлых текстур. На практике мы находим текстуры с завышенным Max Size (4096 для мобильной иконки — типичная ошибка). Меры: Mipmap для 3D-текстур (включить), для UI (выключить); Streaming Mipmaps для open world — загружает mip-уровни по мере приближения камеры. Крассовская проблема: текстуры, на которые ссылаются неиспользуемые Materials, остаются в памяти — Memory Profiler покажет reference chain. Удаляйте лишние материалы. После замены всех текстур формата RGBA32 на ASTC 6×6 на Android экономия достигает 60% без потери качества.

GC Allocations: как устранить фризы в Hot Path

C# garbage collector в Unity — stop-the-world. Если за кадр аллоцировано много heap-памяти, GC-пауза вызывает видимый фриз. Цель: нулевые аллокации в hot path (Update, FixedUpdate, рендер). Типичные источники: string конкатенация в Update (заменяем на StringBuilder), LINQ в hot path (ручные циклы с предаллоцированными списками), GetComponent<T>() каждый кадр (кэшируем в Awake/Start), boxing value types при передаче в object параметры. После профилирования с помощью Unity Profiler мы снижаем аллокации в hot path на 95% — фризы исчезают.

LOD и Culling: как отсечь лишние 40% draw calls

LOD Group — переключение на упрощённую геометрию при удалении объекта от камеры. Стандарт для 3D окружения: LOD0 (100%), LOD1 (30–50% треугольников), LOD2 (10–15%), Culled. Для мобильных порог Culled ставим агрессивнее — меньше рисуем за кадр.

Occlusion Culling — Unity не рендерит объекты за стенами. Требует запечённые occlusion данные. Для indoor сцен снижает draw calls на 20–40%.

Frustum Culling работает автоматически — объекты вне FOV камеры не рендерятся. Но draw call на проверку всё равно происходит. Для сцен с тысячами объектов — кастомный spatial partitioning (Quadtree, Octree). В одном из проектов внедрение окклюзионного калинга и LOD снизило общее количество draw calls с 2800 до 450 на Android.

Оптимизация VR: как удержать 72 FPS на Quest 3

VR — отдельный класс задач. Фреймрейт 72/90 Hz нельзя нарушать, иначе motion sickness. Дополнительно к стандартным методам: Single Pass Instanced Rendering — рендер для обоих глаз за один проход (снижает draw calls в 2 раза); Fixed Foveated Rendering (Quest) — снижение разрешения на периферии; Late Latching (Quest 3) — обновление позиции контроллера максимально поздно перед рендером; Dynamic Resolution в URP/HDRP — автоматическое снижение разрешения рендера при просадке fps. Для Quest профилируем через OVR Metrics Tool — показывает CPU/GPU time прямо в гарнитуре. После применения этих методов частота кадров на Quest 2 стабилизируется на 72 FPS даже в сценах с 1.5 млн полигонов.

Что входит в работу по оптимизации: этапы и сроки

Мы предлагаем комплексную услугу «под ключ»:

1. Профилирование на целевых устройствах — сбор метрик (FPS, draw calls, память, GC). Анализируем 5–7 основных сценариев за 3–5 рабочих дней.
2. Отчёт с приоритетами — какие проблемы критичны, какие можно отложить. Приоритеты выставляем на основе влияния на игровой опыт.
3. Внедрение оптимизаций — батчинг, LOD, Addressables, шейдеры, occlusion culling. Средний цикл внедрения — 2–4 недели.
4. Повторное профилирование — замер улучшений. Типичный прирост FPS — 30–60% на мобильных устройствах.
5. Документация — рекомендации по поддержке и дальнейшей разработке.
6. Обучение команды — как не допустить регресса. Проводим воркшопы по профилированию и оптимизации.

Средняя экономия заказчика за счёт предотвращения переделок на поздних этапах — от $15,000 до $40,000 на проекте. Получите консультацию — мы бесплатно оценим ваш проект и покажем потенциал оптимизации. Обращайтесь, чтобы узнать точные сроки и стоимость для вашего стека.