How PowerScrollView Revolutionizes Flutter’s Flow Layout Performance

Background

Most of Xianyu’s business scenarios are built with Flutter, where flow layouts (e.g., search, product details) are the most common. As business iterates quickly and complexity grows, requirements for flow layout capabilities and performance have become increasingly demanding.

Capability gaps: card exposure, scroll anchors, waterfall layouts, etc., can no longer be satisfied by native Flutter widgets or existing open‑source solutions.

Performance gaps: list scrolling smoothness degrades as data and UI complexity increase, harming user experience.

To address these challenges, a generic solution for flow scenarios called PowerScrollView was designed.

Overall Architecture Design

Before designing the architecture, native scrolling containers UICollectionView (iOS) and RecyclerView (Android) were studied. Their section concepts inspired the design, but Flutter’s uniqueness required a hybrid approach that leverages native maturity while fitting Flutter’s paradigm.

Flutter provides ListView and GridView, which are limited. The advanced CustomScrollView composes multiple Sliver widgets for complex scenarios, and PowerScrollView is built on top of it.

The list consists of multiple Sections, each divided into header (optional sticky), content (list, grid, waterfall, or custom), and footer . The container also supports pull‑to‑refresh and load‑more.

Mapping to Slivers:

Section header → SliverBox Section footer → SliverBox Section content → SliverList or SliverGrid Waterfall layout → custom SliverWaterfall Refresh / load‑more → Slivers inserted at list head and tail

The solution is divided into four parts: data source manager, controller, event callbacks, and refresh configuration (see diagram).

Core Features

Automatic Exposure

Traditional Flutter exposure logic placed tracking in the build method, causing duplicate or incorrect exposures. PowerScrollView encapsulates exposure in a unified cell wrapper, records element mount/unmount via a custom StatefulElement, and uses InheritedWidget to maintain a list of active elements. During scroll, only on‑screen elements are checked, while off‑screen buffers are ignored, and a sampling rate parameter limits how often checks occur. Height changes from 0 to non‑zero trigger a one‑time exposure.

Scroll to Index

Flutter can scroll by pixel offset but not directly to a specific item. PowerScrollView handles two scenarios:

If the target cell is already in the viewport or buffer, it is located via the element list and scrolled into view.

If the target cell is not present, the system determines scroll direction, performs a fast jump, then recursively continues until the target appears, accepting possible animation roughness.

Performance Optimizations

Why Partial Refresh?

Full list rebuilds after data changes (e.g., load‑more, insert, delete) cause noticeable jank. Reducing the dirty region to only the changed part improves smoothness.

Viewport Refresh Process

When a viewport is dirty, all sliver elements rebuild and the viewport relayouts each visible child based on SliverConstraints. Diagrams illustrate the layout range for SliverList and SliverGrid.

Partial Refresh Implementation

Instead of rebuilding all children, PowerScrollView precisely updates childWidgets and childElements for the affected sections:

Variable child count: a custom SliverChildBuilderDelegate overrides childCount retrieval.

LoadMore: clears widget cache, inserts a placeholder for the loading widget, and dirties the sliver for layout.

Delete: adjusts childWidgets mapping, deactivates the removed element, updates sibling relationships, and marks the sliver dirty.

Insert: similar to delete, updating mappings and layout.

Element Reuse

Inspired by iOS UITableView/UICollectionView and Android RecyclerView, PowerScrollView overrides collectGarbage to move deactivated elements into a pool for later reuse, avoiding full destruction. Proper removal (not setting to defunct) is essential for reuse to work.

Frame‑by‑Frame Rendering

When a frame builds too many cells, frame drops occur. PowerScrollView introduces a placeholder mechanism: simple widgets are built first, while heavy cells are deferred to later frames, smoothing the workload. Benchmarks on a Pixel XL show reduced 90th/99th percentile frame times and fewer dropped frames, though extremely complex cells may still cause issues on low‑end devices.

Real‑World Usage

PowerScrollView is deployed across multiple core pages of Xianyu, providing rich capabilities, strong performance, and low integration cost.

Conclusion and Outlook

PowerScrollView now reliably supports Xianyu’s flow layouts, delivering smoother scrolling and richer features. Future work includes optimizing waterfall layout calculations for low‑end devices, deeper engine‑level element reuse, and exploring end‑to‑end solutions that combine list containers with dynamic templates for cloud‑native page building.