Публикация сборок
В любой момент разработки игры можете захотеть посмотреть на то, как она выглядит вне редактора, при сборке в качестве самостоятельного приложения или веб-проигрывателя. В этом разделе рассказано, как вызвать и использовать окно Build Settings (настройки сборки) для создания разных сборок ваших игр.
Пункт меню File->Build Settings… позволяет открыть окно Build Settings. В нём выводится редактируемый список сцен для включения в сборку игры.
Окно Build Settings
Список будет пуст при первом открытии этого окна в проекте. В таком случае, при сборке, в игру будет включена только текущая открытая сцена. Если вы желаете быстро собрать тестовый плеер с единственной текущей сценой, просто соберите плеер с пустым списком сцен.
Следует заметить, что каждая из сцен в списке имеет свой индекс. Scene 0 — это первая сцена, которая будет загружена в сборке. Если вы желаете загрузить другую сцену во время игры, используйте в вашем коде метод Application.LoadLevel().
Если вы добавили более одной сцены и хотите изменить их порядок, просто перетаскивайте сцены в списке до тех пор, пока не добьётесь необходимого вам порядка.
Чтобы удалить сцену из списка, достаточно выбрать её в списке и нажать Command-Delete (на Mac) или Delete (на Win). Сцена пропадёт из списка и не будет включена в сборку.
Включение опции Development Build добавит плееру возможность использовать Profiler и позволит изменять опции Autoconnect Profiler и Script Debugging.
Further information about the Build Settings window can be found on the Build Settings page.
Сборка standalone плееров
Unity может собирать standalone приложения для Windows, Mac и Linux. Достаточно просто выбрать целевую платформу в настройках сборки и нажать кнопку ‘Build’. При сборке standalone проигрывателей, получаемые в результате файлы могут различаться в зависимости от выбранной платформы. На Windows в результате сборки будет создан исполняемый файл (.exe) и папка “Data”, содержащая все ресурсы приложения. На Mac будет создан “app bundle”, содержащий все необходимые файлы для запуска приложения и его ресурсы.
В недрах процесса сборки
Сперва процесс сборки разместит пустую копию игры там, где вы указали. Затем он начнёт прорабатывать список сцен в настройках сборки: открывать в редакторе одну из них за раз, оптимизировать их и интегрировать их в пакет приложения. Он также подсчитает все ассеты, необходимые включенным в сборку сценам и сохранит эти данные в отдельном файле внутри пакета приложения.
Любой GameObject в сцене с тэгом ‘EditorOnly’ не будет включён в собираемый пакет. Это удобно для отладки скриптов, которые не должны оказаться в финальной игре.
Все объекты в текущем уровне уничтожаются при загрузке нового уровня. Чтобы это предотвратить, используйте DontDestroyOnLoad() на любых объектах, которые вы желаете уберечь от уничтожения. Обычно это используют для проигрываемой при загрузке уровня музыки, или для скриптов игровых контроллеров, которых хранят состояние и прогресс игры.
После загрузки уровня будет разослано сообщение OnLevelWasLoaded() всем активным игровым объектам.
Для дополнительной информации о том, как лучше всего создавать игры, в которых насколько сцен (например, главное меню, экран рейтинга и сами уровни игры), ознакомьтесь с нашими уроками.
Опубликованные сборки автоматически осуществляют прелоадинг всех ассетов в сцене при её загрузке. Исключением является сцена 0, так как она, как правило, используется в качестве загрузочного экрана, который нужно отобразить как можно быстрее.
Вы готовы собирать игры
На данный момент вы изучили, как использовать интерфейс Unity, как использовать ассеты, как создавать сцены и как публиковать ваши сборки. Теперь вас ничто не останавливает от создания игры вашей мечты. Мы уверены, что по пути вам ещё предстоит многое узнать, и мы всегда рядом, чтобы помочь вам во всём разобраться.
Для дополнительной информации о том, как создавать игровые уровни, см. раздел Построение сцен.
Для дополнительной информации о написании скриптов для вашей игры, см. раздел Скриптинг.
Для дополнительной информации о создании графических ассетов, см. раздел Импорт и создание ассетов данного руководства.
Для общения с другими пользователями Unity, посетите Unity Forums. Там вы можете задавать вопросы, делиться проектами, строить команду, можете делать там всё, что вы захотите. Обязательно загляните на форумы хотя бы один раз, потому что мы хотим посмотреть на невероятные игры, которые вы создадите.
Development builds
Unity Cloud Build builds your projects for release by default. To create a development build, go to the build target’s Advanced Options. (See documentation on accessing and editing Advanced Options.)
The Edit Advanced Options screen
Check the Development Builds box. When enabled, this sets two flags in the BuildOptions API:
Development : A development build includes debug symbols and enables the Profiler.
AllowDebugging : Allow script debuggers to attach to the player remotely.
Did you find this page useful? Please give it a rating:
Thanks for rating this page!
What kind of problem would you like to report?
Is something described here not working as you expect it to? It might be a Known Issue. Please check with the Issue Tracker at issuetracker.unity3d.com.
Thanks for letting us know! This page has been marked for review based on your feedback.
If you have time, you can provide more information to help us fix the problem faster.
You’ve told us this page needs code samples. If you’d like to help us further, you could provide a code sample, or tell us about what kind of code sample you’d like to see:
You’ve told us there are code samples on this page which don’t work. If you know how to fix it, or have something better we could use instead, please let us know:
You’ve told us there is information missing from this page. Please tell us more about what’s missing:
You’ve told us there is incorrect information on this page. If you know what we should change to make it correct, please tell us:
You’ve told us this page has unclear or confusing information. Please tell us more about what you found unclear or confusing, or let us know how we could make it clearer:
You’ve told us there is a spelling or grammar error on this page. Please tell us what’s wrong:
You’ve told us this page has a problem. Please tell us more about what’s wrong:
Thanks for helping to make the Unity documentation better!
Building apps for Android
There are two locations to configure settings that affect how your app is built:
The output package includes an APK, and an APK expansion file (OBB) if the Split Application Binary option is selected in the Player settings. For more information on OBB files, see OBB Support.
To optimize for download and installation size, enable the Split APKs by target architecture option in the Player settings. The Split APKs by target architecture option produces one set of APKs and OBBs for each device architecture selected in the Target Architecture list in the Player settings. You can upload this set of APKs (and OBBs, if enabled) to the Google Play, or other, store instead of a FAT APK in which all of the selected architectures are included into a single APK. For more information on this feature, see Multiple APK support on the Android Developer website.
Configuring Build Settings
To configure and build apps for Android, access the Build Settings window (File > Build Settings). In Platform, select Android.
To set Android as your default build platform, click the Switch Platform button.
After you specify your build settings, click the Build button to create your build. To build the app, click Build And Run to create and run your build on the platform you have specified.
Texture compression
Unity uses the Ericsson Texture Compression (ETC) format for textures that don’t have individual texture format overrides. When building an APK to target specific hardware, use the Texture Compression option to override this default behavior. Texture Compression is a global setting for the Project. If a texture has a specific override on it, that texture is not affected by the Texture Compression setting. For additional information, see Textures.
For additional information on textures and texture compression, see the Mobile and WebGL specific formats and Notes on Android sections on the Texture compression formats for platform-specific overrides page.
Note: Texture Compression is a global setting. Individual textures override the global setting.
ETC2 fallback
For Android devices that don’t support ETC2 (which don’t support GL ES3), you can override the default ETC2 texture decompression by choosing from 32-bit, 16-bit, or 32-bit with half the resolution formats.
This option allows you to choose between the uncompressed image quality and the amount of memory the uncompressed texture occupies. 32-bit RGBA texture is the highest quality format, and takes twice the required disk space as the 16-bit format, but a texture in 16-bit might lose some valuable color information. 32-bit half-resolution reduces the memory requirement further, but the texture is likely to become blurry.
Build system
Unity supports two Android build systems: Gradle and Internal.
The steps involved with building for Android are:
Preparing and building the Unity Assets.
Processing the plug-ins.
Splitting the resources into the parts that go to the APK and the OBB, if Split Application Binary is selected.
Building the Android resources using the AAPT utility (internal build only.)
Generating the Android manifest.
Merging the library manifests into the Android manifest (internal build only.)
Compiling the Java code into the Dalvik Executable format (DEX) (internal build only.)
Building the IL2CPP library, if IL2CPP Scripting Backend is selected.
Building and optimizing the APK and OBB packages.
Gradle build system
The Gradle build system uses Gradle to build an APK or export a Project in Gradle format, which can then be imported to Android Studio. When you select this build system, Unity goes through the same steps as the Internal build system excluding resource compilation with AAPT, merging manifests, and running DEX. Unity then generates the build.gradle file (along with the other required configuration files) and invokes the Gradle executable, passing it the task name and the working directory. Finally, the APK is built by Gradle.
Internal build system
The Internal build system creates an APK using the Android SDK utilities to build and optimize the APK and OBB packages. For more information about OBB files, see OBB Support.
Exporting the Project
If you need more control over the build pipeline, or to make changes that Unity does not normally allow (for example, fine tuning the manifest files that are automatically generated by Unity), you can export your Project and import it into Android Studio. Exporting a Project is only available when you have selected Gradle as your Build System.
To export the Project:
When the export finishes, open Android Studio and import your project. For more information on importing projects to Android Studio, see the Migrate to Android Studio section of the Android Developer documentation.
Build or Build and Run
The Build Settings window offers two options: Build and Build and Run. Using either option saves the output packages (APK and OBB, if enabled) to the path that you select. You can publish these packages to the Google Play Store, or install them on your device manually with the help of Android Debug Bridge (ADB). For further information about installing apps manually, see the Run your app section of the Android Developer documentation. For information on ADB commands, see the Android Debug Bridge section of the Android Developer documentation.
Selecting Build and Run saves the output packages to the file path you specify, while also installing your app on the Android device connected to your computer.
If the Split Application Binary option is enabled, the OBB file is pushed to the correct location on your device. If Development Build is checked, Unity also sets up a Profiler tunnel and enables CheckJNI. After that, the app is launched. The Split Application Binary setting is located in the Publishing Settings section of the Player settings.
Tip: Specify the output path for the packages and then use the Ctrl+B (Windows) or Cmd+B (macOS) keyboard shortcut to Build and Run using the saved output path.
2018–11–19 Page amended
Updated functionality in 5.5
Updated the Build Settings Configuration options
Building and running a WebGL project
When you build a WebGL project, Unity creates a folder with the following files:
An index.html file which browsers can navigate to load your content.
A TemplateData folder (when building with the default template) containing the build logo, loading bar and other template Assets. The build template folder is normally used to customize the appearance of the build while loading. See the User Manual page on WebGL templates for more information.
A Build folder containing your generated build output files.
The Build folder contains the following files (the MyProject file name represents the name of your project).
A UnityLoader.js JavaScript file containing the code needed to load up the Unity content in the web page.
A MyProject.json JSON file containing all the necessary information about your build. The URL of this JSON file is provided as an argument for the Unity Loader when the build is instantiated. JSON file contains URLs of all the other build files, which can be absolute or relative to the location of the JSON file. JSON may contain additional Module parameters, such as the splash screen style or the initial size of the memory heap.
A MyProject.wasm.framework.unityweb file containing the JavaScript runtime and plugins.
A MyProject.wasm.code.unityweb file containing the WebAssembly binary.
A MyProject.wasm.memory.unityweb file containing a binary image to initialize the heap memory for your player. Note that this file is only generated for multi-threaded builds.
A MyProject.data.unityweb file containing the Asset data and Scenes.
The contents of the *.unityweb files in the Build folder may be compressed with gzip, brotli or may be uncompressed, depending on the Publishing Settings. See documentation on deploying compressed builds for more information
On some servers you need to explicitly make .unityweb files accessible, because the server needs to provide these files to clients.
Build Settings
To access the WebGL build settings, open the Build Settings window (File > Build Settings). Then select WebGL from the Platform list.
Development Build
When you select the Development Build setting, Unity generates a development build which has Profiler support and a development console which you can use to see any errors in your application. Additionally, development builds do not minify content. The JavaScript in development builds are in human-readable form, and Unity preserves function names so you can see stack traces for errors. However, this means development builds are very large, and too large to distribute. You can only select Autoconnect Profiler and Deep Profiling Support if you enable the Development Build setting.
Autoconnect Profiler
Enable the Autoconnect Profiler setting to profile your Unity WebGL content. For WebGL, it is not possible to connect the Profiler to a running build as on other platforms, so you have to use this option to connect the content to the Editor. This is because the Profiler connection is handled using WebSockets on WebGL, but a web browser only allows outgoing connections from the content.
Deep Profiling Support
Enable the Deep Profiling Support setting to make the Unity Profiler profile every function call in your application. For more information see the documentation on Deep Profiling.
Player settings
WebGL has some additional options in the Player settings (menu: Edit > Project Settings, then select the Player category).
Other Settings
Strip Engine Code
Open Other Settings to access the Strip Engine Code option. This option is checked by default to enable code stripping for WebGL. With this option checked, Unity does not include code for any classes you don’t use. For example, if you don’t use any physics components or functions, the whole physics engine is removed from your build. See the Stripping section below for more details.
Publishing Settings
Enable Exceptions
Open Publishing Settings to access Enable Exceptions. Enable Exceptions allows you to specify how unexpected code behavior (generally considered errors) is handled at run time. It has these options:
Select Publishing Settings to access Data Caching. Select this to enable automatic local caching of your player data. This option sets asset storage as a local cached in the browser’s IndexedDB database, so that assets won’t have to be downloaded again in subsequent runs of your content. Note that different browsers have different rules on allowing IndexedDB storage; browsers may ask the user for permission to store the data, and your build may exceed a size limit defined by the browser.
Distribution size
When publishing for WebGL, it is important to keep your build size low so users get reasonable download times before the content starts. For generic tips on reducing asset sizes, see documentation on Reducing the file size of the build.
Hints and tips specific to WebGL
Specify the Crunch texture compression format for all your compressed textures in the Texture Importer.
Don’t deploy development builds; they are not compressed or minified, and so have much larger file sizes.
Open the Player settings (menu: Edit > Project Settings, then select the Player category), open the Publishing Settings panel and set Enable Exceptions to None if you don’t need exceptions in your build.
Open the Player settings (menu: Edit > Project Settings, then select the Player category), open the Other Settings panel, and enable Strip Engine Code to ensure an efficient build.
Take care when using third-party managed dlls, as they might include a lot of dependencies and so significantly increase the generated code size.
If you make a release build, Unity compresses the build output files according to the Compression Format selected in the Publishing Settings panel of the WebGL Player settings.
See documentation on Deploying compressed builds for more info on these options, and on how to publish builds with them.
AssetBundles
Since all your Asset data needs to be pre-downloaded before your content starts, you should consider moving Assets out of your main data files and into AssetBundles. That way, you can create a small loader Scene for your content which loads quickly. It then dynamically loads Assets on-demand as the user proceeds through your content. AssetBundles also help with Asset data memory management: You can unload Asset data from memory for Assets you don’t need any more by calling AssetBundle.Unload.
Some considerations apply when using AssetBundles on the WebGL platform:
When you use class types in your AssetBundle which are not used in your main build, Unity may strip the code for those classes from the build. This can cause a fail when trying to load Assets from the AssetBundle. Use BuildPlayerOptions.assetBundleManifestPath to fix that, or see the section on Stripping, below, for other options.
WebGL does not support threading, but http downloads only become available when they have finished downloading. Because of this, Unity WebGL builds need to decompress AssetBundle data on the main thread when the download is done, blocking the main thread. To avoid this interruption, LZMA AssetBundle compression is not available for AssetBundles on WebGL. AssetBundles are compressed using LZ4 instead, which is de-compressed very efficiently on-demand. If you need smaller compression sizes than LZ4 delivers, you can configure your web server to use gzip or Brotli compression (on top of LZ4 compression) on your AssetBundles. See documentation on Deploying compressed builds for more information on how to do this.
AssetBundle caching using WWW.LoadFromCacheOrDownload is supported in WebGL using the IndexedDB API from the browser to implement caching on the user’s computer. Note that IndexedDB may have limited support on some browsers, and that browsers may request the user’s authorization to store data on disk. See documentation on WebGL browser compatibility for more information.
Stripping
Unity removes all unused code from your build by default. You can change this via the Player settings (menu: Edit > Project Settings, then select the Player category): Select the Other Settings panel to access the Strip Engine Code option. It is better to build with stripping enabled.
Issues with code stripping
Code stripping might cause issues with your project if it strips code which is actually necessary. This can be the case when you load AssetBundles at run time which contain classes that are not included in the main build, and have therefore been stripped from the project. Error messages appear in your browser’s JavaScript console when this happens (possibly followed by more errors). For example:
Could not produce class with ID XXX
To troubleshoot these errors, look up the ID (such as XXX in the example above) in the Class ID Reference to see which class it is trying to create an instance of. In such cases, you can force Unity to include the code for that class in the build, either by adding a reference to that class to your scripts or to your Scenes, or by adding a link.xml file to your project.
Below is an example which makes sure that the Collider class (and therefore the Physics module) gets preserved in a project. Add this XML code to a file called link.xml, and put that file into your Assets folder.
If you suspect that stripping is causing problems with your build, you can also try disabling the Strip Engine Code option during testing.
Unity does not provide a convenient way to see which modules and classes are included in a build, which would allow you to optimize your project to strip well. However, to get an overview of included classes and modules, you can look at the generated file Temp/StagingArea/Data/il2cppOutput/UnityClassRegistration.cpp after making a build.
Note that the Strip Engine Code option only affects Unity engine code. IL2CPP always strips byte code from your managed dlls and scripts. This can cause problems when you need to reference managed types dynamically through reflection rather than through static references in your code. If you need to access types through reflection, you may also need to set up a link.xml file to preserve those types. See the documentation page on iOS Build size optimization for more information on link.xml files.
Moving build output files
To change the location of your Build folder, change the URL of the JSON file (the second argument of the UnityLoader.instantiate) in the index.html file.
To change the location of the files inside the Build folder, change their URLs (that is, dataUrl, wasmCodeUrl, wasmMemoryUrl, and wasmFrameworkUrl) in the JSON file. All non-absolute URLs in the JSON file are treated as URLs relative to the location of the JSON file. You can specify URLs on external servers for these if you want to host your files on a content distribution network (CDN), but you need to make sure that the hosting server has enabled Cross Origin Resource Sharing (CORS) for this to work. See the manual page on WebGL networking for more information about CORS.
Incremental builds
The C++ code generated for your project by IL2CPP is compiled incrementally; that is, only generated C++ code that has changed since the last build is compiled again. Unchanged source code re-uses the same object files generated for the previous build. The object files used for incremental C++ builds are stored in the Library/il2cpp_cache directory in your Unity project.
To perform a clean, from-scratch build of the generated C++ code which doesn’t use incremental compiling, delete the Library/il2cpp_cache directory in your Unity project. Note that if the Unity Editor version differs from the one used for the previous WebGL build, Unity does a clean, from-scratch build automatically.
2019–06–10 Page amended
Full Without Stacktrace added in Unity 2017.3
