Why Flutter’s Inertial Scrolling Trails Chromium and Native Android – A Deep Performance Dive

In a previous article we compared the theoretical animation performance of Flutter and Web (Chromium) and concluded that, due to different inertia‑scroll handling and rasterization mechanisms, Web (Chromium) should far outperform Flutter. Real‑world tests on low‑end Android devices confirmed severe inertia‑scroll frame‑rate issues in Flutter‑based business apps.

Business A: simple page, average FPS 40‑50 on low‑end phones, 50‑55 on mid‑range, noticeable stutter.

Business B: complex page, FPS drops to 30‑45 on low‑end, ~50 on mid‑range, frequent long stalls.

By contrast, similar Web pages on low‑end phones usually maintain >50 FPS with minimal stalls, and the native Android version of Business B runs 5‑10 FPS higher than its Flutter counterpart.

Web (Chromium) > Native (Android) > Flutter (Android)

Trace analysis on various devices showed that Flutter’s UI thread incurs heavy Build & Layout costs when new list items are mounted, often exceeding a vsync period and causing frame drops. Rasterization also contributes: simple pages spend 3‑5 ms per frame, while complex pages can reach 7‑10 ms, and extensive BackdropFilter usage may push frame times to 10‑20 ms.

Web (Chromium) benefits from a dedicated compositor thread and asynchronous rasterization, which keep scrolling smooth. Flutter relies on relayout‑driven scrolling, causing the UI thread to handle both layout and raster work, leading to the observed performance gap.

Native Android uses RecyclerView with view‑tree reuse, allowing partial updates that are far cheaper than Flutter’s full widget rebuilds, further explaining its advantage over Flutter.

Application‑Level Optimizations and Limitations

Some apps, such as the “Idle Fish” project, mitigate long Build & Layout times by reusing elements and employing frame‑splitting rendering, but these techniques still cannot match the efficiency of native view reuse.

Our Engine‑Level Optimization Attempts

Raise thread priorities to protect UI and raster threads.

Refine vsync scheduling to eliminate unnecessary idle time.

Improve TextureView rendering coordination.

Deepen pipeline stages to increase throughput.

Optimize layout algorithms to reduce layout time.

Split new‑item Build & Layout across frames.

Introduce indirect rasterization tricks (opacity hacks) to lower raster cost.

Preliminary results show noticeable smoothness gains, bringing the optimized engine close to native scrolling performance. Future articles will detail each optimization and aim to upstream the changes.

In this context, a “movie frame” refers to ~40 ms (1000/24); “2 movie frames/min” means more than 80 ms of stutter within a minute of continuous scrolling.