FlutterWorker: Cross‑Platform Logic Processing Framework for Mobile Apps

The Xianyu community’s main pages are implemented natively, with parts using Flutter and Weex. Repeated data‑handling logic for posts, topics, likes, and comments leads to low cost‑effectiveness across multiple tech stacks. To improve development efficiency, a cross‑platform logic tool—FlutterWorker—was created to run on the client side, eliminating dependence on server‑side BFF layers.

FlutterWorker adopts a logical cross‑platform approach. Existing solutions such as C++ (with native bindings) and JetBrains’ KMM were evaluated, but Dart was chosen to ensure consistency across iOS, Android, and Flutter while reducing manpower.

Overall Architecture

The design defines a reusable logic center where data requests originate on the client, are processed entirely within FlutterWorker, and callbacks return results. Key architectural concerns include a stable runtime environment, aligned data structures across platforms, extensible interfaces, and built‑in monitoring.

The system is divided into four layers:

Runtime Container Layer – relies on FlutterEngine and Isolate; FlutterEngineGroup is used to share resources and reduce memory overhead.

State Management Layer – stores and synchronizes state (currently a demo).

Data Processing Layer – handles model synchronization and data conversion using a Dart‑based CLI (dartGen) that generates unified models from YAML/IDL definitions.

Monitoring Layer – provides performance and exception monitoring, with metrics inspired by RabbitMQ (message loss, latency) and real‑time/aggregated reporting.

Implementation Highlights

• Model synchronization: OriginDataModel → TargetDataModel generated via dartGen, ensuring identical definitions on iOS, Android, and Flutter.

• Data conversion: WorkerBinaryMessenger wraps Flutter’s MethodChannel to encode/decode primitive types; Dart models use fish_serializable for JSON (toJson/fromJson) support.

• Monitoring: WorkerMonitor tracks message queues, employs timers or per‑call statistics, and reports both performance and exception data.

Performance Evaluation

Stress tests on the homepage scenario compared native code with FlutterWorker. Results showed memory and CPU increases under 30 MB (short‑term) and under 5 MB (long‑term), with latency reduced by ~5 % compared to the original solution.

The approach enables a single development effort to serve multiple platforms, significantly boosting development efficiency.

Future Work

Planned improvements include optimizing MethodChannel communication (potentially replacing it with pointer‑based native calls), expanding unit‑test coverage, and adding support for front‑end containers such as Weex and H5.