Материалы по пакетному

разделению VR контента
в Unity
Архитектура платформы
В нашей платформе заложено 2 сценария загрузки контента на устройство, а также
запуск этих 2-х видов контента в специализированном приложении (Лаунчере) на VR
устройстве (устройство типа Oculus 2). За счёт этого подхода, появляется
возможность агрегации на VR платформе, как ранее созданного (сторонними
разработчиками) VR контента, так и создание нового VR контента с использованием
Web технологий доставки и воспроизведения.

Виды VR контента:

1. WebGL (A-frame контент и/или WebXR контент) запуск в браузере (внутри

Лаунчера будет вызываться модальное окно с браузером на весь экран, в
котором уже будет проигран WebGL контент). Браузер - проигрыватель.
2. Пакеты запакованные средствами Unity, которые при необходимости в фоне
загружаются на устройство из интернета Лаунчером, распаковывается и
запускаются специальным проигрывателем пакетного контента (который
придется написать, ну или найти исходники подобного). Тут контент собран и
упакован Unity, а проигрыватель тоже Unity проигрыватель для Android.
(материалы по теме: Загрузка ресурсов в реальном времени; AssetBundles;
Уменьшение размера файла сборки; Сериализация JSON; Streaming Assets)

Таким образом на платформе могут быть опубликованы: и ранее созданные в Unity VR

проекты, и новые созданные в A-frame обучающие материалы в формате VR.

Лаунчер
С технической точки зрения Лаунчер представляет из себя APK приложение,
опубликованное в Oculus Store, и устанавливаемое на VR устройство.

После установки приложение позволяет пользователю:

● авторизоваться на VR платформе,
● получить доступ к уже загруженному и установленному на устройство контенту,
● получить доступ к каталогу контента (Маркетплейсу) платформы,
● получить новый контент:
○ скачать пакет (архив) с серверов платформы,
○ распаковать скачанный пакет (архив),
○ установить (прописать необходимые данные) пакет, чтобы контент
пакета стал виден в Лаунчере, среди доступного на устройстве контента,
 ○ удалить загруженный и установленный на устройство пакет (архив)
после его установки,
● запускать (проиграть) уже загруженный и установленный на устройство контент,
● удалять установленный на устройство контент,
● запускать (проиграть) WebGL контент (через встроенный в Лаунчер браузер)

Обмене данными между Лаунчером и Back-End платформы происходить по API в виде

JSON и пакетов (архивов) контента. Данные и прочая информация поступают в
Лаунчер, распарсиваются в нем (если это JSON) и отображается в интерфейсе
Лаунчера. Также в Лаунчере необходимо реализовать систему прослушивания
событий системы, и вызова в Лаунчере необходимых функций, при передачи этих
событий в него (прослушивание и распознавание префиксов ссылок и запуск или
внутреннего браузера в полноэкранном режиме или процедур скачивания, распаковки
и установки пакета)

Back-End
С технической точки зрения Back-End платформы представляет из себя сервис -
обмениваются по API информацией в виде JSON, HTML и пакетов (архивов) контента.

Многопользовательский VR контент
Для создания многопользовательского VR контента, в проекте необходимо
предусмотреть специальное меню, вызываемое на первом экране, после запуска VR
контента. В этом меню должно быть 2 сценария взаимодействия в
многопользовательском варианте VR контента:

1. Создание (старт) многопользовательского сервера. В рамках этого сценария,

