Skipping the "why mobile optimization matters" preamble — you already know Editor performance lies to you. The specific mistake worth flagging: material fragmentation.
200 trees, each with its own material instance (even when the only difference was a trivial color tint), meant 200 separate draw calls. Mobile CPUs handle draw calls far worse than desktop CPUs handle the same load. Switching all 200 to a single shared material with GPU Instancing enabled cut draw calls by more than half — same visuals, same tree count, completely different cost.
The actual profiling workflow, if you're guessing instead of measuring:
Window > Analysis > Profiler, with a Development Build + Autoconnect Profiler enabled on your actual target device — not Play Mode.
Click the frame spike, expand the CPU breakdown.
Physics.Processing dominating → too many active Rigidbodies or Mesh Colliders where a primitive collider would work.
Rendering/Camera.Render dominating → draw calls, overdraw, or shader complexity — check for the material-fragmentation pattern above first.
GC.Collect dominating → allocations inside Update(), usually new calls or LINQ creating garbage every frame.
One non-obvious setting worth checking explicitly rather than trusting platform defaults: Application.targetFrameRate — Unity mobile builds can default to 30 FPS unless you set it yourself at startup.
Full breakdown of build settings, batching, overdraw, and physics tuning for mobile: https://digitaltoolify.blogspot.com/2026/06/unity-mobile-optimization-complete.html
Curious what people are seeing for GPU Instancing gains on more complex meshes than trees — has anyone benchmarked it on skinned/animated instances?
Top comments (0)