How Xianyu Built a Cross‑Platform Flutter Live‑Streaming SDK

Background

Live streaming commerce has become a major growth driver for e‑commerce, and Xianyu, China’s largest second‑hand marketplace, needed a more flexible live‑streaming solution. The existing third‑party SDK suffered from hard‑to‑customize business logic, inconsistent behavior between Android and iOS, and opaque logging, prompting the team to develop a cross‑platform SDK using Flutter.

Overall Design Principles

Reuse native, non‑business core capabilities : Leverage existing native video decoding, WebView containers, and other mature components via plugins to reduce development time.

Keep native thin, Flutter thick : Place UI and most business logic in Flutter, avoiding duplicated code across Android, iOS, and Flutter.

This approach ensures that a change in business logic only requires a single Flutter code modification, achieving true cross‑platform maintainability.

Functional Partitioning

The live‑streaming UI is divided into three layers:

Render Layer : Handles video stream decoding and rendering; it reuses native pull‑stream and codec capabilities while moving control logic to Flutter.

Interactive Container Layer : Renders dynamic interactive components (e.g., red‑packet, auction) using a native‑based container that can be bridged to Flutter.

UI Layer : Implements pure UI interactions such as sharing, commenting, following, and likes entirely in Flutter.

The final architecture diagram (image omitted) shows the Flutter‑centric framework.

Key Module Implementations

Player

The team evaluated open‑source Flutter players and decided to build a custom player to avoid package bloat, version conflicts, and mismatched native dependencies. The solution uses an external texture: the native side creates a texture ID, which Flutter displays.

State management is critical because the MethodChannel communication is asynchronous. Two additional states— transition state and desired state —are introduced to synchronize load, play, and pause operations.

void load() async { /* ... */ }</code><code>void play() async { /* ... */ }</code><code>void pause() async { /* ... */ }</code><code>// Case 1: call play immediately after load (no effect)</code><code>load();</code><code>play();</code><code>// Case 2: rapid play/pause calls (only the last operation takes effect)</code><code>play(); pause(); play(); pause();

Interactive Container Layer

Dynamic H5 components are bridged to a native WebView (PlatformView). To avoid global singleton pitfalls, each live room receives its own API Bridge instance and a dedicated MethodChannel, eliminating cross‑room data contamination.

Seamless Picture‑in‑Picture (PiP)

Instead of creating a new player for PiP, the existing player’s surface is detached and re‑attached to a new window surface, allowing uninterrupted video flow and true seamless switching.

Message Channel

A dedicated messaging plugin abstracts native‑to‑Dart communication. Control messages use MethodChannel (method‑level granularity) while high‑frequency data messages use EventChannel for one‑way streaming.

Componentization

The architecture treats each functional block (LivePage, LiveCell, LiveInteractive, LivePlayer, LiveComment, etc.) as a component. A lightweight Knight framework implements an observer pattern for data sharing, reducing coupling while enabling dynamic UI replacement.

Results

The new Flutter live‑streaming solution launched in version 7.2.40, achieving over 90% user‑view share with no reported log‑related issues. It withstood Double‑Eleven traffic peaks, delivering higher user growth and exceeding expectations for interactive features.

Conclusion & Future Work

The article shares practical insights from Xianyu’s innovation team, highlighting challenges such as PlatformView compatibility, memory optimization, and the goal of a fully native‑coded Flutter player. Continued exploration will focus on these areas to further improve cross‑platform streaming quality.