пользователь:
1.1. Авторизуется в системе
1.2. Заходить в каталог доступного ему (на VR устройстве) VR контента.
1.2.1. Если VR контент доступен, но не установлен на VR устройство,
получает необходимый VR контент.
1.3. Запускает необходимый VR контент
1.4. На первом экране VR контента вызывает меню многопользовательского
взаимодействия
1.5. Запускает сервер (сервер внутри нужного VR контента)
1.6. Получает код безопасности (это 4-х значный цифровой код, являющийся
идентификатором сервера (сервера внутри нужного VR контента)
1.7. Передает код безопасности остальным пользователям, которые булут
участвовать
2. Присоединение к запущенному многопользовательскому серверу. В рамках
этого сценария, пользователь:
2.1. Авторизуется в системе
2.2. Заходить в каталог доступного ему (на VR устройстве) VR контента.
2.2.1. Если VR контент доступен, но не установлен на VR устройство,
получает необходимый VR контент.
2.3. Запускает необходимый VR контент
2.4. На первом экране VR контента вызывает меню многопользовательского
взаимодействия
2.5. Присоединяется в серверу (серверу внутри нужного VR контента)
 2.6. Вводит код безопасности (это 4-х значный цифровой код, являющийся
идентификатором сервера (сервера внутри нужного VR контента)

Также в рамках 2-х сценариев взаимодействия в многопользовательском варианте VR

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

1. Авторизоваться,
2. Зайти в специальный раздела в личном кабинете пользователя,
3. Заранее составить список пользователей которые должны присоединиться,
4. Выбрать многопользовательский VR контент,
5. Запустить его.

Пользователь который присоединяется к взаимодействию в многопользовательском

варианте VR контента должен:

1. Авторизоваться,
2. Зайти в специальный раздела в личном кабинете пользователя, в котором ему
будут видны все приглашения в многопользовательские сервера и их статус
(сеанс начат, сеанс завершен),
3. Выбрать активное приглашение и перейти в него.
Загрузка ресурсов в реальном
времени
В некоторых случаях полезно создать ассет, доступный для проекта без его загрузки в качестве
части сцены. Например, там может быть персонаж или другой объект, который может появиться в
любом месте игры, но который будет использоваться лишь изредка (это может быть “секретная”
функция, сообщение об ошибке или предупреждение о рекордном счете). Кроме того, вы даже
можете загрузить ресурс из отдельного файла или через URL, чтобы сократить время начального
скачивания или добавить в проект взаимозаменяемый контент.

Unity поддерживает папки ресурсов в проекте (папки с названием Resources), чтобы разработчик
мог добавить в сборку контент, который не будет загружен до того как понадобится. В Unity Pro,
Unity iOS Advanced и Unity Android Advanced вы также можете создавать ассет бандлы. Это
файлы, полностью отделённые от главной игры, которые содержат ассеты, к которым игра может
получить доступ при необходимости, из файла или по URL.

Asset Bundles
Ассет бандл (Asset Bundle) - это внешняя коллекция ассетов. Вы можете иметь множество ассет
бандлов и следовательно множество внешних коллекций ассетов. Эти файлы существуют вне
проигрывателя, созданного Unity, обычно размещаются на вэб-сервере для динамического доступа.

Чтобы собрать ассет бандл, вы вызываете BuildPipeline.BuildAssetBundle() из Editor скрипта. В

аргументах вы указываете массив объектов для включения в бандл, и некоторые другие опции.
Этот метод соберёт файл, который вы потом сможете динамически загружать в реальном времени с
помощью AssetBundle.Load().

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

Чтобы что-либо положить в папку ресурсов, достаточно просто создать в окне Project (Project
View) новую папку с именем “Resources”. У вас может быть несколько папок ресурсов, размещённых
в разных подпапках проекта. Когда вы пожелаете загрузить ассет из любой такой папки, вызовите
метод Resources.Load().

Если вы собираете под Streaming Web Player (Web Player с функцией поточной загрузки), вы
можете указать в какой сцене будет всё из ваших папок ресурсов. Сделать это можно в настройках
проигрывателя (Player Settings), доступных через меню Edit->Project Settings->Player.
Очередь поточной загрузки уровней определяется очередью сцен в окне Build Settings.

Важно:
Все ассеты из папок ресурсов и их зависимости хранятся в файле под названием resources.assets.
Если ассет уже используется в другом уровне, он хранится в файле .sharedAssets для того уровня.
Настройка Edit -> PlayerSettings First Streamed Level определяет уровень, в котором
будет собран файл resources.assets для включения в сборку.

Если уровень до указанного в “First streamed Level” содержит ассет из папок ресурсов, ассет будет
сохранён вместе с другими ассетами того уровня. Если же ассет из папок ресурсов содержит
уровень после указанного в “First streamed Level”, уровень будет ссылаться на ассет из файла
“resources.assets”.

Только ассеты из папки Resources могут быть загружены с помощью Resources.Load. Однако,
многие другие ассеты могут оказаться в файле “resources.assets”, если они являются зависимостями
ассетов из папок ресурсов (например, материал в папке Resources может ссылаться на текстуру вне
этой папки).
Выгрузка ресурсов
Вы можете выгружать ресурсы ассет бандла вызывая AssetBundle.Unload(). Если вы передадите
true в качестве аргумента unloadAllLoadedObjects, то и ассеты, хранящиеся в AssetBundle и
ассеты, загруженные из AssetBundle с помощью AssetBundle.Load() будут уничтожены и будет
освобождена память, которую они занимали.

Иногда предпочтительнее загрузить AssetBundle, создать экземпляры интересующих вас объектов и

освободить память, занимаемую уже ненужным вам ассет бандлом, при этом сохранив загруженные
объекты. Это полезно для освобождения памяти для других задач, например, для загрузки другого
AssetBundle. В таком случае, вам следует передать false в качестве аргумента. После
уничтожения бандла вы более не сможете загружать из него объекты.

Если вы желаете уничтожить объекты в сцене, загруженные с помощью Resources.Load() до

загрузки другого уровня, вызовите на них Object.Destroy(). Чтобы выгрузить ассеты, используйте
Resources.UnloadUnusedAssets().

AssetBundles
AssetBundles - это файлы, которые можно экспортировать из Unity, для упаковки ресурсов (assets) в
1 файл, по вашему выбору. Эти файлы используют собственный формат сжатия, и могут быть
загружены вашим приложением по необходимости. Это позволяет подгружать различный контент,
такой как модели, текстуры, аудио клипы, или даже целые сцены, отдельно от тех, в которых они
будут использоваться. AssetBundles созданы для упрощения скачивания контента в ваше
приложение.

AssetBundles были разработаны для упрощения загрузки контента в приложение. AssetBundles

могут содержать любой вид ресурсов, поддерживаемых Unity, и определяемых по расширению
файла. Если вы хотите подключить файлы с пользовательскими двоичными данными, они должны
иметь расширение “.bytes”. Unity импортирует эти файлы как TextAssets.

При работе с AssetBundles, вот типичный рабочий процесс:

В процессе разработки, разработчик готовит AssetBundles, и передает их на сервер.

1. Сборка AssetBundles. Asset bundles созданы в редакторе из ресурсов вашей

сцены. Процесс сборки Asset Bundle описан более подробно в разделе Сборка
AssetBundles
2. Загрузка AssetBundles на внешнее хранилище. Этот этап не включает в себя
Unity Editor или любые другие продукты Unity, но мы включили его для
полноценности. Вы можете использовать FTP client, чтобы загружать ваши Asset
Bundles на сервер по вашему выбору

Во время работы, на компьютере пользователя, приложение загрузит AssetBundles по требованию

и позволит управлять отдельными ассетами в рамках каждого AssetBundle по мере необходимости.
 1. Загрузка AssetBundles во время выполнения вашего приложения. Это
выполняется из скрипта в сцене Unity, и Asset Bundles загружаются с сервера по
требованию. Подробнее об этом в Загрузка Asset Bundles.
2. Загрузка объектов из AssetBundles. Как только AssetBundle загружен, вы можете
получить доступ к отдельным ассетам внутри бандла. Подробнее об этом в
Загрузка ресурсов из AssetBundles

Пожалуйста, прочтите этот раздел документации для тщательного ознакомления с рабочим

процессом использования AssetBundles. Откройте для себя различные возможности, и изучите
рекомендации, которые позволят вам сэкономить время и усилия во время разработки.

Уменьшение размера файла сборки

Зачастую важно сохранять размер собранного приложения на минимальном уровне, особенно если
речь о разработке под мобильные устройства, или для магазинов приложений, имеющих
ограничения по размеру. Первый шаг в процессе уменьшения размера - определить, какие ассеты
больше всего занимают места, т.к. такие ассеты - первые кандидаты для оптимизации. Вы можете
найти эту информацию в логе редактора, сразу после совершения сборки (выберите Open Editor
Log в выпадающем меню маленькой иконки в правом верхнем углу окна Console).
Лог редактора сразу после сборки

Лог предоставляет сводку по ассетам, разбитым по типам и затем список отдельных ассетов,
отсортированных по размеру. Как правило, текстуры, музыка и видео занимают больше всего места,
в то время как скриптами, уровнями и шейдерами часто можно пренебречь. Учтите, что File Headers
(заголовки файлов) в сводке - это не ассеты как таковые. Заголовки обычно добавляются к “сырым”
файлам ассетов для сохранения настроек и ссылок. Обычно заголовки не значительно влияют на
размер файлов ассетов, но значение может оказаться и большим, если у вас много больших
ассетов в папке Resources.

Лог помогает выявить ассеты, которые вы, возможно, пожелаете удалить или оптимизировать, но
вам стоит учитывать следующее перед тем как начать работу:

Unity перекодирует импортированные ассеты в собственные внутренние форматы,

поэтому выбор исходного формата ассета не имеет значения. Например, если у
вас в проекте есть Photoshop текстура с множеством слоёв, они будут объединены,
а сама текстура будет сжата перед сборкой проекта. Экспорт текстуры в виде PNG
никак не повлияет на размер сборки, так что вам следует придерживаться
форматов, наиболее удобных для вас при разработке.
Unity отсеивает большинство неиспользуемых ассетов во время сборки, так что вы
ничего не выиграете, вручную удаляя ассеты из проекта. Ассеты, которые не
подвергаются отсеиванию - скрипты (они в любом случае занимают очень мало
места) и всё, что находится в папке Resources (т.к. Unity не может определить какие
из них будут использоваться, а какие - нет). Помня об этом, вам следует убедиться,
что в папке Resources находятся только те ассеты, которые действительно нужны
во время игры. Кроме того, вместо хранения ассетов в папке Resources, вы можете
выбрать AssetBundles для их динамической загрузки, чтобы ещё больше снизить
размер сборки.
Советы по уменьшению размера сборки
Текстуры
Зачастую, больше всего места в сборке занимают текстуры. Первое, что следует сделать -
использовать сжатые форматы текстур (DXT (для настольных платформ) или PVRTC) там, где это
возможно.

Если это не приведёт к уменьшению размера, попробуйте снизить качество текстур. Хитрость тут в
том, что вам не нужно менять исходный контент. Просто выберите текстуру в окне Project и
измените значение свойства Max Size (максимальный размер) в настройках импорта. Можно
приблизить объект, на котором используется выбранная текстура, и подобрать значение Max Size
так, чтобы вы не замечали ухудшения качества текстуры в окне Scene (Scene View).

Изменение максимального размера текстуры

повлияет лишь на разрешение текстуры в игре, и не изменит ваш ассет текстуры

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

Сжатие Потребление памяти (байты/пиксель)

Standalone & WebGL

RGB Crunched DXT1 variable

RGBA Crunched DXT5 variable

RGB Compressed DXT1 0.5 bpp

RGBA Compressed DXT5 1 bpp

RGB 16bit 2 bpp

RGB 24bit 3 bpp

Alpha 8bit 1 bpp

RGBA 16bit 2 bpp

RGBA 32bit 4 bpp

iOS

RGB Compressed PVRTC 2 bits 0.25 bpp (байты/пиксель)

RGBA Compressed PVRTC 2 bits 0.25 bpp

RGB Compressed PVRTC 4 bits 0.5 bpp

RGBA Compressed PVRTC 4 bits 0.5 bpp

RGB 16bit 2 bpp

RGB 24bit 3 bpp

Alpha 8bit 1 bpp

RGBA 16bit 2 bpp

RGBA 32bit 4 bpp

 Android

RGB Compressed DXT1 0.5 bpp (байты/пиксель)

RGBA Compressed DXT5 1 bpp

RGB Compressed ETC1 0.5 bpp

RGB Compressed PVRTC 2 bits 0.25 bpp (байты/пиксель)

RGBA Compressed PVRTC 2 bits 0.25 bpp

RGB Compressed PVRTC 4 bits 0.5 bpp

RGBA Compressed PVRTC 4 bits 0.5 bpp

RGB 16bit 2 bpp

RGB 24bit 3 bpp

Alpha 8bit 1 bpp

RGBA 16bit 2 bpp

RGBA 32bit 4 bpp

Формула занимаемого на диске места такова: ширина * высота * bpp. Если вы используете
мипмапы, тогда размер на диске будет примерно на треть больше, чем при обычном единичном
изображении.

По умолчанию, Unity сжимает все текстуры при импорте. Для ускорения рабочего процесса в
редакторе, вы можете отключить сжатие в настройках редактора (флажок Compress Assets on
Import), но при этом текстуры всё равно будут сжиматься при сборке, независимо от этой настройки.

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

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

Учтите, что сжатие меша снижает только физических размер файлов, но не объём используемой
памяти при выполнении программы. А вот снижение количества ключевых кадров в анимации
(значение Keyframe reduction у свойства Anim. Compression в настройках импорта) уменьшает и
физический размер файлов, и потребление памяти во время выполнения программы, потому
рекомендуется всегда оставлять эту настройку включенной.

DLL файлы
По умолчанию, Unity включает в сборку только эти DLL файлы:

mscorlib.dll
Boo.Lang.dll
UnityScript.Lang.dll
UnityEngine.dll

При работе над игрой рекомендуется избегать использования зависимостей из System.dll или
System.Xml.dll. По умолчанию, Unity не включает эти библиотеки в к сборку проигрывателя, но если
в своём коде вы используете их классы, библиотеки будут включены в сборку. Эти DLL файлы
добавят к размеру сборки проигрывателя около одного мегабайта. Если в вашей игре требуется
работа с XML, вы можете использовать библиотеки вида Mono.Xml.zip в качестве небольшой по
размерам альтернативы системным библиотекам. Хоть большинство дженерик контейнеров
содержится в mscorlib, но Stack<> и некоторые другие находятся в System.dll, так что постарайтесь
избегать их использования по возможности.

Сериализация JSON
Функция сериализации JSON преобразует объекты в формат JSON и из него. Это может быть
полезно при взаимодействии с веб-службами, или просто для упаковки и распаковки данных в
текстовом формате легко.

Для получения информации о классе JsonUtility, пожалуйста, посетите страницу Unity ScriptRef
JsonUtility.

Простое использование
Функция сериализации JSON построена на понятии «структурированный» JSON, что означает, что
вы описываете, какие переменные будут храниться в данных JSON, создавая класс или структуру.
Например:

[Serializable]

public class MyClass

public int level;

public float timeElapsed;

public string playerName;

Это определяет простой класс C, содержащий три переменные - уровень, timeElapsed, и

playerName - и отмечает его как Serializable, который необходим для его работы с сериализатором
JSON. Затем можно создать такой экземпляр:

MyClass myObject = new MyClass();

myObject.level = 1;
myObject.timeElapsed = 47.5f;

myObject.playerName = "Dr Charles Francis";

И сериализовать его в формате JSON с помощью:JsonUtility.ToJson

string json = JsonUtility.ToJson(myObject);

Это приведет к переменной, содержащей строку:json

{"level":1,"timeElapsed":47.5,"playerName":"Dr Charles Francis"}

Чтобы преобразовать JSON обратно в объект, используйте:JsonUtility.FromJson

myObject = JsonUtility.FromJson<MyClass>(json);

Это создаст новый экземпляр и установит значения на нем с использованием данных JSON. Если
данные JSON содержат значения, которые не картированы на поля, то эти значения будут просто
проигнорированы, и если в данных JSON отсутствуют значения для полей, то эти поля будут
оставлены на построенных значениях в возвращенном объекте.MyClassMyClassMyClass

В настоящее время JSON Serializer не поддерживает работу с «неструктурированным» JSON (т.е.

навигацией и редактированием JSON как произвольного дерева пар ключевых значений). Если вам
нужно сделать это, вы должны искать более полное функциональные библиотеки JSON.

Перезапись объектов с помощью JSON

Кроме того, можно взять данные JSON и deserialize его "над" уже созданный объект, перезаписывая
данные, которые уже присутствуют:

JsonUtility.FromJsonOverwrite(json, myObject);

Любые поля на объекте, для которых JSON не содержит значения, останутся неизменными. Этот
метод позволяет с минимальными затратами, повторно использовать созданные ранее объекты, а
также «патч» объектов, намеренно перезаписывая их с JSON, который содержит только небольшой
подмножество полей.

Обратите внимание, что API JSON Serializer поддерживает и подклассы, а также простые
структуры/классы. Однако при deserializing JSON в подклассы или, вы должны использовать
FromJsonOverwrite; FromJson не поддерживается и будет бросать
исключение.MonoBehaviourScriptableObjectMonoBehaviourScriptableObject

Поддерживаемые типы
API поддерживает любой подкласс, подкласс или простой класс/структуру с атрибутом. Объект,
который вы проходите, подается в стандартный сериализатор Unity для обработки, поэтому
применяются те же правила и ограничения, что и в Инспекторе; только поля сериализируются, а
типы, как не поддерживаются.MonoBehaviourScriptableObject[Serializable]Dictionary&lt;&gt;

Передача других типов непосредственно API, например примитивных типов или массивов, в
настоящее время не поддерживается. На данный момент вам нужно будет обернуть такие типы в
или какой-то.classstruct

Только в редакторе есть параллельный API, который позволяет сериализировать любой тип,
полученный как в JSON, так и из него. Это позволит создать JSON, который содержит те же данные,
что и представление объекта YAML.EditorJsonUtilityUnityEngine.Object

Производительности
Тесты бенчмарка показали, что они значительно быстрее, чем популярные решения .NET JSON
(хотя и с меньшим количеством функций, чем некоторые из них).JsonUtility

Использование памяти GC как минимум:

ToJson() выделяет память GC только для возвращенной строки.

FromJson() выделяет память GC только для возвращенного объекта, а также
любые необходимые подобъекты (например, если вы deserialize объект,
содержащий массив, то память GC будет выделена для массива).
FromJsonOverwrite() выделяет память GC только по мере необходимости для
письменных полей (например, строк и массивов). Если все поля, перезаписаные
JSON, типизы значений, они не должны выделять память GC.

Допускается использование API JsonUtility из фонового потока. Как и в случае с любым

многопоточном кодом, следует быть осторожным, чтобы не получить доступ к объекту или изменить
его на одном потоке во время его сериализации/дезериализации на другом.

Управление выходом ToJson()

ToJson поддерживает довольно-печать выхода JSON. Он выключен по умолчанию, но вы можете
включить его, пройдя в качестве второго параметра.true

Поля могут быть опущены из вывода с помощью атрибута.[NonSerialized]

Использование FromJson (), когда тип не известен

заранее
Дезериализировать JSON в класс или структуру, которая содержит «общие» поля, а затем
использовать значения этих полей, чтобы выяснить, какой фактический тип вы хотите. Затем
deserialize во второй раз в этот тип.

Как вы можете видеть, Unity включает System.Xml.dll и System.dll, при сборке

проигрывателя
Уменьшение размера мобильной .NET библиотеки
Для некоторых мобильных устройств, Unity поддерживает два уровня совместимости .NET API: .NET
2.0 и подмножество .NET 2.0 (.NET 2.0 subset). Вы можете выбрать соответствующий уровень для
вашей сборки в параметрах проигрывателя.

Профиль .NET 2.0 API соответствует полной версии .NET 2.0 API. Большинство подпрограмм
библиотеки полностью реализованы, потому использование этой опции позволяет получить
наилучшую совместимость с уже существующим кодом. Однако, в большинстве игр не требуется
полная версия библиотеки и ненужный код занимает ценное пространство в памяти.

Во избежание излишнего потребления памяти, Unity поддерживает профиль подмножества .NET 2.0
API. Он очень похож на профиль Mono “monotouch”, так что многие из ограничений профиля
“monotouch” также распространяются и на профиль .NET 2.0 Subset редактора Unity (здесь можно
получить дополнительную информацию об ограничениях профиля “monotouch”). Многие редко
используемые в играх процедуры исключены из этого профиля для снижения потребления памяти.
Однако, это также значит, что не будет правильно работать код с зависимостями от этих процедур.
Эта опция может быть полезна для оптимизации, но вам следует проверить, работает ли
существующий код после применения этой опции.

Streaming Assets (Потоковые)

Многие ассеты в Unity комбинируются при сборке в проект. Тем не менее, иногда полезно
размещать файлы на указанном компьютере в нормальной файловой системе, чтобы сделать их
доступными через пути. В качестве примера можно привести развёртку файла фильма на iOS
устройства; оригинальный файл должен находиться в файловой системе, чтобы его можно было
проиграть с помощью функции PlayMovie.

Все файлы, помещённые в папку под названием StreamingAssets в Unity проекте будут скопированы
в определённую папку на указанный компьютер. Вы можете извлечь папку используя свойство
Application.streamingAssetsPath. Для справки, расположение этой папки меняется в зависимости от
платформы:

Расположение этой папки варьируется в зависимости от платформы. Пожалуйста, обратите

внимание, что они чувствительны к случаям:

На настольном компьютере (Mac OS или Windows) местоположение файлов можно

получить со следующим кодом:

path = Application.dataPath + "/StreamingAssets";

path = Application.dataPath + "/Raw";

path = "jar:file://" + Application.dataPath + "!/assets/";

Примечание: .dll файлы, расположенные в папке StreamingAssets, не участвуют в компиляции.

На iOS, вам следует использовать:

Android, на Android, файлы содержатся в сжатом файле .jar (который, по сути, тот
же формат, что и стандартные файлы с сжатой на молнии). Это означает, что если
вы не используете класс WWW Unity для извлечения файла, вам необходимо
использовать дополнительное программное обеспечение, чтобы увидеть внутри
.jar архива и получить файл.