Flutter Map Performance: A Lifecycle and Measurement Playbook

A flagship phone can hide a driver-app defect. The same screen may stutter on a budget Android when location updates rebuild unrelated widgets, marker assets are recreated, and the map receives a new camera command on every GPS change.

The fix is not one animation flag. It requires disciplined state ownership, marker update frequency, overlay composition, lifecycle recovery, and control over what the application asks the UI thread to do on every GPS ping.

This should replace the existing Impeller article

App Clone Labs already has a published post targeting Flutter Impeller, 120fps, real-time maps, and app-clone performance. This draft should update that URL rather than create a competing page:

/blog/flutter-impeller-benchmarks-app-clones-real-time-maps

The upgrade changes the article from a broad Impeller explainer into a specific device trace and remediation case study.

The map was not the only thing rebuilding

The first implementation kept too much driver state near the screen root:

• latest coordinate;
• route polyline;
• driver availability;
• trip status;
• ETA;
• customer card;
• earnings summary;
• network banner;
• location-permission state;
• map camera instructions.

When a coordinate changed, a broad listener invalidated the parent and rebuilt descendants that did not depend on that coordinate.

At a five-second GPS interval this could appear acceptable. During navigation, camera motion, trip events, and reconnect recovery, the work converged into visible stutter.

Establish the frame budget

Flutter targets 60fps, or 120fps on devices that support it. Its performance documentation gives approximately 16ms per frame at 60fps; high-refresh rendering requires a tighter budget, around 8ms for 120fps. Flutter recommends profiling in performance tooling and tracking jank, startup, battery, and other device-level metrics through benchmark tests. (Flutter performance profiling,Flutter performance best practices)

Our acceptance criteria were device-specific:

Device tier — Refresh capability — Frame target — p95 UI time — p95 raster time — Jank threshold

Budget Android — disclose device rate — 60fps where supported — under 16ms — under 16ms — disclose

Mid-range Android — disclose device rate — native refresh target — measure — measure — disclose

Flagship Android — disclose device rate — native refresh target — measure — measure — disclose

iPhone reference — disclose device rate — native refresh target — measure — measure — disclose

“120fps on budget Androids” should remain out of the headline unless the named budget device actually has a 120Hz panel and the traces support the claim.

Impeller helped, but it did not fix state management

Impeller is the default Flutter renderer on iOS and on Android API 29 and later in current Flutter releases. Its design precompiles shaders and builds rendering pipelines ahead of time, reducing runtime shader-compilation work that historically contributed to animation jank. (Flutter Impeller documentation)

That does not make expensive widget rebuilds free. It does not prevent oversized marker bitmaps, excessive polyline decoding, synchronous JSON work, repeated camera commands, or unbounded location events.

The renderer can reduce one class of stutter while the application continues generating another.

Change 1: Separate telemetry from presentation state

Raw GPS input did not write directly into every widget listener.

We separated:

1. Telemetry state: raw coordinate, accuracy, bearing, speed, timestamp.
2. Trip state: accepted, arriving, waiting, active, completed, cancelled.
3. Map presentation: smoothed coordinate, visible route segment, camera target, marker rotation.
4. Peripheral UI: customer card, earnings, notifications, connectivity.

The telemetry layer could receive every permitted update. The presentation layer emitted only changes the user could perceive and the screen needed to render.

The implementation can use Riverpod, Bloc, Provider, or another deliberate state model. The important test is whether a telemetry change invalidates only the widgets that consume it.

Change 2: Narrow rebuild boundaries

Instead of rebuilding the map shell when any trip field changed, we isolated listeners around the smallest useful surfaces:

• marker position and bearing;
• route overlay;
• trip action panel;
• connectivity banner;
• ETA label;
• customer details.

Static controls and map configuration stopped participating in location-driven rebuilds.

The Flutter widget rebuild profiler can expose unnecessary rebuild counts, while DevTools separates UI-thread work from raster-thread work. We used both views because a smooth raster trace cannot excuse an overloaded UI thread, and the reverse is also true. (Flutter DevTools Performance view)

Change 3: Stop recreating map assets

Custom markers were decoded and resized outside the hot update path. Stable marker assets were cached. Only the driver marker’s position and necessary rotation changed during telemetry updates.

The same rule applied to:

• route patterns;
• pickup and destination icons;
• cluster assets;
• accuracy circles;
• vehicle-type markers.

Use DevTools allocation and raster traces to confirm that asset caching reduces work rather than relying on visual judgment.

Change 4: Coalesce location and camera updates

GPS events, visible marker motion, backend persistence, ETA calculation, and camera movement do not need one shared frequency.

The revised system used separate policies:

• ingest valid raw updates;
• reject stale or implausible coordinates;
• smooth visible marker movement;
• persist history at an operationally useful cadence;
• recalculate ETA only when distance, time, or route state justified it;
• move the camera only when the driver crossed a defined visual boundary or the user requested recentering.

Publish the chosen thresholds with the device trace so readers can reproduce the behavior.

Repeated camera animation is a common source of self-inflicted map jank. The map should not fight the driver every time the GPS estimate moves.

Change 5: Decode route work away from the critical frame

Large encoded polylines and route responses should not be parsed repeatedly during build. The application cached stable route geometry and moved expensive transformation away from the visible frame path.

When a reroute arrived, it replaced route state once. It did not append fragments indefinitely or recreate unrelated overlays.

The benchmark recorded route size because “map performance” changes materially between a two-kilometre test path and a dense city route with thousands of points.

Change 6: Treat lifecycle recovery as a state transition

The driver app had to recover when:

• it returned from the background;
• location permission changed;
• the OS reclaimed the process;
• connectivity changed;
• the active trip was updated elsewhere;
• the authentication token expired;
• the map controller was recreated.

On resume, the app reconciled durable trip state before restarting presentation updates. It did not assume that the last in-memory coordinate or trip action remained authoritative.

This prevented a class of “smooth but wrong” behavior where the animation continued from stale state.

Before and after

Metric on the named budget device — Before — After — Change

p95 UI-thread frame time — report milliseconds — report milliseconds — calculate

p95 raster-thread frame time — report milliseconds — report milliseconds — calculate

Missed frames per route — report count — report count — calculate

Rebuilds per location update — report count — report count — calculate

Peak memory — report MiB — report MiB — calculate

Battery consumed per 30-minute route — report percentage — report percentage — calculate

Thermal state — report state — report state — compare

The device matrix we would use again

At minimum:

• one low-memory Android device on the oldest supported OS;
• one budget device representative of the driver market;
• one mid-range Android device;
• one high-refresh Android device;
• one supported iPhone reference;
• poor-network and reconnect conditions;
• a 30-minute thermal and battery run;
• foreground, background, resume, and process-recovery tests.

An emulator is useful for development. It is not evidence for driver-device performance.

Founder takeaway

Impeller improves Flutter’s rendering foundation. It does not replace application architecture or physical-device profiling.

For map-heavy driver products, the practical work is to narrow rebuilds, separate telemetry from presentation, control marker and route work, respect the lifecycle, and publish frame-time evidence from the devices drivers actually carry.

App Clone Labs treats the cheapest supported driver phone as an architecture input—not a QA surprise at the end of the build.