Speed up the build process of your Unity projects
Few questions before reading
Are you suffering from a few hours of builds of your project? Your project is too old and super risky to apply new changes to the structure of your project. Or you want to start a new project and prevent such issues in the future to reach more flexibility.
If you answer True you might find some new ideas or look differently on your build problems.
We will take a look at improvements from these sides:
- Agent&Hardware Configuration
- Client architecture
- Approaches
- Player Settings
Prerequisites:
It is relevant for Unity 2020 and Unity 2021.
Let's assume you have CI/CD pipeline, and the build process happens remotely on agents
To be focused and more concrete let's take the Android target platform for example.
Clear builds mean without a Library folder or a newly fetched fresh repo.
Agent&Hardware Configuration
Unity 2020 and higher perfectly utilize resources of hardware. And the best approach is to use as much as possible powerful hardware. It could be expensive but the easiest way to speed up builds without significant project changes.
SSD — il2cpp compilation will request many read/write operations on the disk and fast access is crucial.
Anti-malware scans filter — Unity found that build times decreased by 50–66% after disabling Windows Defender on a fresh Windows 10 installation
64 Gb RAM and >=16 CPU — virtual of course will be less powerful
Setup Unity Accelerator — will speed up significantly clear builds.
Сlient architecture
I recommend thinking about a multi-project setup. If you have a lot of art content inside one Unity project with a main code base the performance will degrade during the lifetime of the project when the code base and art content are growing constantly. Usually, any art variations or new skins do not need development.
The simple advice is to separate the code base and art content base into different projects.
When you use Addressables, you might be interested to take a look at Loading from Multiple Projects and read this forum that describes examples of configuring Primary Project and Secondary Project.
Also, a great example of multi-project workflow could be discovered at Unite Talk 2020 of Amplitude studio
The other advice is to separate the technical third-party code base ( Facebook, Firebase, Braze, etc ) from the core and feature code base into different Unity projects.
It depends on which tasks for QA you have more in your regular daily routine. But the gameplay or UI tasks not are required at all times to get the functionality of third parties. Anyway, you can mock the data that you need.
Approaches
Next, I recommend setting up a few development build profiles that are different from the build options set and will align with your studio's needs and process. Different build options will speed up significantly your builds.
If you need to test gameplay features you can build only Android amrv7 — architecture with mono only. And it will be significantly faster than building all supported architecture of clients.
For example:
- QA — feature/QA-technical
- Prerelease
- Release
QA feature is the most fastest development build with all debug capabilities in the build. In this profile you can reuse one Library folder safely. Unity fixed bugs from 2020 that caused issues when in one project could be builded different state branches.
QA technical is similar to Release and it needs when you do platform depended changes like new shaders or update Facebook SDK. And it will require making tests on all supported platforms. In this profile, all debug capabilities are enabled like Charles Proxy, debug panel, as many as possible logs and etc.
Usually Prerelease is similar to the Release profile and the difference is only in additional capabilities to test features, different backend environment, and more logs.
Release builds will be uploaded to stores and after smoke tests opened for your users.
Next, when you integrate Quality Gates on your pull requests with compilation per different platforms with your custom scripting define symbols and with simple Unity play mode tests it will exclude many build requests when the branch has errors and is not compiled.
From the studio approaches you can agree about testing not platform-dependent tasks inside Unity with Device Simulator in some cases. That result will reduce the impact on your CI/CD.
Or developers could verify fast check with scripting patch mode on their dev machines. The feature is available from 2021 Unity.
Finally, you can decrease the count of build requests by adding configuration capabilities directly to your build. For instance, If you have multi-backend environments it makes sense to give the ability to switch the client into a new env from the debug panel in build and avoid building a new client.
Player Settings
Unity allows using of its engine in so many kinds of product cases and alternatives. And if you take a look at your player settings I am pretty sure you find some unused for your product. In this case, you can disable and it will speed up the build because will be fewer operations in the Unity build process.
When you defined build profiles like
- QA — feature/QA-technical
- Prerelease
- Release
You can leave some optimizations only for the Release profile and do not use them for QA builds.
For instance: Compression method — LZ4 for QA and Prerelease and LZ4HC for Release. For art-based projects - Texture MipMap stripping, Optimise mesh data, and Prebake collision meshes might be disabled in QA and enabled from Prerelease.
By default, Unity likes to enable Lighting or Lightmap functionalities in the project but a lot of mobile projects do not need this — feel free to turn it off.
When you do some UI changes you do not need for test purposes all target architectures like ARMv7, Arm64, X86, and X86–64. And you are not going to upload the build into Google. In such cases, the best option is to build only Android armv7 mono for the QA feature profile.
In my tests for Android target build with Gradle:
- Il2cpp armv7, arm64 — takes X seconds to build.
- Il2cpp armv7 — takes X/1.5 seconds
- Mono armv7 — takes X/3 seconds
- Scripts Only build — Patch — Mono Arnv7 takes x/6 seconds
As you can see the difference are significant.
And of course are you sure that all packages are installed in the project you need? Let's review and remove some from the Unity package manager it will make it easier to strip unused code.
One more thing
Check Unity updates and their change log. Unity regularly invests time to improve and parallels the build process and I see significant improvements from 2018 to 2021 Unity
Many projects use Zenject or Unitask and these third parties produce a huge amount of il2cpp code because of reflection and generic structs that impact on build size and build il2cpp time. Only from 2022 Unity will support IL2CPP Full Generic Sharing.
How to profile build allocation time? You can use BuildReport API and implement a simple editor UI or take Build Report Tool. Unity Build report inspector is not stable and I cannot recommend it.
In conclusion
I believe that time to build clients is one of the important metrics of the technical health of a studio.
Fast building of your project will allow you to decrease the capacity of agents on CI/CD and to have a reasonable time to get artifacts. That will decrease costs to support the infrastructure because it needs fewer machines.
And finally, it should actually decrease the time to market.
Some improvements could be long-term solutions that will require redesigning parts of your build pipeline and client architecture. Some could be fast quick wins and some are good for mid-term planning.
Have the fastest stable Unity builds!
If you liked this story, please show your support by 👏 this story or follow me to get the latest publications in the future.
Thank you for reading!
