Технические ограничения

Веб-технологии налагают ограничения на веб-приложения Unity, предназначенные для запуска в веб-браузерах. Убедитесь, что вы знаете о следующих технических ограничениях, прежде чем создавать приложение для веб-платформы.

Поддержка платформы

Большинство популярных версий браузеров для настольных компьютеров поддерживают веб-контент Unity, но обратите внимание, что разные браузеры предлагают разные уровни поддержки.

Следующие функции в веб-сборках либо недоступны, либо ограничены из-за ограничений самой платформы:

Отсутствие поддержки отладки веб-сборки в Visual Studio

Отладка веб-построек не поддерживается в Visual Studio. Дополнительные сведения см. в разделе Отладка и устранение неполадок веб-построек.

Отсутствие поддержки Unity кэша и кэш-скриптов

Веб-сборки не поддерживают Unity Кэш и Кэширование API скриптов из-за ограниченного доступа к файловой системе в браузерах. Сетевые запросы на данные ассетов и AssetBundles вместо этого кэшируются в кэше браузера. См. Поведение кэша в Web.

Отсутствие отображения раскладки клавиатуры Input System

Веб-платформа не поддерживает физические-активные клавиатуры отображения, функция Unity Input SystemЭто ограничение означает, что некоторые InputControl свойства которые опираются на преобразование физических кодов клавиш в раскладку виртуальной клавиатуры, работают не так, как ожидается, с неанглоязычными клавиатурами.

Отсутствие поддержки управляемых потоков

