Flutter-based IM Architecture Redesign for Xianyu

The Xianyu IM framework, originally built in 2016‑2017, has accumulated technical debt through multiple iterations and a recent Flutter UI migration, resulting in low development efficiency, poor architectural layering, and sub‑optimal performance.

Key problems identified include difficulty locating bugs across Android, iOS, and Flutter layers; unclear separation of business logic from core logic; and performance bottlenecks caused by serializing native data to Flutter via plugins.

Industry cross‑platform solutions are surveyed, covering GUI‑level frameworks (Weex, ReactNative, H5, Uni‑APP) and logic‑level approaches (C/C++, assembly, Flutter, KMM). Xianyu opts for a Flutter‑centric solution, noting that Dart isolates isolate memory heaps, making inter‑isolate communication more complex than Android’s shared heap.

To simplify the architecture, multiple FlutterEngine instances are shared (similar to FlutterBoost), enabling a shared memory model across pages.

The new architecture is divided into four layers: Business, Distribution, Logic, and Data Source. Data originates from push or network requests, is wrapped in native code, and is lifted to Flutter via plugins as protocol entities. The Logic layer flattens data and passes it to the Distribution layer, which then notifies business components through an observer pattern.

Database storage relies on the Sqflite plugin. The original model suffers from two serialized queues (Flutter sync queue and native HandlerThread), leading to slow queries and SQL backlog. An improved design introduces an Entity Cache in Flutter and supports both synchronous and asynchronous operations, recommending async reads and sync writes for stability.

Because Flutter lacks reflection, a custom ORM solution is built using annotation processing (APT) to bind Entity and ORMEntity, mirroring Android’s OrmLite/GreenDao patterns.

The in‑memory model separates sessions (SessionModuleData) and messages (MessageModuleData). Sessions are cached globally, while messages are managed within a MessageContainer that can shrink when a session ends, reducing memory overhead.

State management uses an observer/event‑bus pattern; UI frameworks such as fish‑redux, Provider, or ScopeModel can be plugged in without affecting core logic.

The original synchronization model involved multiple threads (ACCS, Main, Region) and complex lock‑based coordination, leading to high concurrency issues. The new model replaces this with a simple flag‑based async/sync queue within Flutter, eliminating lock overhead.

Performance results show a 40 MB memory reduction, 4 mAh lower power consumption, and a 1 % CPU drop in private‑chat scenarios on a Xiaomi 9 device. The unified Flutter codebase also halves development, testing, and visual‑acceptance costs.

The outlook emphasizes that cross‑platform solutions like Flutter are preferable to unsafe JS or heavyweight C++ approaches, and that the migration is driven by legacy technical debt rather than Flutter for its own sake.