A mobile game can look buttery smooth on one phone and strangely jumpy on another, even when both report decent FPS.
The culprit is often timing rather than raw graphics power. Modern screens may refresh at 60Hz, 90Hz, or 120Hz, and some switch rates while the game is running.
Designing Frame Budgets means giving every update a realistic deadline instead of expecting the GPU to work at one universal speed. Once you understand those deadlines, it’s much easier to balance visual quality, responsive controls, and stable animation across devices.
Start With the Display’s Actual Timing
Refresh rate describes how often a screen can update, while FPS describes how many new frames your game produces.
Those numbers are related, but they aren’t interchangeable. At 60Hz, a refresh opportunity arrives roughly every 16.67 milliseconds; at 90Hz, every 11.11 milliseconds; at 120Hz, every 8.33 milliseconds.
That shrinking window matters. A frame that takes 10 milliseconds might fit a 90 FPS target, with limited spare time, but it cannot consistently support 120 FPS. Treat those figures as scheduling deadlines, not an invitation to occupy every millisecond with game code.
Leave Space for Unexpected Work
Suppose a team targets 60 FPS and keeps its main rendering path near 13 milliseconds. The remaining time provides some breathing room for variations in scheduling, synchronization, and presentation.
A fixed percentage of headroom isn’t universal, so measure it on real hardware rather than relying on a magic number.
Separate CPU Work From GPU Work
A frame includes input handling, simulation, animation, draw submission, and graphics processing.
The CPU prepares work while the GPU executes commands, and some stages overlap. Adding total CPU time to total GPU time can therefore exaggerate the actual critical path.
Instead, examine the longest dependency chain and look for stalls at synchronization points.
A crowded render thread, shader compilation, or an overloaded GPU can each make a different frame miss its deadline. Profile those workloads seperately, then optimize whichever one is delaying presentation.
Budget the Expensive Moments
Don’t profile only an empty training level. Explosions, crowded multiplayer scenes, and first-time asset loading reveal spikes that average frame measurements hide. These situations are where a modest buffer can protect the player’s experience.
Match Frame Targets to Supported Refresh Modes
Choosing 60 FPS on a 120Hz screen can work neatly because each game frame spans two refresh cycles.
On a 90Hz-only mode, 60 FPS doesn’t divide evenly into refresh intervals, so display cadence may feel uneven unless the system selects another compatible mode. A steady 45 FPS can be a better fit for 90Hz than an unstable attempt at 60.
Android’s frame-rate APIs allow games to communicate their preferred rate, while the Swappy library helps align frame presentation.
On supported iPhones, CADisplayLink offers preferred frame-rate ranges. Neither platform promises to honor every request, so code must remain flexible when the display changes its mind.
Build a Loop That Survives Rate Changes
Hardcoding movement per rendered frame is a classic trap. If a character moves five pixels per frame, it travels twice as fast at 120 FPS as at 60 FPS. Use elapsed time for visual motion or a fixed simulation timestep with interpolation for predictable gameplay.
Keep simulation timing and rendering cadence related but not identical. That approach helps physics behave consistantly when a device shifts refresh rates or briefly repeats a frame.
It also prevents frame-rate transitions from causing visible speed changes in menus, cameras, and particle effects.
Adjust Visual Complexity Before Frames Collapse
Higher refresh targets leave less time for lighting, shadows, particles, and post-processing. Rather than waiting for visible stutter, consider reducing render resolution, shadow quality, or expensive effects when recent frame times repeatedly approach the deadline.
Protect readability and touch controls before trimming decorative details.
Make changes gradually. A quality system that jumps between settings every few frames can create its own distracting fluctuations.
Add thresholds and cooldown periods so that adjustments happen deliberately instead of occasionaly reacting to one unusual frame.
Test Frame Pacing, Not Just Average FPS
A counter showing 60 FPS can hide alternating fast and slow frames. Record CPU and GPU timings, frame presentation intervals, missed deadlines, and slow-frame percentiles.
Look at demanding scenes, loading transitions, power-saving settings, and devices that support several refresh modes.
For example, compare a phone holding near 11 milliseconds at 90 FPS with another averaging the same value but periodically spiking past 20 milliseconds.
The second experience will likely feel rougher even though their averages look similar. The goal is dependable cadence, not simply an impressive number in a benchmark.
Good mobile performance starts with understanding when each frame must arrive.
By calculating realistic deadlines, profiling CPU and GPU bottlenecks, choosing compatible frame targets, and adapting gracefully to display changes, teams can deliver smoother gameplay without wasting power.
Audit your current frame-time traces this week, then test one high-refresh device and one mainstream phone before setting your next performance target.