Существует столько же различных способов оптимизации кода, сколько и причин проблем с производительностью. В общем, настоятельно рекомендуется, чтобы разработчики тщательно профилировали свои приложения, прежде чем пытаться применить оптимизацию ЦП. Однако есть несколько простых универсальных оптимизаций ЦП.
Свойства адреса по идентификатору
Unity не использует строковые имена для обращения к Animator, Material и Shaderпрограмме, работающей на графическом процессоре. Подробнее
См. в свойствах Словарь внутри. Для ускорения все имена свойств хэшируются в идентификаторы свойств, и именно эти идентификаторы фактически используются для адресации свойств.
Поэтому всякий раз, когда вы используете метод Set или Get для аниматора, материала или шейдера, используйте метод с целочисленным значением вместо методов со строковым значением. Строковые методы выполняют хеширование строк, а затем передают хешированный идентификатор методам с целочисленным значением.
Идентификаторы свойств, созданные из хэшей строк, являются детерминированными в течение одного запуска. Самый простой способ их использования — объявить статическую целочисленную переменную только для чтения для каждого имени свойства и использовать целочисленную переменную вместо строки. Они автоматически инициализируются во время запуска без необходимости дополнительного кода инициализации.
Соответствующие API: Animator.StringToHash для имен свойств Animator и Shader.PropertyToID для имен свойств материалов и шейдеров.
Использовать физические API без выделения памяти
В Unity 5.3 и более поздних версиях были введены нераспределяющие версии всех API запросов Physics. Замените вызовы RaycastAll на RaycastNonAlloc, SphereCastAll вызывает с SphereCastNonAlloc. Для 2D-приложений также существуют нераспределяющие версии всех API запросов Physics2D.
Нулевые сравнения с подклассами UnityEngine.Object
Mono и IL2CPPразработанный Unity сервер сценариев, который можно использовать в качестве альтернативы Mono при создании проектов. для некоторых платформ. Подробнее
См. в Словарь. Среда выполнения обрабатывает экземпляры классов, производных от UnityEngine.Object определенным образом. Вызов методов для экземпляров фактически вызывает код механизма, который должен выполнять поиск и проверку для преобразования ссылок сценария в собственные ссылки. Сравнение переменной этого типа с нулевым значением требует больше ресурсов, чем сравнение с чисто классом C#. По этой причине избегайте этих сравнений с нулевыми значениями в узких циклах или в коде, который выполняется в каждом кадре.
Векторная и кватернионная математика и порядок операций
Для векторов и кватернионовстандартный способ Unity для представления поворотов в виде данных. При написании кода, имеющего дело с поворотами, обычно следует использовать класс Quaternion и его методы. Подробнее
Посмотрите в Словарь математику, расположенную в узких циклах, помните, что целочисленная математика быстрее чем математика с плавающей запятой, а математика с плавающей запятой быстрее векторной, матричной или кватернионной математики.
Поэтому всякий раз, когда позволяет коммутативная или ассоциативная арифметика, старайтесь минимизировать ресурсоемкость отдельных математических операций:
Vector3 x;
int a, b;
// Less efficient: results in two vector multiplications
Vector3 slow = a * x * b;
// More efficient: one integer mult, one vector mult
Vector3 fast = a * b * x;
Встроенная ColorUtility
Приложения, которым необходимо преобразовывать цветные строки в формате HTML (#RRGGBBAA), в собственные Color Unity и Color32, чтобы использовать скрипт из сообщества Unify. Этот сценарий был медленным и приводил к чрезмерному выделению памяти из-за манипуляций со строками.
В Unity 5 имеется встроенный API ColorUtility, который эффективно выполняет эти преобразования. Использование встроенного API должно быть предпочтительным.
Найти и FindObjectOfType
Рекомендуется отказаться от любого использования GameObject.Find и Object.FindObjectOfType в производственном коде. Поскольку эти API требуют, чтобы Unity перебирал все GameObjectsфундаментальный объект в сценах Unity, который может представлять персонажей, реквизит, декорации, камеры , путевые точки и многое другое. Функциональность GameObject определяется прикрепленными к нему компонентами. Подробнее
Посмотрите в Словарь и Компоненты в памяти, они быстро становятся неэффективными по мере масштаб проекта растет.
Исключение из приведенного выше правила может быть сделано в средствах доступа для одноэлементных объектов. Объект глобального менеджера часто предоставляет свойство «экземпляр» и часто имеет вызов FindObjectOfType в геттере для обнаружения уже существующих экземпляров синглтона:
class SomeSingleton {
private SomeSingleton _instance;
public SomeSingleton Instance {
get {
if(_instance == null) {
_instance =
FindObjectOfType();
}
if(_instance == null) {
_instance = CreateSomeSingleton();
}
return _instance;
}
}
}
Хотя этот шаблон в целом приемлем, важно изучить код и убедиться, что метод доступа вызывается в сценахA Сцена содержит окружение и меню вашей игры. Думайте о каждом уникальном файле сцены как об уникальном уровне. В каждой сцене вы размещаете свое окружение, препятствия и декорации, по сути проектируя и создавая свою игру по частям. Подробнее
Посмотрите в Словарь, где объект-одиночка не существует. Если геттер не создает автоматически экземпляр отсутствующего синглтона, обычно обнаруживается, что код, ищущий синглтон, приводит к повторным вызовам FindObjectOfType (часто несколько раз за кадр). и создает нежелательное снижение производительности.
Код отладки и атрибут [условный]
API ведения журналов UnityEngine.Debug не удаляются из сборок, не предназначенных для разработки, и запись в файлы журнала, если вызывается. Поскольку большинство разработчиков не собираются записывать отладочную информацию в сборках, не предназначенных для разработки, рекомендуется заключать вызовы ведения журнала, предназначенные только для разработки, в пользовательские методы, например так:
public static class Logger {
[Conditional("ENABLE_LOGS")]
public static void Debug(string logMsg) {
UnityEngine.Debug.Log(logMsg);
}
}
Благодаря декорированию этих методов атрибутом [Conditional] определение или определения, используемые атрибутом Conditional, определяют, включен ли декорированный метод в скомпилированный исходный код.
Если ни одно из определений, переданных атрибуту Conditional, не определено, то декорированный метод и все вызовы декорированного метода компилируются. Эффект идентичен тому, что произошло бы, если бы метод и все вызовы метода были заключены в блоки препроцессора #if … #endif.
Дополнительную информацию об атрибуте Conditional см. на веб-сайте MSDN: msdn.microsoft.com.
