Reduce Unity Android Build Size with Real Evidence

Make the size comparison reproducible

Suppose your baseline universal APK is 120 MB and a candidate is 104 MB. The arithmetic reduction is 16 MB, or 13.3 percent of that baseline. Those illustrative numbers say nothing about a particular phone's download until the two artifacts use the same distribution method. Write down the Unity editor version, scripting backend, scene list, target architectures and development-build setting beside the measurements. Otherwise, accidentally comparing a development APK with a release app bundle can look like an optimization.

Export the build report or preserve the relevant build-log breakdown. Sort contributors by size and select one change with a clear hypothesis: for example, reducing a background texture's maximum imported resolution because it is never displayed near its original dimensions. Rebuild with just that change first. A package-wide percentage cannot identify whether a texture, an audio bank or a duplicated native library caused the difference.

Use a representative scene as a quality check

For a texture experiment, compare the original and candidate at the device resolution and camera distance at which the asset appears. Check text embedded in textures, normal maps, alpha edges and close-up objects separately. For audio, listen to quiet passages as well as loud ones; a short menu sound and a streamed music track have different quality and loading requirements. Unity's build-size guidance identifies texture, mesh, animation and code-stripping controls, but their acceptable settings depend on this scene-level evidence.

Keep a small results table with the asset path, old and new import setting, package delta and a quality verdict for your selected devices. Record a failed experiment too. If reducing an asset saves 5 MB but makes a required interface label unreadable, the release decision is to restore that asset or use a more suitable format, not to hide the quality loss inside an impressive overall percentage.

Check what was removed or deferred

Trace large files back to the scenes, resources, addressable groups or plugins that reference them. An asset absent from the first scene may still be required in a later level, a language pack or a recovery screen. After changing inclusion, test that path from a fresh installation, rather than from an editor session with previously cached data. A missing file can remain invisible when an older downloaded copy is still present on the development device.

If you move a level into deferred delivery, test a fresh install while offline, then an interrupted download, then a successful retry. The interface needs to explain which content is available and preserve progress during interruption. Measure the base download and later content separately. A smaller initial package with a larger mandatory first-launch download may be a worse experience for the game's audience even when it passes a storefront limit.

Finish by installing the actual candidate through the intended channel. Play a representative late-game path, open each supported locale, and check memory pressure while the largest scene loads. Preserve the accepted artifact and its report together. These observations support a specific reduction claim; the figures in this worked example are a measurement plan, not benchmark results for your project.