Профилирование CPU и GPU ресурсов игр: найдём и устраним тормоза

Профилирование CPU и GPU ресурсов игр: найдём и устраним тормоза

Отметим: когда игра тормозит, первый инстинкт — открыть Stats в Game View и смотреть на FPS. Это бесполезно. Stats показывает усреднённое значение, не видит спайков, не разделяет CPU от GPU, не показывает, какой именно код съедает время. Для реальной диагностики нужен Profiler в режиме Standalone на целевом железе. Наша команда с 10-летним опытом и более чем 50 успешными проектами ежедневно решает такие задачи. Вместо гадания на fps-счётчике предлагаем системный подход: от снятия профиля до внедрения оптимизаций под ключ.

Разница между «42 fps в среднем» и «42 fps с просадками до 18 на каждом третьем кадре» — это разница между комфортной игрой и ощущением, что игра сломана. И это видно только через frame time graph, не через fps-счётчик. Мы гарантируем стабильный результат на целевых платформах.

Как отличить CPU bottleneck от GPU bottleneck?

Первый вопрос при любой оптимизации: где узкое место. Если CPU тормозит → GPU ждёт. Если GPU тормозит → CPU ждёт. Смешивать методы оптимизации без понимания этого — трата времени.

Диагностика в Unity Profiler: открываем CPU Usage модуль, смотрим на Gfx.WaitForPresent или Graphics.PresentAndSync. Если эти маркеры занимают 8+ мс из 16.6 мс бюджета кадра — вы GPU-bound. CPU уже отдал всё GPU и просто ждёт.

Если же PlayerLoop, Physics.Processing или ваши скрипты занимают большую часть frame time, а Gfx.WaitForPresent минимален — вы CPU-bound.

Это принципиально разные пути оптимизации. GPU-bound: уменьшаем сложность шейдеров, overdraw, fill rate. CPU-bound: оптимизируем скрипты, используем Job System, сокращаем количество Update()-вызовов.

Глубокое профилирование CPU

Deep Profile в Unity — мощный инструмент, но с overhead'ом: он инструментирует каждый вызов метода, и сам по себе замедляет игру. Используем только для точечной диагностики конкретной подсистемы, не как постоянный режим.

Отметим: что ищем в CPU профиле:

• Managed heap allocations в Update(). Coloured Marker в Profiler — GC.Alloc. Любая аллокация в горячем пути (Update, FixedUpdate, OnCollisionEnter) потенциально вызовет GC.Collect в будущем. GC.Collect на мобильных устройствах — это 2–20 мс spike. Исправляется через кэширование ссылок, object pools, string interning, замену LINQ на ручные циклы.

• Physics.Processing занимает > 4 мс. Слишком сложные Collider'ы (Mesh Collider вместо Capsule), слишком маленький Fixed Timestep, слишком много Rigidbody с ContinuousCollisionDetection. Первым делом — Physics Debugger: visualize sleep state всех Rigidbody, искать те, что не спят без причины.

• NavMesh.CalculatePath каждый кадр для 40 агентов. NavMeshAgent обновляется по умолчанию в каждом FixedUpdate. Для большого количества агентов — разбиваем на группы с обновлением через кадр или через N кадров в зависимости от дистанции до игрока.

Когда использовать RenderDoc вместо Unity Frame Debugger?

RenderDoc — обязательный инструмент для любого серьёзного GPU-профилирования. Подключается к Android/PC, делает capture одного кадра, показывает каждый draw call с временем на GPU, Input/Output текстуры, pipeline state. Именно здесь видно, какой шейдер съедает 60% GPU time. RenderDoc даёт в 10 раз больше деталей, чем встроенный Frame Debugger.

Unity Frame Debugger — легче в использовании, но менее детальный. Показывает порядок отрисовки, почему объекты не батчатся, состояние render targets. Для первичной диагностики вполне достаточен.

На мобильных устройствах — ARM Streamline (Mali) или Snapdragon Profiler (Adreno). Они показывают метрики, недоступные в Unity: bandwidth memory, ALU utilization, texture cache miss rate. Именно texture cache miss (много маленьких текстур вместо атласа) или высокий bandwidth (текстуры без mipmaps) часто является настоящей причиной тормозов там, где Draw Calls казались в норме.

Реальный кейс: мобильный аркадный раннер, 45 fps на Snapdragon 730. CPU профиль — чисто, скрипты занимают < 3 мс. GPU — подозрительно много fill rate по данным Snapdragon Profiler. RenderDoc показал: кастомный distortion-шейдер на воде семплировал GrabPass (Screen Space Texture) на каждом кадре, плюс стоял в Transparent queue поверх трёх других слоёв с блендингом. Замена GrabPass на предзапечённую кубмап-текстуру для фоновых отражений + перенос water mesh ниже по Z-order убрали 11 мс с GPU time. Итог: 58–60 fps стабильные.

Процесс профилирования

Сначала определяем целевые метрики: fps бюджет (30/60/120), допустимый frame time (16.6/8.3 мс), платформа. Без целевых метрик непонятно, что считать «достаточно хорошим».

Профилируем в нескольких сценариях: idle (персонаж стоит), пиковая нагрузка (бой с максимальным количеством эффектов), переход между сценами. Каждый сценарий — отдельный Profiler capture.

Создаём отчёт с конкретными bottleneck'ами, их весом в ms и предложениями по устранению. Приоритизируем по соотношению усилий к приросту производительности.

Сравнение инструментов профилирования GPU

Что входит в работу по профилированию

После завершения аудита вы получаете:

• Детальный отчёт с указанием всех узких мест и их влиянием на производительность.
• Исправленные сцены и настройки проекта с улучшениями.
• Рекомендации по дальнейшей поддержке и мониторингу.

Мы работаем под ключ: от первичного анализа до внедрения фиксов. Оценим ваш проект и предложим оптимальный план. Свяжитесь с нами, чтобы получить консультацию.

Стоимость определяется после изучения проекта и целевых платформ.

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

Без профилирования вы тратите время на догадки. Вместо того чтобы оптимизировать реальные узкие места, вы можете улучшить то, что не нужно. Статистика показывает: до 70% проблем производительности игр связаны с неправильной оценкой bottleneck'ов. Мы за 10+ лет работы убедились: каждая вторая игра на стадии финального полиша имеет скрытые тормоза, которые выявляются только при профилировании на целевом железе. Наш опыт гарантирует, что вы получите стабильный FPS без лишних затрат.

Unity Profiler Documentation — официальная документация по Profiler.

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

Проект запускается на топовых девайсах разработчика без вопросов. На 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 на проекте. Получите консультацию — мы бесплатно оценим ваш проект и покажем потенциал оптимизации. Обращайтесь, чтобы узнать точные сроки и стоимость для вашего стека.