Flutter List Page Jank Analysis and Frame‑Splitting Optimization

In the current Beike mobile business, many Flutter pages are used, and a specific vertically scrolling list page with three TextFields per item exhibited noticeable jank on a Vivo X23 (Snapdragon 660) device.

The list consists of rows each containing three TextFields; performance overlay shows normal behavior, but under Profile mode the page stalls.

Understanding that smooth scrolling requires ~60 FPS (16.7 ms per frame), the observed frame took up to 130 ms, indicating a bottleneck.

Flutter renders a frame through three main stages: Build (widget to Element and RenderObject trees), Layout (measuring and positioning), and Paint (creating a Layer tree and sending to the GPU). The build stage was identified as the primary source of delay, especially for complex list items.

Lazy building of list items means that when many items near the viewport are constructed simultaneously, the cumulative build time can cause jank (e.g., ten items each taking 10 ms results in 100 ms).

Two optimization strategies are proposed:

Reduce module complexity (incremental list updates, drawing optimizations, modal TextField handling, state‑management improvements).

Split work across frames (frame‑splitting) by inserting lightweight placeholder widgets in the first frame and deferring the construction of actual items to subsequent frames.

Frame‑splitting is implemented via a conditional queue that schedules tasks after the system render completes, respecting task priority weights. Only tasks whose weight meets the configured strategy are executed, and one task is processed per frame.

The process for a list of five visible items: the first frame renders five placeholders and enqueues five high‑priority tasks; over the next five frames each placeholder is replaced by the real item, keeping each frame under the 16.7 ms budget.

Performance measurements on the same device show that after applying the frame‑splitting optimization, the average jank frequency dropped from 33.3 frames per 200 frames to 1 frame, peak frame time reduced from 188 ms to 90 ms, and smooth‑frame ratio increased from 40 % to 64.5 %.

Page transition smoothness also improved, with peak frame time decreasing from 112.5 ms to 30.2 ms.

The solution is open‑source; add the keframe: 2.0.2 dependency to pubspec.yaml and follow the GitHub repository for details.

GitHub: https://github.com/LianjiaTech/keframe Pub: https://pub.dev/packages/keframe