Unity Build Size Experiment

A reproducible Unity project that measures how texture compression, audio compression, Korean font subsetting, and a runtime plugin change an Android APK.

The experiment builds eight APKs while changing one condition at a time, then repeats the full run. The maximum same-step difference between the two runs was 8 bytes.

Results

Tested with Unity 6000.3.7f1, Android APK, IL2CPP, ARM64, Built-in Render Pipeline, Development Build off, and Managed Stripping Level Medium.

Step	Controlled change	APK MiB	Delta MiB
0	Minimal experiment project	14.32	-
1	2048x2048 texture, Android RGBA32	28.12	+13.80
2	Same texture, Android ASTC 6x6	16.14	-11.98
3	Add 30-second stereo audio, PCM	21.19	+5.05
4	Same audio, Vorbis quality 0.5	16.60	-4.59
5	Add full Noto Sans KR dynamic font	19.49	+2.89
6	Same font, app-specific subset	16.63	-2.86
7	Add DOTween, preserved and referenced at runtime	17.10	+0.46

The exact numbers belong to this configuration. The reusable part is the method: fix the settings, change one variable, measure the final artifact, and keep the final APK size separate from Unity's BuildReport metrics.

Reproduce It

Requirements

• Unity 6000.3.7f1
• Android Build Support, SDK, NDK, and OpenJDK installed through Unity Hub
• macOS, Windows, or Linux supported by that Unity version

Run from the Editor

1. Clone this repository.
2. Open the repository root as a Unity project.
3. Select Hano Studio > Build Analyzer > Run Full Size Experiment.
4. Wait for all eight Android builds to finish.

Results are written to:

• Builds/experiment-results.csv
• Builds/Experiment/step-00-baseline.apk through step-07-dotween-runtime.apk
• Builds/Reports/*-summary.txt
• Builds/Reports/*-assets.csv

Run from the command line

git clone https://github.com/hellohanostudio/BuildAnalyzer.git
cd BuildAnalyzer
/Applications/Unity/Hub/Editor/6000.3.7f1/Unity.app/Contents/MacOS/Unity \
-batchmode \
-quit \
-projectPath "$(pwd)" \
-executeMethod HanoStudio.BuildAnalyzer.Editor.ExperimentBuildRunner.RunAllSteps \
-logFile "$(pwd)/Builds/full-experiment.log"

Adjust the Unity executable path for Windows or Linux.

What Is Controlled

• One saved scene with one camera, one directional light, and one cube
• APK output, IL2CPP, ARM64 only
• Development Build off
• Managed Stripping Level Medium and engine code stripping on
• The same generated 2048x2048 high-entropy texture for RGBA32 and ASTC
• The same deterministic 30-second stereo WAV for PCM and Vorbis
• The same Noto Sans KR source font before and after subsetting
• The same DOTween Free DLL, excluded before step 7 and preserved at runtime in step 7

The scene contains a small runtime reference harness so each tested asset is genuinely referenced and survives normal build stripping.

Why Three Size Metrics?

The reporter records three values separately:

1. Final APK file bytes from FileInfo.Length
2. BuildReport.summary.totalSize
3. The sum of BuildReport.packedAssets[].contents[].packedSize

They are not interchangeable. In the final measured build they were 17.10 MiB, 143.54 MiB, and 5.60 MiB respectively.

The DOTween step shows why this matters. The APK grew by 0.46 MiB while the packed-asset report attributed only 192 bytes to the DLL path. Most growth appeared in IL2CPP native code and metadata.

CI Build-Size Gate

The project also includes a small CI gate that compares a generated *-summary.txt report against a versioned JSON baseline.

The sample baseline lives at:

• BuildSizeBaselines/android-dotween-runtime.json

Run the gate against the measured step 7 summary:

/Applications/Unity/Hub/Editor/6000.3.7f1/Unity.app/Contents/MacOS/Unity \
-batchmode \
-quit \
-projectPath "$(pwd)" \
-executeMethod HanoStudio.BuildAnalyzer.Editor.BuildSizeGateCli.Run \
-buildAnalyzerBaseline "$(pwd)/BuildSizeBaselines/android-dotween-runtime.json" \
-buildAnalyzerSummary "$(pwd)/Results/raw/step-07-dotween-runtime-summary.txt" \
-buildAnalyzerReport "$(pwd)/Builds/Reports/build-size-gate-report.txt" \
-logFile "$(pwd)/Builds/build-size-gate.log"

Exit codes:

Code	Meaning
0	Pass, or warning when -buildAnalyzerFailOnWarning is not set
1	Size regression failed a threshold
2	Baseline file is missing
3	Invalid input, such as a missing summary metric

Useful flags:

• -buildAnalyzerFailOnWarning turns warnings into CI failures.
• -buildAnalyzerAllowMissingBaseline lets the first run continue while still reporting that no baseline exists.

The committed sample output is Results/ci-gate-sample-pass.txt.

You can run the built-in self-test for pass, warning, failure, and missing-baseline cases:

/Applications/Unity/Hub/Editor/6000.3.7f1/Unity.app/Contents/MacOS/Unity \
-batchmode \
-quit \
-projectPath "$(pwd)" \
-executeMethod HanoStudio.BuildAnalyzer.Editor.BuildSizeGateSelfTest.Run \
-logFile "$(pwd)/Builds/build-size-gate-self-test.log"

Repository Layout

Assets/BuildAnalyzer/Editor/
BuildAssetSizeReporter.cs # Exports ranked PackedAssetInfo data
BuildSizeGate.cs # Compares summary metrics against a JSON baseline
BuildSizeGateCli.cs # CI-friendly executeMethod wrapper with exit codes
BuildSizeGateSelfTest.cs # Verifies pass, warn, fail, and missing-baseline cases
ExperimentBuildRunner.cs # Generates inputs and builds all eight steps
ExperimentEvidenceWindow.cs # Displays verified results inside Unity
Assets/BuildAnalyzer/Runtime/
ExperimentReferences.cs # Keeps test inputs referenced at runtime
BuildSizeBaselines/
android-dotween-runtime.json # Versioned CI gate baseline
ExperimentInputs/
Fonts/ # Full and subset Noto Sans KR inputs
DOTween/ # Standard DOTween Free DLL and license
Results/
ci-gate-sample-pass.txt
experiment-results-run1.csv
experiment-results-run2.csv
raw/ # Per-step summary and packed-asset exports

Raw Data

• Run 1 CSV
• Run 2 CSV
• Per-step raw reports

License

The original experiment code is licensed under the MIT License.

Noto Sans KR and DOTween keep their own licenses. See THIRD_PARTY_NOTICES.md and the license files under ExperimentInputs.