How DingTalk Boosted Desktop Flutter Performance with LightweightEngine

1 Introduction

In previous articles we introduced DingTalk's Flutter desktop solution and the need for a multi‑engine approach because sharing a single FlutterEngine is impossible on desktop when supporting multiple windows.

The multi‑engine approach meets current needs but shows drawbacks: occasional engine start‑up stalls, longer first‑frame time (1‑2.6 s), and high memory usage (~70 MB per engine), especially on 32‑bit Windows where Flutter runs in JIT mode.

Dutter, DingTalk's cross‑4+ platform framework built on Flutter, aims for native‑like performance, but the multi‑engine overhead has become a critical obstacle.

2 Performance Gains

We adopted the Flutter 2.0 LightweightEngine (EngineGroup) on desktop. After refactoring, the first‑frame time dropped from ~1.23 s to 0.45 s (≈‑63 %) and memory per engine fell from 70 MB to about 300 KB (≈‑50 %). In a demo opening eight windows, start‑up time fell from 0.67 s to 0.15 s (‑77 %) and memory usage decreased by ~65 %.

2.1 In‑App Results

Using the “Schedule Sign‑in” feature, the shared‑engine mode reduced memory and start‑up latency as shown in the table above.

2.2 Demo Results

A standalone demo confirms the same improvements when eight windows are opened simultaneously.

3 Early Exploration

Before selecting LightweightEngine we tried three alternatives:

Option 1: Replace Flutter‑Channel with FFI to speed up data transfer. Gained 5‑10 % first‑frame improvement but introduced heavy development constraints; abandoned.

Option 2: Build an engine pool with pre‑warming and keep‑alive. Improved load performance but increased memory dramatically; unsuitable as a general solution.

Option 3: Align desktop with LightweightEngine. A rough POC showed large gains in Windows JIT mode and lower memory, leading us to adopt this direction.

4 Solution Analysis

LightweightEngine provides a FlutterEngineGroup that shares resources such as threads, Skia contexts, graphics contexts, image caches, isolate groups, and fonts. The desktop implementation must adapt this mobile‑side design.

4.1 Mobile Implementation

The core idea is resource sharing within EngineGroup. Official documentation lists the shared items.

4.2 Desktop Alignment Cost

Flutter does not yet support EngineGroup on desktop; the issue is tracked on GitHub. Since the upstream roadmap does not prioritize it, we decided to implement it ourselves after feasibility verification.

5 Detailed Design

5.1 Overall Structure

Desktop adds an Embedder layer above the Shell, increasing complexity. We mapped the resource sharing relationships and identified the modules that need modification: EmbedderThreadHost, Setting, FlutterEngineProcTable, EGLContext/Display, TaskRunner, and Platform/Embedder interfaces.

5.2 Three Major Challenges

5.2.1 GPU Context Sharing

Windows uses Angle to wrap DirectX as OpenGL. We introduced AngleEGLContext to let multiple AngleSurfaceManagers share a single GPU context, ensuring proper lifecycle management.

5.2.2 Skia Context Sharing

We added SetSkiaContext/GetSkiaContext callbacks in FlutterOpenGLRendererConfig, extended EmbedderSurfaceGL to create or retrieve a shared Skia context, and ensured AngleEGLContext holds a pointer to the Skia context for coordinated destruction.

5.2.3 ThreadHost Sharing

ThreadHost is split into EmbedderThreadHost and TaskRunnerWin32 on desktop. We wrapped TaskRunnerWin32 with TaskRunnerWin32Wrapper that holds references to all engines in the group, allowing any engine to execute tasks, and cleaned up when the group is destroyed.

6 Conclusion

We have completed most of the EngineGroup integration for DingTalk Windows x64, achieving significant start‑up speed and memory reductions. The solution will be rolled out gradually and we plan to contribute the changes upstream with the Hummer team to benefit the broader Flutter ecosystem.