Game development unity resource management series: The role of SpriteAtlas's Include in Build ( Part 1 ) explores the impact of SpriteAtlas's include in build on packaged resources, and whether to check the impact on resource loading.
This article mainly explains the benefits of not checking include in.
First conclusion:
When the include in build is not checked, we can manually manage the memory of the large texture (generated by the atlas).
analysis:
First check include in build, we load assetbundlecontent in the editor or runtime (refer to the article mentioned at the beginning), you can see that the picture is displayed normally. So why does it display normally?
For the first test, we still add the late binding api to see if it will be called. We will find that when you check include in build, RequestAtlas is not called when assetbundlecontent is loaded, and the picture on the interface is displayed normally. And we did not load the assetbundle where atlastest is located. Conclusion: Unity automatically helps us load the atlas resources.
The second test is whether the atlas resource can be uninstalled. Before loading the prefab in assetbundlecontent, we checked the profiler and found that there is no large image generated by the atlas in Texture2D.
After loading the prefab in assetbundlecontent, the atlas resource is automatically loaded into the memory, and the image is displayed correctly.
Then uninstall the ab package, the sprite reference is lost, but the big picture where the atlas is located is not uninstalled.
(You need to manually control the Active of the GameObject to turn white)
I can’t help thinking about it again, so the atlas resources in this part really can’t be uninstalled? The answer is that they can be uninstalled. After testing, when unloading assetbundlecontent (using AssetBundle.Unload(true), AssetBundle.Unload(false) cannot be used), and then calling Resources.UnloadUnusedAssets(), you can unload the atlas resource that is no longer used.
After the test does not check the include in build, delete all ab resources and re-type, close the editor and reopen the project, and then open the unity profiler tool for analysis
Then see that there are only 2 textures in the memory
Load assetbundlecontent
See that the pictures can be loaded correctly, then look at the profiler
The big picture is added to the memory.
Then call AssetBundle., Unload(true) api, unload the ab package where the atlas is located, and see that the picture turns white, and the sprite referenced by the image is in the Missing state
(You need to manually control the Active of the GameObject to turn white)
Check the profiler, the big picture is also released from the memory
to sum up:
If you don’t check include in build, the developer can manually manage the atlas resources, but it feels more cumbersome to deal with.
Check include in build, and unity will automatically load atlas resources. Developers cannot unload atlas resources directly. They need to call Resource.UnloadUnusedAssets() to manually remove atlas references. Then during the loading process, there may be an atlas automatically loaded by unity, another spriteatlas resource generated when loading the atlas resource in the assetbundle, causing the same atlas in the memory to occupy two copies of the memory.
expand:
Every time you test the profiler, remember to close the project after changing the include in build of the atlas and typing the ab package, and then reopen the project for profiler testing. The reason is that in the editor state, unity is actually a project, and all operations performed are cached. Therefore, when the ab package is opened, a lot of intermediate resources will be generated, and unity is loaded into the memory. At this time, the profiler is actually very inaccurate.