Howdy everyone, I got a fairly simple question I’d love your feedback on.
Say I got a Unity project with lots and lots of Unity packages installed, but no direct or explicit usage of any of them in my project. Will Unity’s standard stripping remove them from my builds?
In other words - is the reason many Unity packages don’t come auto-installed in Unity because they just don’t want to make downloading Unity/opening it bloated and slow?
If completely unused a package’s contents will not end up in your build.
Additional upm packages have very little effect on the editor behaviour, minimal compile time and memory usage overhead in my experience.
You will have an initial compile time for a package upon importing the package. And I believe every time when doing a build the package assemblies will be compiled too whether unused or not. Time depends on the package but typically expect fractions of a second here.
Every script change causes an assembly reload, that means more assemblies to be reloaded the more packages you have but you won’t notice this becoming any faster when only removing two or three unused packages. It’s different if you have 10 packages installed and in use vs 50 packages in the project but maybe only using half of them - at that point you should consider a upm package cleanup.
Note that this does NOT apply to Asset Store assets under the “My Assets” category!
UAS assets are not installed as upm packages but imported as .unitypackage packages into your Assets tree hierarchy so they behave like any assets/scripts you may be creating and adding to your project yourself.
Any UAS asset making use of Assembly Definition files should prevent the asset’s scripts to be in your build if you don’t use them by referencing said asmdef in your own asmdefs. However without any asmdefs the scripts of such assets will be compiled into the main assemblies. They may or may not be stripped from builds in that case (likely are but depends on various conditions afaik).
You should generally try to keep your project as clean as possible with UAS assets (those located under “Assets” folder) and ensure all scripts including 3rd party are in an asmdef. Personally I move every UAS asset folder to the “Assets/Plugins” tree right after importing and 99% of the time this still works but sometimes I may have to manually fix a path or something. The plugin tree’s scripts essentially and transparently compile into a “plugins” asmdef if any of the scripts in that tree don’t have an asmdef in their folder or any of the parent folders.
In the reverse, if you often change scripts, be sure they’re not located under Plugins because this causes practically all dependent assemblies to recompile/reload on every change. Plugins is for scripts/assets that hardly ever change.