Глубокий анализ системы Adaptive Performance в разработке мобильных игр на движке Unity
В экосистеме современной разработки мобильных игр геометрический рост аппаратных возможностей открыл путь к запуску требовательных к графике игр на портативных устройствах. Однако мобильные платформы, в отличие от настольных или консольных систем, лишены активных механизмов охлаждения (вентиляторов или систем жидкостного охлаждения). В архитектуре однокристальной системы (SoC) центральный процессор (CPU), графический процессор (GPU), контроллеры памяти и сетевые модули находятся вместе в пределах миллиметровой зоны.¹ Постоянная работа этих компонентов на высоких тактовых частотах неизбежно приводит к выделению огромного количества отходящего тепла.
Когда температура устройства достигает критических порогов, операционная система задействует защитный механизм под названием Thermal Throttling (термотротлинг), чтобы защитить железо от физических повреждений и предотвратить нарушение химической структуры аккумулятора.² Этот механизм внезапно и агрессивно снижает тактовые частоты CPU и GPU. С точки зрения разработчиков игр, это означает резкое падение количества кадров в секунду (FPS), увеличение задержки ввода (input lag) и полное ухудшение игрового опыта.³ Именно в этот момент в игру вступает система Unity Adaptive Performance (адаптивная производительность), которая создает мост между программным и аппаратным обеспечением, нацеленный на проактивную адаптацию игрового движка к тепловым динамикам устройства. В этом отчете, начиная с анатомии часто встречающихся в процессе разработки предупреждений о конфигурации, подробно рассматриваются — с академической и профессиональной глубины — базовая архитектура пакета Adaptive Performance, алгоритмы масштабирования, стратегии интеграции и предоставляемые им преимущества оптимизации.
Первопричины предупреждения «Adaptive Performance Settings» и решения по конфигурации
Когда в игровом движке Unity запускается новый мобильный проект или существующий проект настраивается для компиляции под мобильные платформы (Android, iOS), на экране консоли часто появляется следующее предупреждение или схожие сообщения: «No Adaptive Performance provider package installed. Adaptive Performance requires a provider to get information during runtime. Please install a provider such as Adaptive Performance Samsung (Android) from the Adaptive Performance Settings».⁴ Основной причиной этого предупреждения, замедляющего процессы разработки, является принцип работы модульной системы управления пакетами Unity и уровня абстракции оборудования (Hardware Abstraction Layer).
Unity включает базовый пакет Adaptive Performance в проект как предустановленный (pre-installed), особенно при создании проектов с такими шаблонами, как «Mobile 2D», «Mobile 3D» или «Universal Render Pipeline (URP)».⁵ Однако сам по себе базовый пакет не имеет нативных библиотек, способных считывать данные с аппаратного обеспечения устройства или вмешиваться в работу операционной системы. Чтобы пакет стал функциональным, в проект необходимо добавить и настроить специализированный модуль «Provider» (поставщик) для целевой операционной системы (Android и т.д.) или тестовой среды.⁶ Если модуль провайдера отсутствует, базовый пакет не может получить доступ к датчикам оборудования во время выполнения (runtime) и выдает это предупреждение, уведомляя разработчика. Решение предупреждения и шаги по настройке имеют серьезные методологические различия в зависимости от целевой платформы разработки и используемой версии Unity.
Решение этого предупреждения, с которым сталкиваются в процессе разработки, должно рассматриваться на уровне платформ. Поскольку разрешения операционных систем на доступ к аппаратным API различаются, решения, предлагаемые Unity, также отличаются.
Целевая платформаТехническая причина предупрежденияМетодология решения, которую необходимо применитьAndroidОтсутствие в проекте нативного плагина для связи с ADPF или Samsung GameSDK.Через Unity Package Manager следует установить пакет Adaptive Performance Android Provider или, при наличии конкретной цели под устройство, пакет Samsung (Android) Provider.⁶ Затем в меню Edit > Project Settings > Adaptive Performance нужно активировать соответствующий провайдер.iOS (Apple)Отсутствие официального аппаратного провайдера (provider), поддерживаемого Unity для Adaptive Performance в экосистеме iOS.⁴При добавлении набора функций Mobile в проект Adaptive Performance поставляется как зависимость (dependency) и не может быть удален. Для сборок iOS это предупреждение безвредно, его можно проигнорировать (ignore) или удалить модуль Mobile из менеджера пакетов для разрыва зависимости.⁴Настольный редактор (PC/Mac)Отсутствие на операционных системах Windows или macOS тепловых датчиков и SoC-архитектур, присущих мобильным устройствам.Для симуляции мобильных условий на компьютере разработчика следует установить провайдер Simulator (Desktop) и создать виртуальную тепловую среду с помощью окна Device Simulator.²Unity 6 (Build Profiles)Забывчивость в добавлении специфичной для профиля конфигурации в дополнение к настройкам Adaptive Performance основного проекта в профилях сборки (Build Profiles), появившихся в Unity 6.В меню File > Build Profiles для выбранной платформы необходимо нажать кнопку Add Settings > Adaptive Performance Settings и назначить провайдер. В версиях Unity 6.000.x отсутствие этих настроек приводит к ошибке «No default loader found».⁹
По своей сути это предупреждение является не ошибкой компиляции (compile), а уведомлением об отсутствии оптимизации. Разработчик может проигнорировать это предупреждение и запустить игру на устройстве; однако в этом случае игра будет работать полностью «вслепую» относительно теплового состояния оборудования и неизбежно подвергнется безжалостным вмешательствам операционной системы в виде термотротлинга.
Архитектура системы Adaptive Performance и экосистема поставщиков (Provider)
Adaptive Performance устанавливает двусторонний коммуникационный мост между механизмами принятия решений игрового движка и физическим оборудованием. Уровень сбора данных этой архитектуры формируется провайдерами (providers). Поскольку крайне фрагментированная (fragmented) структура экосистемы Android делает невозможным работу единого аппаратного API на всех устройствах, Unity преодолевает эту проблему с помощью специфических провайдеров, интегрируемых в различные аппаратные фреймворки (frameworks).
Интеграция Android Dynamic Performance Framework (ADPF)
Основной модуль «Android Provider» от Unity построен на архитектуре Android Dynamic Performance Framework (ADPF), представленной Google в операционной системе Android 12 и более поздних версиях.² ADPF — это революционный набор API, обеспечивающий прямой диалог между играми и управлением терморегуляцией операционной системы. В традиционных подходах операционная система пытается угадать, какому кадру (frame) игры требуется больше вычислительной мощности процессора, и эти догадки часто приводят к назначению неверных тактовых частот CPU.
Провайдер Android для Unity Adaptive Performance, напротив, обеспечивает непрерывный поток данных в операционную систему с помощью «Performance Hint API» (интерфейса подсказок производительности).⁶ При рендеринге каждого кадра движок сообщает системе ADPF целевое время этого кадра (например, 16.6 миллисекунды прицеливаясь на 60 FPS) и реальное время (actual duration), потраченное CPU и GPU на его завершение.⁶ Благодаря этому циклу точной обратной связи операционная система Android повышает частоту ядер CPU ровно настолько, насколько это необходимо игре. Когда устройство начинает нагреваться, операционная система отправляет тепловые предупреждения обратно в Unity, благодаря чему внутриигровые графические масштабировщики задействуются до возникновения замедлений на аппаратном уровне.⁶ Стабильная версия Android Provider 1.2 и выше (версии, преодолевающие ограничения устройств Pixel) поддерживается начиная с Adaptive Performance 5.0 и Unity 2021.3.⁶
Samsung GameSDK и специфические аппаратные оптимизации
Поскольку Samsung обладает одной из крупнейших рыночных долей в экосистеме Android, она предлагает специализированный аппаратный интерфейс под названием GameSDK, чтобы раздвинуть границы возможностей собственного оборудования. Провайдер Adaptive Performance Samsung (Android) от Unity выходит за рамки стандартных функций ADPF, позволяя получать метрики, которые проникают непосредственно вглубь SoC от Samsung.²
Провайдер Samsung охватывает огромный спектр устройств с операционной системой Android 10 и выше, поддерживающих GameSDK 3.2 и более поздние версии. Эта область охвата простирается от устройств начального уровня до флагманских, предоставляя разработчикам широчайшее поле для оптимизации.
Поддерживаемые серии Samsung GalaxyМодели (GameSDK 3.2+ / Android 10+)Серия Galaxy SСерые S9, S10e, S10, S10+, S10 Lite, S20, S20+, S20 Ultra, S20 Lite, S21, S21+, S21 Ultra, S22, S22+, S22 Ultra¹³Серия Galaxy NoteNote9, Note10, Note10+, Note10 Lite, Note20, Note20 Ultra¹³Серия Galaxy Z (складные)Z Fold2¹³Серия Galaxy AA10s, A11, A21s, A31, A41, A50s, A51, A51 5G, A71, A71 5G, A80, A8 2018, A9 2018, A90 5G¹³Серия Galaxy XcoverXcover 4s, Xcover Pro¹³
Одним из важнейших аппаратных преимуществ, предоставляемых этими устройствами, является технология « Variable Refresh Rate» (переменная частота обновления — VRR).¹³ Поддержка VRR на данный момент активно используется на устройствах Galaxy S20, S21, S22 и Note 20.¹³ Когда Adaptive Performance обнаруживает, что устройство достигло своих пределов, и принимает решение снизить значение FPS в игре, например, с 60 до 45, она отправляет команду в API Samsung VRR, чтобы также снизить физическую частоту обновления экрана до 45 Гц.¹⁶ Эта синхронизация не только предотвращает разрывы экрана (screen tearing), но и предотвращает избыточное энергопотребление панели дисплея, внося серьезный вклад в более быстрое охлаждение устройства. Кроме того, провайдер Samsung на устройствах с GameSDK 3.5 (Android 12) и выше также предоставляет возможность доступа к данным «Cluster Info», отображающим распределение нагрузки больших и малых ядер в архитектуре процессора big.LITTLE.¹³
Тепловые метрики и алгоритмы обнаружения узких мест (Bottleneck)
Инженерная составляющая, стоящая за способностью Adaptive Performance предлагать проактивную оптимизацию, основана на системах анализа датчиков, которые непрерывно собирают данные. Интерфейс IAdaptivePerformance, создаваемый во время выполнения игры, считывает наборы данных от оборудования в двух основных категориях: тепловая обратная связь (Thermal State Feedback) и тайминг кадров (Frame Timing). На основе этих данных принимается решение о том, что именно является главным элементом (узким местом), ограничивающим производительность системы в данный момент.
Тепловая обратная связь и уровни предупреждений
Тепловое состояние устройства оценивается не просто по простому показателю градусов Цельсия. Тепловые динамики отслеживаются по трем различным метрикам, которые нормализованы и аналитически обработаны ²:
Первая метрика, TemperatureLevel (уровень температуры), представляет собой значение с плавающей запятой (float), нормализованное в диапазоне от 0.0 до 1.0 (где 0.0 — стандартная комнатная температура / температура эксплуатации, а 1.0 — абсолютный максимальный тепловой порог).² Используя это значение, разработчики могут выводить игроку состояние нагрева устройства в виде графического баров в интерфейсе игры или конструировать собственную логику оптимизации.
Вторая и более прогностическая метрика, TemperatureTrend (тенденция температуры), меняется в диапазоне от -1.0 до 1.0
и представляет собой значение, отражающее математическую производную температуры, то есть скорость ее изменения. 2 Значение 1.0 указывает на то, что устройство нагревается чрезвычайно быстро, в то время как 0 означает, что температура остается стабильной, а -1.0 показывает вход в период агрессивного охлаждения. Для обнаружения этих трендов системой и вычисления действующего среднего обычно требуется около десяти секунд анализа. 2 Третья и самая критическая метрика называется WarningLevel (уровень предупреждения) — это категорическая классификация, определяющая реакцию операционной системы на тепловое состояние. 2
Уровень предупреждения (WarningLevel) Состояние операционной системы Реакция Adaptive Performance в игровом движкеNoWarning (0) Устройство находится в оптимальных температурах. Никакое тепловое замедление не наблюдается. Разрешается рендеринг игры в целевых наивысших разрешении, частоте кадров и визуальном качестве. 2 ThrottlingImminent (1) Тепловая емкость близка к исчерпанию. Операционная система еще не снизила частоты оборудования, но опасность очень близка. Начинается проактивное вмешательство. Задействуются масштабировщики с низким визуальным эффектом (например, уменьшение дальности прорисовки теней), чтобы попытаться предотвратить переход устройства в следующую фазу. 2 Throttling (2) Оборудование достигло критической температуры, и операционная система для самозащиты агрессивно снизила тактовые частоты CPU/GPU. Выставляется самый агрессивный счет за оптимизацию. Целевая частота кадров (Target FPS) драматически снижается, основное разрешение рендеринга ограничивается, и приносятся радикальные жертвы ради возвращения устройства к нормальной температуре. 2
Анализ времени кадров и обнаружение узких мест (Bottleneck)
Неспособность игры достичь скорости 60 кадров в секунду может быть вызвана несколькими аппаратными ограничениями. Первое правило оптимизации — выяснить, вызвана ли проблема нехваткой графического процессора (GPU) или исчерпанием вычислительной мощности центрального процессора (CPU). Для проведения этого анализа Adaptive Performance отслеживает данные averageFrameTime (среднее общее время кадра) и averageGpuFrameTime (среднее время работы GPU) для каждого кадра. 17 Время CPU включает в себя процессы выполнения игровой логики основным потоком Unity и подготовки рендер-потоком данных для отправки на GPU (пакетирование вызовов отрисовки и т. д.). 17 Важная деталь: измерение времени CPU не включает в себя блокировки на уровне операционной системы или время простоя/ожидания (idle/wait times), когда CPU ждет завершения работы GPU. 17 В результате анализа этих данных система относит текущее узкое место (PerformanceBottleneck) к одной из четырех категорий: ● CPU: Внутриигровые алгоритмы искусственного интеллекта, сложные физические вычисления или чрезмерное количество инстанцирования объектов перегружают процессор. 20
● GPU: Многослойные эффекты прозрачности (overdraw), чтение текстур высокого разрешения, тяжелые эффекты постобработки (например, SSAO или Bloom) ограничивают работу графического блока. 22
● TargetFrameRate (Fillrate): Система уже достигла целевой частоты кадров, какого-либо аппаратного ограничения нет, и производительности достаточно даже при работе ниже потенциала оборудования. 2
● Unknown: Промежуточные состояния, когда источник задержки невозможно определить точно.
Разработчики могут подписаться на событие PerformanceStatus.PerformanceBottleneckChangeEvent (с помощью паттерна делегатов), чтобы фиксировать моменты изменения статуса узкого места во время игры и соответствующим образом реагировать с помощью алгоритмов. 23 Например, когда узкое место внезапно смещается на CPU, частоту сканирования поля зрения (raycast) юнитов искусственного интеллекта в открытом мире можно мгновенно снизить с 60 до 15 раз в секунду, чтобы сразу уменьшить математическую нагрузку на процессор.
Движок принятия решений и выполнения: Indexer и масштабировщики (Scalers)
Механизм, обеспечивающий автономную работу системы Adaptive Performance, основан на безупречной слаженности работы двух основных компонентов: мозга под названием Indexer (индексатор) и исполнительных органов под названием Scalers (масштабировщики).
Механизм Indexer (Индексатор)
Indexer — это центральный координатор, который непрерывно пропускает получаемые с устройства сложные тепловые тенденции и данные об узких местах через математический фильтр для расчета текущего «Индекса качества» игры. 19 Главная задача Indexer заключается в предотвращении визуальной несогласованности (oscillation), которая возникает при постоянном изменении качества игры из-за каждого небольшого колебания температуры или FPS в оборудовании. Для обеспечения этой стабильности в Project Settings можно задать параметры Thermal Action Delay (задержка теплового действия) и Performance Action Delay (задержка действия производительности) в секундах. 23 Даже если система чувствует узкое место, в течение этого заданного времени задержки она убеждается в устойчивости ситуации, после чего принимает решение о действии и отправляет подключенным масштабировщикам сигнал о снижении качества (StateAction.Decrease). 23
Анализ математического и визуального влияния масштабировщиков (Scalers)
Масштабировщики — это скрипты, изменяющие специфические особенности конвейера рендеринга (Render Pipeline) или физического движка Unity во время выполнения (runtime). 19 Уровень (Level) каждого масштабировщика по умолчанию равен нулю. С каждым сигналом «снизить качество» от Indexer этот уровень возрастает; по мере повышения уровня детализация функции, контролируемой масштабировщиком, уменьшается. 19 Время и порядок задействования масштабировщиков определяются трехмерной матрицей принятия решений 19 :
1. Целевое узкое место (Targeting Bottleneck): Если в результате анализа выясняется, что узким местом является GPU, Indexer пропускает масштабировщики, оптимизирующие CPU, и напрямую задействует масштабировщики, нацеленные на GPU (например, разрешение).
2. Самый низкий уровень (Lowest Level): Приоритет отдается функциям, уровень которых еще не был повышен (сохраняющим исходное качество).
3. Визуальное влияние (Visual Impact): Вероятность того, что игрок заметит снижение качества функции. Классифицируется как «Низкое» (Low), «Среднее» (Medium) или «Высокое» (High). 19 Система всегда начинает с уменьшения функций, имеющих низкое визуальное влияние.
Система предлагает чрезвычайно широкий спектр масштабировщиков как для стандартного конвейера рендеринга, так и для Universal Render Pipeline (URP). В следующей таблице подробно описаны аппаратные цели этих масштабировщиков и их теоретическое влияние внутри приложения.
Класс масштабировщика Целевое узкое место Визуальное влияние Теоретическое и практическое влияние на конвейер рендеринга (Render Pipeline) AdaptiveFramerate CPU / GPU / Fillrate Высокое Изменяет переменную Application.targetFrameRate игры в заданных пределах. Особенно эффективно при отключенной вертикальной синхронизации. Снижение с 60 FPS до 30 FPS создает радикальный период охлаждения за счет увеличения времени простоя всех компонентов на кристалле. 19 AdaptiveResolution GPU / Fillrate Высокое Динамически снижает масштаб разрешения обработки экрана (Resolution Scale). 19
В проектах URP работает через Render Scale. Поскольку это геометрически уменьшает скорость заполнения пикселей (fillrate), это мощнейшее средство для преодоления тепловой нагрузки GPU, но оно напрямую ухудшает четкость изображения. 15 AdaptiveLOD CPU / GPU Среднее Манипулирует расстояниями перехода (LOD bias) для уровней детализации (Level of Detail — LOD) трехмерных моделей в сцене. 18 Позволяет низкополигональным версиям оставаться на экране даже при приближении камеры к моделям, уменьшая вызовы отрисовки CPU (draw calls) и вычисления вершин GPU. 18 AdaptiveShadowmapResolution GPU Среднее/Низкое Снижает пиксельное разрешение карты теней в URP. Поскольку пикселизация краев теней при интенсивном движении на экране трудновосприимчива когнитивно, это разгружает пропускную способность памяти GPU без ущерба для качества. 19 AdaptiveShadowCascade CPU / GPU Среднее Уменьшает количество каскадов для направленных источников света в URP. Каждый каскад теней требует повторного рендеринга (draw call) отбрасывающих тени объектов в сцене. Уменьшение количества каскадов напрямую снижает нагрузку на CPU. 19 AdaptiveViewDistance CPU / GPU Высокое Сужает плоскость дальней отсечки (far clip plane) основной камеры, гарантируя, что удаленные объекты вообще не попадают в поток рендеринга (frustum culling). 19 Это один из самых критических этапов оптимизации, особенно в играх с открытым миром. 15 AdaptiveLayerCulling CPU / GPU Среднее Вместо сокращения общей дальности прорисовки настраивает дальность видимости для определенных слоев (Layers) Unity.
Например, ограничение дальности рендеринга слоя деталей окружения (трава, мелкие декорации) повышает производительность за счет удаления мелких деталей при сохранении крупных сооружений вокруг игрока. 16 AdaptivePhysics CPU Yüksek Модифицирует шаги обновления (fixedDeltaTime) или количество итераций физического движка Unity (PhysX или Box2D), снижая нагрузку на CPU. 2 Физические вычисления — одни из главных виновников узких мест на базе CPU. 21 AdaptiveBatching CPU Низкое Контролирует процессы динамической группировки (Dynamic Batching). Разгружает CPU в ситуациях, не требующих чрезмерных вычислений вершин. 19 AdaptiveDecals CPU / GPU Низкое Ограничивает дальность рендеринга или количество декалей (следы пуль, пятна крови на стенах) в системе URP, снижая нагрузку overdraw на этапе отрисовки материалов. 2
Разработчики не обязаны ограничиваться только стандартными масштабировщиками. Настоятельно рекомендуется разрабатывать «Пользовательские масштабировщики» (Custom Scalers), соответствующие специфической механике игры. 2 Чтобы написать пользовательский масштабировщик, достаточно унаследовать класс AdaptivePerformanceScaler и переопределить (override) метод OnLevel(), наряду с такими базовыми свойствами, как VisualImpact, Target, MaxLevel. 19 Например, в игре, происходящей в туманной обстановке, написание пользовательского масштабировщика позволяет увеличивать плотность тумана по мере роста температуры (Adaptive Fog). Таким образом, дальность видимости игрока естественным образом сужается, а дальность прорисовки камеры на заднем плане сокращается, создавая серьезную иллюзию оптимизации. 15
Режимы контроля производительности и управление тактовой частотой (Clock Frequency)
Adaptive Performance не только ограничивает графические возможности внутри игрового движка, но также имеет способность прямо или косвенно вмешиваться в подачу электроэнергии и тактовые частоты CPU и GPU, предоставляемые операционной системой. Работа процессоров на максимальных тактовых частотах создает асимптотическую неэффективность: то есть за счет получения небольшого количества дополнительной вычислительной мощности потребляется колоссальное количество энергии и выделяется тепло. 17
Для управления этим энергетическим балансом интерфейс Adaptive Performance предлагает три различных режима управления (PerformanceControlMode): «Системный», «Ручной» и «Автоматический». 20
Системный режим (System Performance Control): Это режим по умолчанию, действующий в системах за исключением Android-провайдера (например, при симуляции на ПК). Операционная система сама определяет частоты CPU/GPU традиционными методами, Adaptive Performance не вмешивается в железо, а лишь снижает внутриигровую графику. 20
Ручной режим (Manual Performance Control): Режим, в котором разработчик может напрямую назначать переменные
Instance.DevicePerformanceControl.CpuLevelиGpuLevelв диапазоне от 0 до максимального уровня. 23 Использование этого режима управления категорически не рекомендуется нигде, кроме очень специфических бенчмарк-тестов. 17 Если разработчик, не имеющий глубоких знаний о тепловых ограничениях мобильного железа и характеристиках разряда батареи, будет постоянно удерживать уровень CPU на высоте, устройство быстро перегреется, операционная система задействует защитные механизмы, загнав игру в фазу «тройтлинга» (Throttling), а батарея будет бессмысленно разряжаться. 20Автоматический режим (Automatic Performance Control): Это самый безопасный, эффективный и настоятельно рекомендуемый режим управления. 17 Все, что нужно сделать разработчику — это задать целевую частоту кадров игры (например, 30 или 60) с помощью
Application.targetFrameRate. 23 Автоматический режим в фоновом режиме анализирует температуру устройства, время рендеринга и рабочее окружение (находится ли игрок в меню или в самом процессе игры). 20 Если игра с легкостью достигает цели в 60 FPS, вместо того чтобы заставлять процессор работать на полную мощность без всякой надобности, он незаметно снижает тактовые частоты CPU и GPU. Частота кадров остается равной 60, но железо потребляет гораздо меньше электричества, что позволяет игре оставаться прохладной, а батарее держаться часами (Battery Life Preservation). 20
Временное усиление мощности: Режим Boost (Режим форсирования)
В определенные моменты мобильных игр вместо стабильной производительности требуется кратковременное получение огромной вычислительной мощности. Для таких специфических сценариев Adaptive Performance содержит API «Boost» (Форсирование). 23 При вызове режима Boost минимальная (minimum) рабочая частота CPU или GPU на временной период приравнивается к максимальной (maximum) рабочей частоте, что заставляет железо работать на своем предельном потенциале. 23
Места, где режим Boost должен использоваться стратегически 23 :
● Минимизация времени загрузки (load time) тяжелых моделей, помещаемых в память, на экранах ожидания при запуске игры или уровней (Loading Screens).
● Устранение задержек, возникающих во время распаковки крупных пакетов, загружаемых по сети (Network), или в процессе асинхронной обработки данных.
● Предотвращение секундных микрофризов (hitches), с которыми может столкнуться игрок на этапах компиляции шейдеров (Shader Compilation) или процедурной генерации контента.
Однако активация режима Boost потребляет огромный ток от батареи устройства и мгновенно повышает температуру SoC. 23 Если операционная система уже вошла в фазу Throttling (Узкое место / Тройтлинг) (устройство перегрето), то во избежание повреждения оборудования запрос Boost от Unity или команды настройки уровней ручного CPU/GPU будут напрямую отклонены операционной системой, а управление будет принудительно переведено в «Системный режим». 23 Крайне важно, чтобы разработчики использовали этот интерфейс исключительно на экранах загрузки, где игрок ожидает в пассивном состоянии, и на секундные интервалы времени.
Интерфейс разработчика: Использование C# API и Visual Scripting (Визуальное скриптование)
Гибкость пакета Adaptive Performance заключается в том, что она позволяет разработчикам использовать автономную систему без написания ни единой строки кода, если они того пожелают, либо выстраивать специальную логику, затрагивающую саму суть игры.
Событийно-ориентированное (Event-Driven) программирование через C# API
Разработчики, желающие программно получить доступ к тепловым данным системы, обращаются к ним через создаваемый вместе с пакетом объект-одиночку (Singleton) UnityEngine.AdaptivePerformance.Holder.Instance (или Mobile.AdaptivePerformance.Holder в новых версиях). 18 В частности, для отслеживания момента, когда устройство вот-вот столкнется с падением производительности из-за перегрева (ThrottlingImminent), прослушивается событие (delegate) IThermalStatus.ThermalStatus.ThermalEvent. 2
При срабатывании события (например, при поступлении сигнала о нагреве) состояние анализируется с помощью конструкции switch-case, после чего вносятся изменения в игровую механику. 2 Если уровень предупреждения равен Throttling, кадровая частота снижается с 60 до 15 или 30; если предупреждение отсутствует, игра возвращается к целевому значению в 60 FPS. 2 Аналогичным образом, если узкое место находится на стороне ЦП, с помощью специального скрипта (script) можно деактивировать часть активных ИИ-агентов на карте, мгновенно разгрузив процессор. 2
Интеграция Visual Scripting (Визуального скриптования)
Для не программирующих технических художников (technical artists) и геймдизайнеров в Unity версии 5.0 и новее реализована полная поддержка C# API посредством пакетов Visual Scripting. 29
После добавления пакета Visual Scripting в проект необходимо перейти по пути Edit > Project Settings > Visual Scripting > Node Library > Regenerate Units, чтобы узлы (nodes) Adaptive Performance добавились в интерфейс Fuzzy Finder. 27
Благодаря этой интеграции предоставляется доступ к ряду специальных узлов 30 :
● Термальные узлы: узел On Thermal Metric срабатывает мгновенно при изменении уровня теплового предупреждения устройства, процентного соотношения температуры (Temperature Level) и тенденции изменения температуры (Trend). Выходной контакт этого узла можно связать с логикой, которая напрямую отключает тяжелый источник света или систему частиц на сцене.
● Узлы производительности: узел On Bottleneck сигнализирует о том, является ли узким местом ЦП, ГП или пропускная способность заполнения (Fillrate); а узлы Frame Timing и FPS идеально подходят для вывода данных о производительности в реальном времени на игровой экран. Благодаря узлу Cluster Info можно считывать нагрузки на ядра в архитектуре big.LITTLE.
● Узлы Boost и Levels: добавив узел Set Boost в начале блоков загрузки сцены в графе визуального скриптинга, можно максимизировать скорость загрузки без написания кода; а с помощью Get Performance Level — прочитать текущее состояние процессора.
Методология тестирования, профилирования и оптимизации
Добавление системы Adaptive Performance в проект само по себе не решает все проблемы; неправильно сконфигурированная система может слишком рано ухудшить качество графики в игре или оказаться абсолютно бесполезной. Процесс разработки должен опираться на научную методологию измерений и бенчмаркинга (profiling and benchmarking).
Создание базового уровня (Baseline) и А/Б тестирование
Согласно общим практикам оптимизации инженеров Google и Unity, первым шагом должно стать измерение производительности игры до активации ADPF или Adaptive Performance (Baseline). 6 Игру следует установить на физическое мобильное устройство с минимальными целевыми системными требованиями (min-spec) и запустить примерно на двадцать минут, пока устройство не нагреется. 21 Во время этого теста инструмент Unity Profiler подключается к устройству по беспроводной сети (Wi-Fi) (Autoconnect Profiler), чтобы зафиксировать минуты, когда FPS начинает падать, а также значения Frame Time. 1
Затем в проекте активируется система Adaptive Performance с настройками масштабировщиков по умолчанию, и тот же тестовый сценарий запускается заново. 6 Через новую вкладку "Adaptive Performance" в модуле Profiler следует изучить в сравнении друг с другом (бок о бок): на какой минуте устройство выдало предупреждение ThrottlingImminent, какой масштабировщик запустила система (например, AdaptiveResolution) и как это повлияло на время работы ЦП/ГП. 2 Если разработчик обнаруживает такие симптомы, как "Игра на 10-й минуте все еще выдает 60 FPS, но разрешение падает слишком сильно", ему следует поработать с весами масштабировщиков в Indexer и выполнить точную настройку (fine-tuning), специфичную для данной игры. 6
Симуляция в среде рабочего стола: Device Simulator
Хотя тесты на реальных устройствах необходимы, ожидание нагрева и остывания физического телефона снижает скорость итераций на этапе кодирования. Для решения этой проблемы был создан поставщик Simulator (Desktop) Provider. 2 На десктопном компьютере разработчика можно открыть окно Window > General > Device Simulator и искусственно (artificial bottlenecks) вызвать падение уровня заряда батареи, тепловой тренд и узкие места виртуального устройства. 2 Одним щелчком мыши разработчик может перевести состояние виртуального устройства в фазу Throttling и за считанные секунды в реальном времени протестировать, как написанные им пользовательские масштабировщики (Custom Scalers) изменяют плотность тумана или детализацию моделей (LOD) в игре. 2
Синергия с традиционными подходами к оптимизации
Adaptive Performance — это не чудо-алгоритм; он не сможет в одиночку спасти игру с изначально некорректно выстроенной архитектурой. В сочетании с классическими практиками мобильной оптимизации система создает колоссальный мультипликативный эффект. 1
● Текстуры игры (textures) должны проектироваться с размерами, краткими степени двойки (POT - Power of Two), и использовать форматы сжатия мобильного железа, такие как ASTC и ETC2. 8
● Для моделей и текстур, которые не будут изменяться во время выполнения, нужно отключить параметры Read/Write Enabled во избежание хранения лишних копий в памяти ЦП и ГП. 31 Пропускная способность памяти (memory bandwidth) является одним из главных источников тепла. 1
● Если акселерометр (accelerometer) на мобильном железе не используется игрой активно (например, если это не гоночная игра), снижение частоты опроса акселерометра или его отключение в Player Settings избавляет операционную систему от огромной нагрузки и расширяет тепловой пакет (thermal envelope). 31
● Матрицы отсечения камер (Occlusion Culling) должны быть тщательно запечены (baked), и десятки тысяч полигональных моделей, находящихся вне поля зрения камеры, но за стенами, должны отсекаться на стороне ЦП до отправки графическому процессору (draw call). 3
Когда игра, чье время до перегрева было увеличено до 15 минут всеми этими традиционными мерами, подкрепляется масштабировщиками Adaptive Performance AdaptiveResolution или AdaptiveFramerate (выступающими в роли последней линии обороны), она превращается в идеальный и стабильный мобильный шедевр, где часы игрового процесса проходят с незаметным для игрока падением кадровой частоты с 60 до 45 FPS.
Отсутствие охлаждающих вентиляторов у мобильного оборудования вынуждает разработчиков игр играть в шахматы с тепловыми лимитами кремния. Это техническое путешествие, начинающееся с простой установки провайдера вроде "Adaptive Performance Settings", достигает уровня мастерства в управлении клапанами энергопотребления ОС, чтении производных теплового анализа и манипулировании алгоритмами качества в конвейере рендеринга в режиме реального времени. Когда процесс оптимизации сосредоточен не на достижении пиковой производительности (peak performance), а на обеспечении стабильности кадровой частоты (sustained performance), он не только максимизирует удовлетворенность игроков, но и открывает путь к долгосрочному успеху на мобильных платформах.
*Примечание: Изображения были сгенерированы с помощью Google Gemini.