Opened ProjectManager => Modules => Disabled most of modules
Opened BuildSettings: Development Build = false
Opened PlayerSettings: Scripting Backend = IL2CPP API Compatibility = .NET Standard 2.1 IL2CPP Code Generation = Faster Runtime C++ Compiler Configuration = Release Target Architecture = ARM64 (ONLY!) ___OPTIMIZATION FOLDOUT___ Strip Engine Code = true Managed Stripping Level = Minimum
Builded APK is 31.8 mb. (Empty project is 32 mb… ok)
Unpack apk (i used apktool, doesn’t really matter)
Open unpacked folder and go to => lib\arm64-v8a libil2cpp.so file size = 55.4 mb
Return to root folder and go to => assets\bin\Data\Managed\Metadata global-metadata.dat file size = 7.7mb
Is it normal? This is when building only for ARM64, if apk includes ARMv7 will size increase proportionally?
Just for reference, i unpacked apk of ‘Axes.io’, which was build in older version of unity.
One is EMPTY project with 55.4 mb libil2cpp file, another one is already published project with libil2cpp file of 31.3 mb.
Currently project that i work on are in middle stages of development, it’s small project, but it already has libil2cpp.so file of almost 110 mb and global-metadata.dat file of almost 15 mb.
Why it is so bloated? Is this expected behavior in Unity6?
Maybe Strip Engine Code = true do not strip engine code that’s why it is so bloated?
I checked ScriptingAssemblies.json file inside unpacked apk folder (assets\bin\Data), and it contains
dll’s of modules that should have been disabled in PackageManager’s Build-In window.
For example UnityEngine.Wind module:
Does this mean DLL files are still included in build even tho i disabled them? They have been converted to C++ and that’s why libil2cpp file is so bloated?
Tried searching similar issues:
But i DID enable stripping tho?
I tried using linker (created link.xml file and dropped to projects Assets folder), however that did not help:
<linker>
<assembly fullname="UnityEngine" ignoreIfMissing="1">
<type fullname="UnityEngine.WindModule" preserve="none"/>
<!-- Add other modules you want to exclude here -->
</assembly>
</linker>
If i could, i would have dumped libil2cpp.so file to check what is inside, it’s a pity IL2CPPDumper does not support newer versions.
Even if i set Managed Stripping Level to Low instead of Minimum, it just decreases sizes of files by ~1.5-2mb.
Can someone from staff explain - is this intended behavior?
Which is a completely different project. You can’t just take Unity game A and Unity game B and compare their executable file sizes.
Most likely yes. If you had asked why it’s that much bigger than the same project built in another Unity editor version, then it would make sense to investigate. But as it stands there’s no reason to suspect there being an issue.
Be sure to test various options, and editor versions. Not saying that this couldn’t be a problem but if it is, and 2022.3 produces much smaller APKs for instance, then it would be worthwhile to report a bug.
Try it out!
Your managed stripping level is set to Minimum. Meaning it strips next to nothing. You want to use the highest level that still works without problems, and even if it fails I’d investigate why - often you can work around that.
And then you’re building for “faster runtime” and if you check the other options, you’ll notice there’s a setting something to the effect of “smaller executable”. Faster runtime is a tradeoff and it typically comes at a bigger executable size.
Lastly, as always with Unity builds, if you keep Packages (including built-in) as well as runtime assets in your project that you aren’t actually using then this may increase the compiled code size, despite stripping.
Finally, when you publish a mobile project and if it’s anything like iOS, then the published executable will be compressed and encrypted, meaning it’ll most likely be smaller than the APK you submit unless for those cases where the APK can’t be compressed much (typically small APKs), then the encryption may even increase its final size. Meaning the size of the published project on the store may vary significantly in size compared to the file you submit and usually it’s smaller.
Thanks. I’m currently using that setting.
Decreased size of libil2cpp.so by ~52.7mb (from 109.2mb to 56.5mb)
Also, It decreased my game’s startup time by around ~0.5-0.8 seconds.
Also, forgot to say, that when stripping is set Low, some packages are stripped, for example i had Newtonsoft.json package stripped from build. That was most noticeable package for my game, that’s why i could see it. Ofc, i could add link.xml to preserve it, but i don’t want additional hassle of looking for packages that were stripped + i don’t even know if there may be parts of my code that got removed.
These settings provide no guarantees, just like many compiler optimizations such as “loop unroll”. Sometimes, optimizing things for speed can go too far and creates more verbose code that ends up costing performance due to a variety of reasons (ie CPU cache thrashing).
So the “faster runtime” should be regarded as the general case, but there may be exceptions.
No. If you care about performance, you should measure it and see the impact of different settings. You cannot blindly assume things. The general settings give you intended result most of the time, but not all the time. Also, the speed difference for your project may be insignificant between two options, but size difference could be substantial. It really depends on what your project is doing.
As aurimasc said, it depends on project. Since my project is small one, difference of ~100 mb is substantial for me, so i selected Smaller Builds option. However, if i would do some big project where end game is of ~2-3 gb size and where i do some heavy lifting stuff under the hood, Faster Runtime is better choice cuz even ~200 mb extra weight will not matter.
