Unity использует платформу .NET с открытым исходным кодом, чтобы приложения, создаваемые с помощью Unity, могли работать на самых разных аппаратных конфигурациях. .NET поддерживает ряд языков и библиотек API.
Скриптовые серверные части
В Unity есть две системы сценариевплатформа, обеспечивающая работу сценариев в Unity. Unity поддерживает три различных бэкэнда для сценариев в зависимости от целевой платформы: Mono, .NET и IL2CPP. Однако универсальная платформа Windows поддерживает только два: .NET и IL2CPP. Дополнительная информация
См. в Словарь, Mono и IL2CPPРазработанный Unity сервер сценариев, который можно использовать в качестве альтернативы Mono при создании проектов для некоторых платформ. Подробнее
См. в Словарь (от промежуточного языка до C++), каждый из которых использует разные техника компиляции:
- Mono использует JIT-компиляцию и компилирует код по запросу во время выполнения.
- IL2CPP использует предварительную компиляцию (AOT) и компилирует все приложение перед его запуском.
Преимущество использования серверной части сценариев на основе JIT заключается в том, что время компиляции обычно намного меньше, чем у AOT, и оно не зависит от платформы.
Редактор Unity основан на JIT и использует Mono в качестве серверной части сценариев. Когда вы создаете проигрыватель для своего приложения, вы можете выбрать, какой сервер сценариев использовать. Чтобы сделать это в редакторе, перейдите в раздел Редактировать > Настройки проекта > Плеер, откройте панель Другие настройки, а затем щелкните раскрывающийся список Сценарная база. и выберите нужную серверную часть.
Управляемое удаление кода
При создании приложения Unity сканирует скомпилированные сборки (DLL) для обнаружения и удаления неиспользуемого кода. Этот процесс уменьшает окончательный двоичный размер вашей сборки, но увеличивает время сборки.
Разделение кода отключено по умолчанию при использовании Mono, но удаление кода нельзя отключить для IL2CPP. Вы можете управлять агрессивностью Unity при удалении кода. Перейдите в раздел Правка > Настройки проекта > Плеер, откройте панель Другие настройки, затем щелкните раскрывающийся список Управляемый уровень очистки и выберите уровень очистки кода. вы хотите. Дополнительные сведения об удалении кода см. в документации по управляемому удалению кода.
Примечание. Удаление кода может быть слишком агрессивным в некоторых случаях и может привести к удалению кода, на который вы полагаетесь, особенно при использовании отражения. Вы можете использовать атрибуты Preserve и файлы link.xml, чтобы предотвратить удаление определенных типов и функций.
Сборка мусора
Unity использует сборщик мусора Boehm как для серверных частей Mono, так и для IL2CPP. Unity по умолчанию использует режим Incremental. Вы можете отключить режим Incremental, чтобы использовать сборку мусора «остановить мир», хотя Unity рекомендует использовать режим Incremental.
Чтобы переключиться между добавочным режимом и режимом «остановить мир», выберите Правка > Настройки проекта > Плеер, откройте панель Другие настройки и нажмите кнопку Использовать инкрементный сборщик мусора. В инкрементальном режиме сборщик мусора Unity работает только в течение ограниченного периода времени и не обязательно собирает все объекты за один проход. Это распределяет время, необходимое для сбора объектов, на несколько кадров и уменьшает количество заиканий и всплесков ЦП. Дополнительные сведения см. в разделе Общие сведения об автоматическом управлении памятью.
Чтобы проверить количество выделений памяти и возможные всплески ЦП в вашем приложении, используйте Профилировщик Unity. Вы также можете использовать API GarbageCollector, чтобы полностью отключить сборку мусора в проигрывателях. Когда сборщик отключен, следует соблюдать осторожность, чтобы не выделять лишнюю память.
Системные библиотеки .NET
Unity поддерживает множество платформ и может использовать различные серверные части сценариев в зависимости от платформы. Системные библиотеки .NET в некоторых случаях требуют реализации для конкретной платформы для правильной работы. Хотя Unity делает все возможное, чтобы поддерживать как можно большую часть экосистемы .NET, существуют некоторые исключения для частей системных библиотек .NET, которые Unity явно не поддерживает.
Unity не гарантирует ни производительности, ни распределения системных библиотек .NET в разных версиях Unity. Как правило, Unity не устраняет снижения производительности в системных библиотеках .NET.
Unity не поддерживает библиотеку System.Drawing и не гарантирует ее работу на всех платформах.
Бэкенд сценариев JIT позволяет создавать динамический код C#/.NET Intermediate Language (IL) во время выполнения приложения, в то время как серверный модуль сценариев AOT не поддерживает генерацию динамического кода. Это важно учитывать при использовании сторонних библиотек, поскольку у них могут быть разные пути кода для JIT и AOT, или они могут использовать пути кода, основанные на динамически сгенерированном коде. Дополнительные сведения о создании кода во время выполнения см. в ModuleBuilder документация.
Хотя Unity поддерживает несколько профилей API .NET, вам следует использовать уровень совместимости API .NET Standard 2.0 для всех новых проектов по следующим причинам:
- .NET Standard 2.0 представляет собой меньшую поверхность API и, следовательно, имеет меньшую реализацию. Это уменьшит размер окончательного исполняемого файла.
- В .NET Standard 2.0 улучшена межплатформенная поддержка, поэтому ваш код с большей вероятностью будет работать на всех платформах.
- .NET Standard 2.0 поддерживается всеми средами выполнения .NET, поэтому ваш код работает в большем количестве сред VM/сред выполнения (например, .NET Framework, .NET Core, Xamarin, Unity).
- .NET Standard перемещает больше ошибок во время компиляции. Некоторые API в .NET 4.7.1 доступны во время компиляции, но на некоторых платформах их реализации вызывают исключение во время выполнения.
Другие профили могут быть полезны, если, например, вам нужно обеспечить поддержку старого существующего приложения. Если вам нужен другой уровень совместимости API, измените профиль .NET в настройках проигрывателя. Для этого перейдите в раздел Правка > Настройки проекта > Плеер > Другие настройки, затем выберите нужный уровень в раскрывающемся списке Уровень совместимости API.
Использование сторонних библиотек .NET
Вы должны использовать только сторонние библиотеки .NET, которые были тщательно протестированы на широком диапазоне конфигураций и платформ Unity.
Примечание. Характеристики производительности путей кода JIT и AOT в сторонних библиотеках могут существенно различаться. AOT обычно сокращает время запуска и по этой причине подходит для более крупных приложений, но увеличивает размер двоичного файла для размещения скомпилированного кода. AOT также требует больше времени для сборки во время разработки и не может изменить поведение скомпилированного кода для какой-либо одной конкретной платформы. JIT настраивается во время выполнения в зависимости от платформы, на которой он работает, что может повысить производительность за счет потенциально более длительного времени запуска приложения. Таким образом, вы должны профилировать свое приложение как в редакторе, так и на целевой платформе. Для получения дополнительной информации см. Profilerокно Unity, которое поможет вам оптимизировать игру. . Он показывает, сколько времени вы тратите на различные области вашей игры. Например, он может сообщать о проценте времени, затраченном на рендеринг, анимацию или игровую логику. Подробнее
См. в документации Словарь.
Вы должны профилировать использование ваших системных библиотек .NET на всех целевых платформах, поскольку их характеристики производительности могут различаться в зависимости от используемых вами сценариев, версий .NET и профилей.
При просмотре сторонней библиотеки учитывайте следующее:
- Совместимость: сторонние библиотеки могут быть несовместимы с некоторыми платформами Unity и серверными программами сценариев.
- Производительность. Характеристики производительности сторонних библиотек в Unity могут сильно отличаться от других сред выполнения .NET.
- Двоичный размер AOT. Сторонние библиотеки могут значительно увеличить размер двоичного файла AOT из-за количества зависимостей
См. Словарь, который использует библиотека.
Накладные расходы на отражение C#
Mono и IL2CPP внутренне кэшируют все объекты отражения C# (System.Reflection), и по замыслу Unity не выполняет их сборку мусора. Результатом такого поведения является то, что сборщик мусора постоянно сканирует кэшированные объекты отражения C# в течение всего времени существования приложения, что приводит к ненужным и потенциально значительным накладным расходам сборщика мусора.
Чтобы свести к минимуму нагрузку на сборщик мусора, избегайте таких методов, как Assembly.GetTypes и Type.GetMethods() в вашем приложении, что создает множество объектов отражения C# во время выполнения. Вместо этого вы должны сканировать сборки в редакторе на наличие необходимых данных и сериализовать и/или кодировать их для использования во время выполнения.
Особое поведение UnityEngine.Object
UnityEngine.Object — это особый тип объекта C# в Unity, поскольку он связан с родным аналогом объекта C++. Например, когда вы используете Камерукомпонент, который создает изображение определенного точка обзора в вашей сцене. Вывод либо рисуется на экране, либо фиксируется в виде текстуры. Подробнее
В компоненте Словарь Unity не сохраняет состояние объекта в объекта C#, а скорее на его собственном аналоге C++.
В настоящее время Unity не поддерживает использование класса C# WeakReference с UnityEngine.Objects. По этой причине не следует использовать WeakReference для ссылки на загруженный ресурс. Дополнительную информацию см. в документации Microsoft по WeakReference. в классе WeakReference.
Unity C# и Unity C++ совместно используют объекты UnityEngine
При использовании такого метода, как Object.Destroy или Object. DestroyImmediate, чтобы уничтожить производный объект UnityEngine.Object, Unity уничтожает (выгружает) собственный объект-счетчик. Вы не можете уничтожить объект C# с помощью явного вызова, потому что сборщик мусора управляет памятью. Как только больше нет ссылок на управляемый объект, сборщик мусора собирает и уничтожает его.
При повторном доступе к уничтоженному объекту UnityEngine.Object Unity воссоздает собственный аналог объекта для большинства типов. Двумя исключениями из этого режима воссоздания являются MonoBehaviour и ScriptableObject: Unity никогда не перезагружает их после их уничтожения.
MonoBehaviour и ScriptableObject переопределяют операторы равенства (==) и неравенства (!=). Таким образом, если вы сравните уничтоженный MonoBehaviour или ScriptableObject с нулевым значением, операторы вернут true, если управляемый объект все еще существует и еще не был удален сборщиком мусора.
Поскольку операторы ?? и ?. не перегружаются, они несовместимы с объектами, производными от UnityEngine.Object. Операторы не возвращают те же результаты, что и операторы равенства и неравенства, когда вы используете их для уничтоженного MonoBehaviour или ScriptableObject, когда управляемый объект все еще существует.
Избегайте использования async и await
Unity API не является потокобезопасным, поэтому не следует использовать асинхронные и ожидающие задачи. Асинхронные задачи часто выделяют объекты при вызове, что может вызвать проблемы с производительностью, если вы их используете слишком часто. Кроме того, Unity не останавливает автоматически асинхронные задачи, выполняемые в управляемых потоках, при выходе из режима воспроизведения.
Unity перезаписывает SynchronizationContext с пользовательским UnitySynchronizationContext и запускает все задачи в основном потоке в режимах Edit и Play. Чтобы использовать асинхронные задачи, вы должны вручную создавать и обрабатывать собственные потоки с помощью TaskFactory, а также использовать SynchronizationContext по умолчанию вместо версии Unity. Чтобы прослушивать события входа и выхода из режима воспроизведения для остановки задач вручную, используйте EditorApplication.playModeStateChanged. Однако при таком подходе большинство API сценариев Unity будут недоступны для использования, поскольку вы не используете UnitySynchronizationContext.