Управление (C#) потоки не поддерживаются из-за отсутствия многопоточной функции сбора мусора в WebAssembly. Вы можете включить частичную поддержку потоков в форме нативного C/C++.C++ потоки с экспериментальным Игрок установка Коренное население C/C++ МногопоточностьСм. Поддержка многопоточности.

Из-за этого ограничения, все в C# System.Threading пространство имен не поддерживается. Например, System.Threading.Timer классе не срабатывает в веб-сборках. Кроме того, любые тайм-ауты, заданные в System.Threading.CancellationTokenSource на самом деле не тайм-аут, потому что механизм отмены основан на System.Threading.Timer.

Следующий код подчеркивает эти различия в поведении:

using System.Threading;
using UnityEngine;

public class NoMultithreadedTimers : MonoBehaviour
{
    private Timer t;
    private static void TimerCallbackElapsed(object obj)
    {
        Debug.Log("Timer Callback Fired!"); // This will never fire in Web builds because multithreaded timers aren't available.
    }
    private void Awake()
    {
        t = new Timer(new TimerCallback(TimerCallbackElapsed), this, 1, -1);
    }
}

public class NoCancellationTokenSourceTimeouts : MonoBehaviour
{
    private CancellationTokenSource cs;
    private void Awake()
    {
        cs = new CancellationTokenSource(0); // millisecondsDelay=0 to time out immediately
    }
    private void Update()
    {
        Debug.Log(cs.IsCancellationRequested.ToString()); // Will return false in Web builds since timeouts aren't tracked for cancellation tokens.
    }
} 

Ограничения сетевого взаимодействия

Есть несколько сетевых функций, которые не поддерживаются веб-платформой:

• Браузеры не разрешают прямой доступ к IP сокетам для сетевого взаимодействия из-за проблем безопасности. Для получения дополнительной информации см. Веб-сетевое взаимодействие.

• Сетевые классы .NET в пространстве имен System.Net не поддерживаются.

• Веб-платформа не поддерживает доступ к собственным сокетам из-за ограничений безопасности в браузерах. Поэтому веб-платформа также не поддерживает такие функции, как ICMP ping или UnityEngine.Ping.

Графические ограничения

Существуют некоторые ограничения в Web-платформе с WebGL графикой API, которая основана на функциональности OpenGL ES графической библиотеки. Для получения дополнительной информации, см. Web-графика.

Аудио ограничения

Веб-сборки используют собственный аудиобэкенд на основе API Web Audio, но он поддерживает только базовые аудиовозможности. Дополнительные сведения см. в разделе Аудио в Web.

Ограничения физики

Физико-математическое моделирование в Интернете не гарантирует получения точно таких же результатов, как в Unity Editor или на других платформах. Это происходит потому, что WebAssembly всегда выполняет вычисления с плавающей запятой с полной точностью, в то время как другие Unity платформы выполняют физико-математическое моделирование с включенной настройкой (FTZ/DAZ), которая сглаживает крайне малые, близкие к нулю числа (денормальности) до нуля. Стандарт WebAssembly не предоставляет доступа к аппаратным флагам управления плавающей запятой, необходимым для этого.

Поскольку каждый шаг в физическом моделировании строится на результате предыдущего, небольшие отклонения могут накапливаться со временем и приводить к заметным изменениям в поведении, например, в обнаружении столкновений.

Динамическое генерирование кода

Веб — это платформа AOT, поэтому она не позволяет динамическое генерирование кода с помощью System.Reflection.Emit. То же самое происходит на всех других платформах IL2CPP, iOS и большинстве консолей.

Поддержка многопоточности

Несмотря на то, что Unity обеспечивает поддержку многопоточности для нативного кода C/C++, веб-платформа пока не поддерживает многопоточность C# из-за ограничений WebAssembly. Это означает, что приложения, созданные с помощью веб-платформы, должны работать на одном потоке C#.

Примечания::

• Веб-платформа поддерживает многопоточность C/C++ только в том случае, если вы включили Поддержка нативного C/C++ в настройках Веб-плеера.

• Веб-платформа поддерживает многопоточность, когда документ находится в безопасном контексте.

  Следующие заголовки ответов HTTP должны быть установлены сервером.

  • Политика кросс-открытия происхождения: same-origin
  • Cross-Origin-Embedder-Policy: требование-корпорации
  • Политика в отношении ресурсов, имеющих разное происхождение:

Рекомендуемый способ выполнения сложных асинхронных задач на веб-платформе — это использование Awaitable, которые могут заменить System.Threading.Tasks.Task в большинстве случаев. Для подробностей см. Введение в асинхронное программирование с Awaitable.

Вы также можете использовать сопутствующие процедуры и для асинхронных рабочих процессов. Но обратите внимание, что Awaitable может возвращать значения напрямую и автоматически вызывать ошибки, в то время как сопутствующие процедуры требуют дополнительной логики для обеих задач.

Следующие факторы ограничивают поддержку многопоточности:

Ограничения на основное сканирование стеков

Веб-платформа использует WebAssembly, который является форматом байт-кода для безопасного и эффективного выполнения Unity кода в веб-браузерах. Веб-браузеры разработаны для запуска кода в безопасной и изолированной среде, которая блокирует прямой доступ к собственному стеку WebAssembly. Это влияет на многопоточное сбор мусора, поскольку Web garbage collector запускается только один раз в конце каждого кадра, в отличие от постепенного запуска по нескольким кадрам на других платформах.

Нет поддержки упреждающей сигнализации потоков

Background Workers в вебе выполняют код параллельно независимо друг от друга. На нативных платформах главный поток может синхронно отправлять сигналы другим потокам о приостановке для сбора мусора. Эта синхронная сигнализация не поддерживается в вебе, что препятствует запуску WebAssembly скомпилированного C# кода в нескольких потоках.

Ограничения построения и запуска

Unity использует веб-сервер только с базовой функциональностью для размещения веб-построек, созданных с помощью Создание и запуск (меню: Изменить > Создание профилей > Создание и запуск).

Сервер не поддерживает кэширование данных, что влияет на:

• Файл .data, который включает все сцены и ассеты сборки, которые не используют AssetBundles или Addressables.
• Файлы Addressables и AssetBundle.

Дополнительные ресурсы

• Безопасный контекст
• Уборка мусора