How Xianyu Scaled Flutter: Architecture, Challenges, and Open‑Source Solutions

Flutter Advantages and Target Scenarios

Flutter is Google’s open‑source UI toolkit that provides a single codebase for iOS and Android, near‑native performance, and a rich set of widgets. It is especially beneficial for:

Small‑to‑medium client teams that need to avoid a 1:1 iOS/Android staffing ratio.

Products whose user base is dominated by Android (e.g., Southeast‑Asian outbound apps) – a “buy‑one‑get‑one” effect on iOS.

Enterprises that ship large volumes of consumer or enterprise apps and want to share UI logic across products.

Embedding Flutter in an Existing Native App

Existing App + Flutter Container

Creating a separate FlutterViewController for each Flutter screen on iOS spawns a distinct Flutter Engine runtime, which dramatically increases memory usage and prevents data sharing between runtimes.

Solution:

Share a single FlutterViewController globally.

Use Flutter Boost (open‑source on GitHub) to manage navigation and communication between the native stack and the Flutter stack.

Introduce a BoostContainerManager that can create independent Navigator instances on demand, similar to opening a new window in a WebView. This enables both push/pop within an existing navigator and the launch of a fresh navigator for complex multi‑tab flows.

The production version runs on Flutter 1.2; support for Flutter 1.5 is planned.

Flutter Page + Native UI Components

Media‑heavy feeds (images, video) require low latency and minimal memory overhead. The default PlatformView and standard Flutter plugins introduce extra copies that increase memory consumption.

Optimization steps:

Leverage FlutterTextureRegistry from the Flutter Plugin API.

Extend the texture interface to accept a GPU TextureID directly instead of a PixelBuffer.

Resulting rendering pipeline changes from:

Native TextureID → copy → PixelBuffer → new TextureID → render

to: Native TextureID → render This eliminates an unnecessary copy, reduces memory usage, and cuts latency for both video and image rendering. The change is being upstreamed to the Flutter Engine and will be open‑sourced in the coming months.

State‑Management Architecture for Complex Business Logic

Initial approach used a community‑based Flutter Redux implementation. As page complexity grew, a monolithic state and reducer became hard to maintain.

Evolution:

Component concept – each UI component owns its own Redux slice (state, actions, reducer). Improves modularity but creates synchronization challenges at the page level.

Inspired by React‑Redux’s connect, the team removed per‑component stores and introduced a Connector that bridges page‑level state with component‑level state. The Connector synchronizes changes bidirectionally, preserving a single global state while allowing independent component development.

Additional performance optimizations were added for long lists and multi‑list compositions.

The resulting framework, Fish Redux , is open‑source on GitHub (supports Flutter 1.5) and is now the standard for Flutter projects within the organization.

R&D Automation and Data‑Driven Workflow

Developers previously spent ~5 minutes coding but up to 2 hours on packaging, uploading, and testing. To improve efficiency:

Enforce a commit‑to‑task policy: each commit must reference a specific requirement or bug; CI checks reject non‑compliant commits.

Webhooks automatically link commits to CI tasks, triggering automated builds, tests, and package uploads.

This automation saves >1 hour per engineer per day and generates clean data for reporting, enabling measurable ROI for new technology adoption.

Future Directions

Planned work includes:

Standardizing Flutter‑level infrastructure (akin to Spring‑Boot for backend services).

Extending dynamic capabilities and integrating UI‑to‑code generation pipelines.

Combining Flutter with Function‑as‑a‑Service (FaaS) to enable full‑stack development for client engineers.