Mobile game performance optimization: where to start

The short answer

Profile on a real low-end phone first, find out whether the processor, the graphics chip or memory is the limit, then fix the largest cost and measure again. The usual suspects on mobile are too many draw calls, too much overdraw from transparent effects, heavy shaders and lighting, garbage collection spikes from scripts, and textures that exhaust memory. Set a frame budget at the start of the project and check it in every milestone.

Why it matters commercially

• Retention. Stutter and long loads lose players in the first session.
• Reach. A large share of the world's phones are entry-level. A game that only runs on flagships has excluded most of the market.
• Store visibility. Google Play tracks stability in Android vitals and can reduce the visibility of apps that exceed its bad-behaviour thresholds for user-perceived crash rate and ANR rate.
• Reviews. Heat, battery drain and crashes are the most common one-star complaints.
• Ad revenue. Sessions that end early show fewer ads.

Step 1: decide the target

A steady 30 is better than an unstable 60. Why this matters to players is explained in frame rate and player experience. Also choose a minimum device, a real phone you own, and test on it every week.

Step 2: profile on the device

The editor on a development PC tells you almost nothing about a phone. Connect the profiler to a device build and record the heaviest moments. You are looking for which of three things limits the frame:

• CPU bound. Scripts, physics, animation, or the cost of preparing draw calls.
• GPU bound. Too many pixels, expensive shaders, overdraw, high resolution.
• Memory bound. Stutters when loading, crashes on low-memory devices.

A quick test: lower the render resolution sharply. If the frame rate jumps, the graphics chip is the limit. If nothing changes, look at the processor.

Step 3: draw calls and batching

Each separate object drawn costs processor time to submit. Hundreds of small draws add up.

• Combine static geometry and use static batching.
• Share materials. Objects with different materials cannot batch.
• Put sprites and interface art in atlases.
• Use instancing for many copies of the same mesh, such as trees or crowds.
• Split interface canvases so one changing number does not rebuild a whole screen.
• Cull what the camera cannot see, including occlusion culling in dense scenes.

Step 4: overdraw and fill rate

Mobile graphics chips struggle when the same pixel is drawn many times, which happens with layered transparent effects.

• Limit full-screen transparent layers, smoke and glow.
• Shrink particle sizes and counts, and cap them by quality level.
• Draw opaque objects front to back.
• Trim empty areas around sprites.
• Reduce or remove full-screen post-processing. Bloom, depth of field and motion blur are expensive on phones.
• Render the 3D scene at a lower resolution than the interface, or use dynamic resolution.

Step 5: shaders and lighting

• Use mobile-oriented shaders and avoid long node graphs designed for PC.
• Bake lighting for static scenes. Real-time shadows are among the most expensive features on mobile.
• Limit real-time lights per object.
• Use light probes for moving characters.
• Reduce shadow distance and resolution.
• Cut shader variants to shorten loading and reduce memory.

Moving between render pipelines changes these costs. See our URP shader conversion guide and Unity 6 upgrade guide.

Step 6: scripts and garbage collection

A common cause of visible hitches is memory being allocated every frame and then cleaned up in a burst.

• Pool bullets, enemies, effects and interface items instead of creating and destroying them.
• Avoid allocations in per-frame code: string building, temporary lists, some language features.
• Cache component lookups.
• Spread heavy work across frames or move it to background jobs.
• Update distant or off-screen objects less often.
• Use the incremental collector where available.

Step 7: physics and animation

• Use simple colliders, such as boxes and capsules, instead of mesh colliders.
• Reduce the physics update rate if gameplay allows.
• Set collision layers so irrelevant pairs are never tested.
• Lower bone counts and skin weights on mobile characters.
• Stop animating characters that are off screen.

Step 8: memory

Low-memory phones close apps that use too much.

• Compress textures with ASTC and cap sizes. This is the largest lever, covered in how to reduce mobile game app size.
• Load only what the current scene needs and unload when leaving.
• Stream long audio.
• Watch for duplicated assets across bundles.
• Test on a device with little memory and with other apps open.

Step 9: heat and battery

Phones reduce processor and graphics speed when they get hot, so a game that starts at 60 can fall to 30 after ten minutes. Sustained performance matters more than peak.

• Cap the frame rate. Rendering faster than the target only makes heat.
• Lower the frame rate in menus and when idle.
• Offer quality tiers and choose a sensible default per device class.
• Use platform tools that report thermal state, such as the Android Dynamic Performance Framework, and reduce load before throttling begins.
• Test for thirty minutes, not three.

Step 10: loading times

• Load asynchronously and show progress.
• Keep the first scene tiny so the game appears quickly.
• Preload shared assets once.
• Warm up shaders during loading to avoid stutter when an effect first appears.
• Compress in a format that decompresses quickly.

Quality tiers

Detect the device class at first launch and set a tier: low, medium, high. Tiers change resolution scale, shadow quality, particle limits, texture size and frame cap. Let players override it in settings. This is how one build serves both a budget phone and a flagship, including foldables with large inner screens, as discussed in foldable game design.

Build performance into production

1. Agree budgets for draw calls, triangles, texture memory and frame time at the start.
2. Profile at every milestone, not at the end.
3. Automate a performance test scene that runs on real devices.
4. Monitor crash and ANR rates after launch.
5. Include device coverage in QA. See game QA and testing cost.

Engine choice affects the baseline, as covered in Unity vs Unreal for mobile games and Unreal Engine on mobile.

Getting help

We run performance audits on Unity and Unreal mobile games and deliver a ranked list of fixes with expected gains, or carry out the work at a fixed price. Packages are on the offer page.

Sources: Android Developers: Android vitals · Unity Manual: Profiler · Android Developers: Android Dynamic Performance Framework. Checked November 11, 2026.

Related: Mobile game development · Unity game development · Get a quote