Assets<\/h1>\n\n\n\n
Assets cause native memory<\/a> and managed memory implication during runtime. The Unity runtime doesn’t return managed memory to the operating system for reuse until the user terminates the application. The managed heap grows if it becomes too fragmented and runs out of available memory. Due to this unpredictable behavior, it is critical to know how Assets occupy managed memory:<\/p>\n\n\n\n Please read the understanding managed memory section<\/a> of the Understanding Optimization in Unity guide<\/a> to gain a deeper understanding of the managed heap.<\/p>\n\n\n\n On iOS<\/strong> and Android,<\/strong> choose between the Mono or IL2CPP Scripting Backends in Player Settings. To change the Scripting Backend, go to the Player Settings<\/strong> window (menu: Edit > Project Settings > Player<\/strong>), scroll down to the Other Settings<\/strong> section, and select either Mono<\/strong> or IL2CPP<\/strong> from the Scripting Backend<\/strong> drop-down menu.Note<\/strong>: As of 2017.3, choose either the IL2CPP<\/strong><\/a> Scripting Backend or the Mono Scripting<\/strong> Backend. However, both WebGL and UWP only support IL2CPP. iOS still supports the Mono Scripting Backend for fast iteration, but you cannot submit Mono (32-bit) application to Apple anymore.<\/p>\n\n\n\n Each Scripting Backend has benefits and drawbacks that should influence your decision on which is the right choice for your situation:IL2CPP<\/p>\n\n\n\n Mono<\/p>\n\n\n\n Tip:<\/strong> You should use IL2CPP to both develop and ship your Project. If iteration times end up being too slow using IL2CPP, switch temporarily to the Mono Scripting Backend during development to improve iteration speed.Note<\/strong>: The default target architectures in the Player Settings are optimized for release builds<\/strong>. Using this default during development increases your build time because Unity builds the binary for each target architecture selected:<\/p>\n\n\n\n Code size has a direct influence on disk space and runtime memory. It\u2019s important that Unity removes any code paths you aren\u2019t using from the code base. Unity strips code automatically during a build, working on two different levels:<\/p>\n\n\n\n Unity strips managed code at the method level<\/a>. To change the Stripping Level, go to the Player Settings<\/strong> window, scroll down to the Other Settings<\/strong> section, locate the Stripping Level<\/strong> drop-down menu and select Strip Assemblies<\/strong> .The UnityLinker removes unused types (classes, structs, etc.) from the Intermediate Language<\/a> (IL). Even if you use a type, the UnityLinker removes the type\u2019s unused methods.Note<\/strong>: Although this functionality is optional on builds using the Mono Scripting Backend, it is always enabled on builds using the IL2CPP Scripting Backend.<\/p>\n\n\n\n Unity enables Strip Engine Code<\/strong> by default in the Player Settings<\/strong> and enables native code stripping<\/a>. Enable Strip Engine Code<\/strong> to remove unused modules and classes in the native Unity engine code. Disable Strip Engine Code<\/strong> to preserve all of the modules and classes in the native Unity engine code.Note:<\/strong> For publically available platforms, native code stripping is only supported on iOS, WebGL, and Android.Unity 2017.3 onwards supports native code stripping on Android; in prior versions, the Unity Android runtime shipped as a pre-linked .so<\/em> library, which Unity could not strip. The Android runtime shipped in 2017.3 is a static engine code library, allowing for native code stripping. The final link happens during the build, which is ultimately what accounts for the slightly longer build times.<\/p>\n\n\n\n Note<\/strong>: WebGL is currently the only platform which supports stripping unused Unity modules.Unity makes the best attempt to eliminate all unused Unity modules. This means if any Scene uses or any script references a component from a Unity module you include in the build, Unity doesn’t strip the module. Unity doesn\u2019t strip core modules, such as Camera, AssetBundle, Halo, etc. but in future releases, Unity strips these too.<\/p>\n\n\n\n Removing modules saves a substantial amount of memory. For example, one of the largest modules in Unity is the physics module, which accounts for about 5MB of gzipped ASM.js code. If you remove the physics module of an empty Project it reduces the build size from 17MB to 12MB.<\/p>\n\n\n\n The UnityLinker works on a basic mark and sweep principle, similar to a garbage collector. The UnityLinker builds a map of each type and method included in each assembly from a build. The UnityLinker marks a number of types and methods as “roots”<\/em> and the UnityLinker then walks the graph of dependencies between types and methods.If, for example, one type\u2019s method calls a method on another type, then the Unity Linker marks the called type and methodas in-use<\/em>. Once the UnityLinker marks all the roots\u2019 dependencies, the system reweaves the assemblies, omitting methods or entire types that are not marked as used.<\/p>\n\n\n\n The UnityLinker marks its internal classes as roots if they\u2019ve been used in a Scene or from content in Resources. Similarly, the UnityLinker marks all types and methods in the user assemblies as roots.If you use types and methods from other assemblies directly in a Scene or in an Asset you include in resources, Unity marks these as roots.Use the link.xml<\/a> file to mark additional types and methods as roots. If your Project uses AssetBundles, use the BuildPlayerOption.assetBundleManifestPath<\/a> to mark additional types and methods as roots too.<\/p>\n\n\n\n User Assemblies are the assemblies Unity generates from loose code within the Assets folder. Unity places most of the C# code in Assembly-CSharp.dll<\/strong>; whereas Unity places code in \/Assets\/Standard Assets\/<\/strong> or \/Assets\/Plugins\/<\/strong> in Assembly-CSharp-firstpass.dll<\/strong>, which is also considered a user assembly.If a significant proportion of a codebase\u2019 types or methods are unused, you could save some binary-size and build time by migrating stable code into pre-built assemblies and allowing the UnityLinker to strip them. Use Assembly Definition Files<\/a> to migrate stable code into pre-built assemblies.<\/p>\n\n\n\n For reference types, IL2CPP generates the implementation (C++ code) which can be shared between Generics using reference types. However, IL2CPP doesn’t share value types because IL2CPP needs to generate the code for each of the types separately. This results in your code size increasing.In general, there should not be any noticeable performance difference, but it depends on the specific use-case and what it should be optimized for. Classes are usually on the heap while structs are on the stack (with some exceptions, such as in the case of coroutines). For memory performance and usage this matters, and using non-reference types leads to other problems. You must copy function parameters using value types to influence performance. For additional information see this blog post<\/a> for more information. Be warned though that Integer or Enum types are not<\/em> shared at this moment.<\/p>\n\n\n\n Assembly Definition Files<\/a> allow you to define custom managed assemblies and assign user Scripts to them on a per-folder basis.In turn, this results in faster iteration times, because Unity will only build those assemblies actually affected by script changes.Note<\/strong>: While multiple assemblies do grant modularity, they also increase the application\u2019s binary size and runtime memory. Tests show that the executable can grow by up to 4kB per assembly.<\/p>\n\n\n\n Build Report<\/a> is an API which is included in Unity but has no UI yet. Building a Project generates a buildreport<\/em> file which lets you discover what is stripped and why it was stripped from the final executable.To preview the stripping information:<\/p>\n\n\n\n The Build Report tool connects to your running Unity Editor, downloads and presents the breakdown of the build report.It\u2019s possible to use the binary2text<\/strong> tool on the generated file in Library\/LatestBuild.buildreport<\/strong> to view data from the report. Binary2text<\/a> is shipped with Unity under Unity.app\/Contents\/Tools\/<\/strong> on Mac or Unity\/Editor\/Data\/Tools\/<\/strong> on Windows. The build report is available in Unity 5.5 and later.<\/p>\n\n\n\n Native memory is a key component when optimizing applications as most of the engine code is in resident memory. When you integrate code in Native Plugins you can control it directly, however it is not always possible to control and optimize the native memory consumption from Unity internal systems. Internal systems use different buffers and resources, and it may not always be apparent how that influences memory consumption. The following section details Unity internal systems and explains memory data you often see in a native profiler.<\/p>\n\n\n\n Unity uses many different native allocators and buffers. Some are persistent, such as the constant buffer, while others are dynamic, such as the back buffer. The following subsections describe buffers and their behavior.<\/p>\n\n\n\n Unity stores constants in a 4MB buffer pool and cycles through the pool between frames. The pool is bound to the GPU for the duration of its lifetime and shows up in frame capture tools such as XCode or Snapdragon.<\/p>\n\n\n\n Unity uses block allocators in some internal systems. There is memory and CPU overhead anytime Unity needs to allocate a new page block of memory. Usually, the block size of the page is large enough that the allocation only appears the first time Unity uses a system. After the first allocation, the page block is reused. There are small differences in how internal systems use the block allocator.<\/p>\n\n\n\n The first time you load an AssetBundle, additional CPU and memory overhead is required as the block allocators spin up, allowing the Asset Bundle system to allocate the first page block of memory.Unity reuses the pages that the Asset Bundle system allocates, however, if you want to load many Asset Bundles at once you may have to allocate a second or third block. All of these stay allocated until the application terminates.<\/p>\n\n\n\n Resources use a block allocator shared with other systems, so there is no CPU or memory overhead when loading an Asset from Resources for the first time (as it already happened earlier during startup).<\/p>\n\n\n\n Unity uses a ring buffer to push textures to the GPU. You can adjust this async texture buffer via QualitySettings.asyncUploadBufferSize<\/a>. Note<\/strong>: You cannot return Ring buffer memory to the system after Unity allocates it.<\/p>\n\n\n\n Assets cause native and managed memory<\/a> implications during runtime. Beyond managed memory, Unity returns native memory to the operating system when no longer needed. Since every byte counts – especially on mobile devices – you can try the following to reduce native runtime memory:<\/p>\n\n\n\n Be aware that managed memory<\/a> implications can often surpass native memory problems, due to heavy fragmentation of the managed heap.<\/p>\n\n\n\n Beware of cloned materials, as accessing the material property of any renderer causes the material to be cloned even if nothing is assigned. This cloned material will not be garbage collected and is only cleared up when you change Scenes or call Resources.UnloadUnusedAssets()<\/em><\/a>. You can use customRenderer.sharedMaterial if you want to access a read-only material.<\/p>\n\n\n\n Call UnloadScene()<\/a> to destroy and unload the GameObjects associated with a Scene. Note<\/strong>: This does not unload the associated Assets. In order to unload the Assets and free both managed and native memory, you need to call Resources.UnloadUnusedAssets()<\/a> after the Scene has been unloaded.<\/p>\n\n\n\n Unity dynamically sets voices as either virtual or real, depending on the real time audibility<\/a> of the platform. For example, Unity sets sounds that are playing far off or with a low volume as virtual, but will change these sounds to a real voice if they come closer or become louder. The default values in the Audio Settings<\/a> are great values for mobile devices.<\/p>\n\n\n\n3.IL2CPP & Mono<\/h2>\n\n\n\n
Benefits and drawbacks of different Scripting Backends<\/h1>\n\n\n\n
Code stripping in Unity<\/h1>\n\n\n\n
Managed code stripping<\/h2>\n\n\n\n
Native code stripping<\/h2>\n\n\n\n
Unity Module Stripping<\/h1>\n\n\n\n
Stripping modules from an empty project on WebGL<\/h2>\n\n\n\n
C# Code Stripping<\/h1>\n\n\n\n
Roots from Scenes, Resources, Assemblies, and AssetBundles<\/h2>\n\n\n\n
User Assemblies<\/h2>\n\n\n\n
Generic Sharing<\/h1>\n\n\n\n
Assembly Definition Files<\/h1>\n\n\n\n
Build Report<\/h1>\n\n\n\n
4.Native Memory<\/h2>\n\n\n\n
Native Buffer<\/h1>\n\n\n\n
Scratchpad <\/h1>\n\n\n\n
![\"\"\/](\"https:\/\/connect-prd-cdn.unity.com\/20190130\/9dc3f46a-8502-4786-aeb1-5a2266d0bcae_memory_management_in_unity_0.png\")
<\/figure>\n\n\n\nBlock allocator<\/h1>\n\n\n\n
AssetBundles<\/h1>\n\n\n\n
Resources<\/h1>\n\n\n\n
Ringbuffer<\/h1>\n\n\n\n
Assets<\/h1>\n\n\n\n
Cloned Materials<\/h1>\n\n\n\n
Unloading Scenes<\/h1>\n\n\n\n
Audio<\/h1>\n\n\n\n
Virtual Voices<\/h2>\n\n\n\n