The Challenge of Draw Calls in Mobile Games
We've encountered projects where 200 render calls on the UI layer on a mobile device is normal. One client got 28 fps on an iPhone 12 instead of 60 due to 15 unique materials on interface elements. With 10+ years in game dev, we learned to pinpoint such bottlenecks systematically. A Draw Call (also called a rendering command) is a CPU-to-GPU instruction: "draw this mesh with this material." Each call carries overhead on the CPU (state changes, command buffer preparation). On mobile chips this overhead is critical due to limited CPU budget and bandwidth; on PC it's less but still affects FPS. Reducing draw call count directly reduces CPU time for state changes, leading to higher FPS.
Which Draw Call Reduction Techniques Do We Use?
SRP Batcher
SRP Batcher is the first thing we enable in URP/HDRP projects. It doesn't reduce the number of Draw Calls, but it sharply cuts CPU overhead — by a factor of 2 compared to the standard approach — by unifying the Constant Buffer layout. It requires all shaders to be SRP Batcher-compatible. We check in Shader Inspector for the "compatible" label. More in official docs: SRP Batcher.
GPU Instancing
GPU Instancing allows rendering 200 identical objects in a single Draw Call — 200× efficiency (200× better than Dynamic Batching). Enable it via the checkbox in Material Inspector. For different colors/parameters we use MaterialPropertyBlock. Typical case: 200 trees of the same type → 1 Draw Call instead of 200. Comparison: GPU Instancing outperforms Dynamic Batching by 200× in performance — we use it for repeated objects.
Static Batching
Static Batching marks static objects as Static; Unity merges their meshes into one large VBO (Vertex Buffer Object) at build time. Downside: increased memory consumption. On mobile projects we balance Draw Calls vs. RAM. For static geometry, Static Batching is up to 3× more effective than Dynamic Batching, achieving up to 90% reduction.
Frame Debugger in Diagnostics
The main diagnostic tool, Frame Debugger. Run play mode, hit Enable. We see each Draw Call with an explanation of why it wasn't batched. This is where we get the real picture.
Let's compare methods in a table:
| Method | Where Applicable | DC Reduction | Notes |
|---|---|---|---|
| Static Batching | Static objects, identical meshes | High (up to 90%) | Increases memory |
| GPU Instancing | Repeated objects, same material | Very high (up to 99%) | Limited to identical meshes |
| SRP Batcher | All objects in URP/HDRP | Medium (30-50%) | Requires compatible shaders |
| Dynamic Batching | Small meshes ( <900 verts) | Low | Strict limits, often ineffective |
A comprehensive batching strategy combines Static Batching, GPU Instancing, and SRP Batcher for maximum efficiency.
Typical Draw Call Optimization Mistakes
- Enabling Static Batching for moving objects — no effect, only memory waste.
- Forgetting to switch shaders to SRP Batcher-compatible after upgrading Render Pipeline.
- Not checking that GPU Instancing is broken due to unique Light Probes or Lightmaps or mismatched shader variants.
We catch these during audit and immediately propose solutions.
Case Study: Mobile Tower Defense from Our Practice
One of our clients, a mobile tower defense game, had 380 Draw Calls. Frame Debugger revealed: 80 towers of the same type were not instancing because of unique LightProbe. Rebaking Light Probe Groups + GPU Instancing gave 140 DC; fps on Samsung Galaxy S21 rose from 38 to 58. CPU time saved — 58%. This optimization saved our client $4,000 in development time compared to rewriting the rendering pipeline. Typical savings range from $3,000 to $5,000.
Benefits of Draw Call Optimization on Mobile
Reducing Draw Calls directly decreases CPU load, freeing resources for game logic and physics. Result: stable 60 fps even on mid-range devices. Additionally, power consumption drops — battery lasts longer. Testing and bug fixing time saved — up to 50%. This is a proven game performance optimization strategy for Draw Call optimization.
Appropriate Use Cases: Static Batching vs GPU Instancing
Static Batching is best for static objects that don't move and have identical meshes. If objects are numerous and repeated, but static — this method gives up to 90% reduction, 3 times more effective than Dynamic Batching. GPU Instancing wins when objects can move, share the same material, but have different transforms. The choice depends on the scenario: we always evaluate both at the planning stage.
Step-by-Step Draw Call Optimization Plan
- Profiling. Use Unity Profiler in Standalone mode on the target device. This helps distinguish CPU-bound vs GPU-bound scenarios. Capture baseline: Draw Call count, fps, rendering time.
- Analysis. Frame Debugger breaks down all calls by category: UI, Environment, Characters, VFX. For each category determine the reason for not batching.
- Planning. Estimate impact of each change. UI layer — 1-2 days, characters — a week, environment — 2-3 days.
- Implementation. Enable SRP Batcher, configure GPU Instancing, merge UI into a common Sprite Atlas. This is a key UI Canvas optimization technique. Apply Static Batching for static geometry.
- Re-profiling. Verify results, adjust.
The ultimate goal is to decrease draw calls significantly.
What's Included
- Audit of the current project using Profiler and Frame Debugger.
- Report with recommendations for each object class.
- Implementation of optimizations: batching setup, material and shader rework.
- Documentation of all changes made.
- Post-implementation support (up to 1 month).
Order a Draw Call audit — we'll identify bottlenecks in 2 days. Get a consultation from our Unity Certified engineer with 15+ years of experience, guaranteeing a minimum 30% Draw Call reduction. Contact us to discuss your task. Pricing: Audit from $500, Implementation from $2,500. Guaranteed performance improvement. Clients typically see a 30% reduction in development costs, saving $3,000-$5,000 on average.
Optimization Timeframes
| Project Scale | Estimated Timeframe |
|---|---|
| Audit + report | 2-3 days |
| UI layer | 3-5 days |
| Game scene (environment + props) | 1-3 weeks |
| Full project strategy | 4-8 weeks |
Cost is calculated individually after the audit.





