1 引言

在我们之前分享的《Dutter | 钉钉 Flutter 跨四端方案设计与技术实践》《Dutter | 前车之鉴：聊聊钉钉 Flutter 落地桌面端踩过的“坑”》文章中，有为大家简单介绍过钉钉 Flutter 桌面端应用的一些情况。在文章中我们有提到，因为需要支持多窗口、窗口内嵌等场景，在桌面端我们无法使用 FlutterBoost 一类的中间件来共享 FlutterEngine，只能采用多引擎方案来驱动多画布同时渲染。

此方案虽然能满足现阶段钉钉业务使用，但未来随着业务盖度、复杂度的提升，方案的弊端也愈加明显：引擎启动偶现卡顿、首帧耗时略长、内存占用高等。尤其是钉钉 Windows 端因为32位兼容问题，目前仍以 JIT 模式在运行 Flutter 页面，情况相比 AOT 模式更加差一些。以钉钉 Windows 目前线上业务为例，若不做任何优化，启动首帧展示耗时大概在 1000ms~2600ms 之间，每个引擎内存占用大概在 70MB 左右。

我们选择基于 Flutter 来构建钉钉跨4+端研发框架（Dutter） 的主要初衷即看中其在性能和体验上具备可媲美 Native 运行的能力，在完成前期基础设施搭建和核心链路验证之后，多引擎下的性能问题已成为阻碍我们达成既定目标的主要障碍，需要攻坚解决掉。

本文主要为大家介绍一下我们在此问题上探索方向以及最终方案，并以实际应用收益来为做一个直观展示，希望能为关注此领域的同学和团队提供一定参考。

2 性能收益

最终我们选择的优化方向，是将 Flutter 在移动端已经支持的 LightweightEngine 方案在桌面端应用起来。经过一段时间的攻坚改造，我们目前完全基本开发验证工作，后续准备开始内部灰度。

下面通过钉钉 App 内以及独立 Demo 来分别展示下优化收益。

2.1 钉钉内表现

在钉钉内，我们以「日程签到」的表现来展示一下优化收益：

表格视频

注：素材较老，共享引擎花屏的问题已处理

2.2 Demo 表现

为了排除业务数据影响的情况，更好的展示优化效果，我们以独立 Demo 的方式也做了一个对比测试，测试会连续打开8个窗口，观察在不同模式下的表现：

3 前期探索

在选择桌面端对齐 LightweightEngine 方案之前，我们在钉钉内部也有尝试过一些优化方案，寄希望于通过上层优化来改善桌面端（主要是 Windows）性能问题。我们尝试过的方案有：

• 探索方案1：使用 FFI 替换 Channel，提升数据通讯效率。

  基于此方案来改造 Dutter 现有核心流程，确实可以取到一定收益。经过实验室测试，首帧加载速度大致可以提升 5%~10% 之间。

  但是此方案的弊端也很明显：收益有限但对开发限制过大，改造 ROI 太低，最终并未在 Dutter 内落地。

• 探索方案2：构建"引擎池"，利用池化技术改善加载性能。

  池化技术有比较多的成功案例，且此方案对 Dutter 框架部分影响很小，通过对引擎的预热+保活，可以大大的改善业务加载性能。

  但此毕竟是一个「内存换时间」的折中方案，虽然性能达标了，但是内存开销上会大大提升，因此只能作为特定业务场景下的优化手段，不可作为通用方案推广。

• 探索方案3：在桌面端对齐 LightweightEngine。

  LightweightEngine 是 Flutter 2.0 推出的重磅功能，对外提供的能力叫做 FlutterEngineGroup。其在内部通过引擎间资源共享来降低派生引擎的资源开销、提升派生引擎的启动性能，这一点与钉钉诉求是高度结合的。

  但因为 Flutter 移动端和桌面端引擎架构有一定的差异，如果我们自己来实现此功能，若无法提交到官方，为了会带来一些引擎维护成本，故最初并未将此方案作为首选方案。

  在一次偶然机会上，我们通过较低成本实现一个比较粗糙的 POC，发现基于此方案可以极大提升 Windows 端 JIT 模式下的启动性能、大大降低内存开销，相比 Mac 端 AOT 模式的收益更大。故在方案1和方案2收益不佳之后，我们选定 LightweightEngine 作为我们下一步性能优化的主攻方向。

4 方案分析

前面也有提到，LightweightEngine 是 Flutter 2.0 推出的重磅功能，对外提供的能力叫做 FlutterEngineGroup。如果我们要将其迁移到桌面端，必然需要先梳理清楚其移动端实现方案，然后再结合桌面端引擎架构做改造实现，故在本小节我们先对 LightweightEngine 的实现方案做一下简单分析。

4.1 移动端实现

详细方案可以参考官方文档：http://flutter.dev/go/multiple-engines，下面梳理一下上述文档重点内容。

此方案的核心思想在于「资源共享」，在 EngineGroup 内的实例会共享一下内容：

1. Threads;
2. Skia Contexts;
3. Graphics Contexts;
4. Image Caches;
5. Isolate Groups;
6. Fonts;

从上述列表我们可以看到，正式借助于将高开销的资源做共享，EngineGroup 内的引擎可以以更快的速度、更低的成本创建出来。

结合类的关系图，我们可以更直观的看下具体共享了哪些内容：

更详细的内容就不展开了，大家感兴趣的话可以查阅官方的设计文档。

4.2 桌面对齐成本

优先我们还是希望官方能将此功能补齐，但比较遗憾的是此需求目前在官方排期中优先级不高，短期也没落地计划【ISSUE】https://github.com/flutter/flutter/issues/95076：

既然官方短期无法支持、我们又有比较强的诉求，那就只能撸起袖子自己干了！不过为了避免「水太深」，出现一脚踏进去爬不出来的情况，在开工之前我们还是通过对引擎架构分析以及 POC 的方式对可行性做了一次验证。

此前，我们有对 Flutter 移动端和桌面端引擎架构做过简单对比：

从上图我们可以看到：

• 在 Shell 层以下部分，移动端和桌面端部分实现是共享的，这部分是平台无关的内容；
• 在 Shell 层以上部分，桌面端相比移动端主要增加一部分「桌面平台无关的」Embedder 层，这部分对 Shell 做了更进一步的封装，以降低桌面端接入成本；

基于以上分析我们可知：

1. Shell 层的改造和实现，桌面端可以直接共享 LightweightEngine 移动端的实现，仅需少量适配即可；
2. 对于 Shell 之上部分的改造，桌面端改造的重点在于两方面：
• 改造 Embedder 层接口以及实现以配合 LightweightEngine 资源生命周期管理；
• 配合平台层具体实现，封装暴露接口以及共享资源桥接；

并且在对移动端 LightweightEngine 方案学习之后，我们判定 Shell 以下部分的实现是整个方案的核心以及难点部分；Shell 以上部分的改造挑战虽然有，但仍在可控范围内，并且也不会与官方演进方向发生分化，具备继续推进落地的可行性。

5 方案详解

虽然可以有移动端成功案例做参考和对齐，但是因为 Flutter 自身在上层架构上移动端和桌面端存在较大差异，我们在实际落地过程中仍处理了一系列比较有挑战性的，下面为大家做一下介绍。

5.1 总体结构

从前文分析可知，LightweightEngine 实现核心在于「资源共享」，桌面端对齐又尤以 Shell 层以上部分为主。FlutterEngine 移动端和桌面端核心类图：

从上图我们可以看到，桌面端 Shell 以上部分设计相比移动端更下复杂，在移动端由同一个 Class 实现的部分被拆分为两部分。以 Surface 为例，在 iOS 端只需要一个IOSSurface 类族来实现即可；但是在桌面端被拆分为跨平台层的 EmbedderSurface 以及平台层的FlutterRender 两部分。并且桌面在进入真实渲染流程时，其对渲染 Context 的操作还需要收到 Flutter Resize 模块控制，总的来说桌面端实现复杂度相比移动端要更高一些。

在梳理完桌面端相关模块之后，参考移动端方案，我们整理出桌面端在 LightweightEngine 模式下相关资源模块的共享关系图：

将此图与移动端类图做对比我们可以看到：

• 在移动端引擎是 Shell + Platform 的两层架构，EngineGroup 下共享资源大部分在 Shell 层，上层只有 ThreadHost 需要共享；
• 桌面端引擎架构在 Shell 和 Platform 中间多了一层跨平台的 Embedder，虽然 Embedder 的设计是为了降低 Platform 层的实现复杂度。但在桌面端实际发展过程中，随着功能复杂度越来越高，Embedder 的存在虽然使 Platform 层功能开发工作量降低、但是增加了配置与交互的复杂度。因此在实现 LightweightEngine 的功能时，我们需要在 Platform 和 Embedder 层同时做改造，具体内容包含：
• EmbedderThreadHost：引擎线层管理控制器，对等移动端 TheadHost，需要配合平台层 TaskRunner 使用；
• Setting：Embedder 层配置服务模块，Platform 层对 Shell 层引擎的设置和注入，都需要通过 Setting 来承载；
• FlutterEngineProcTable：负责与 Embedder 层函数地址绑定；
• EGLContext&Display: 控制平台层渲染上下文，根据平台分别对应 OpenGL、Metal、D3D等；
• TaskRunner: 平台层实现的 Runner，负责与当前平台线程交互，与 EmbedderThreadHost 配合；
• Platform 层：
• Embedder 层：

支持我们即基本梳理出桌面端支持 LightweightEngine 总体改造方案以及改造范围，但产出方案仅是万里长征第一步，从方案设计到落地存在不少要处理的问题。

下面我们以 Windows 端实现为例，为大家介绍一下我们在方案落地过程中翻越的"三座大山"：

1. GPU Context 共享；
2. Skia Context 共享；
3. ThreadHost 共享；

5.2 三座大山

5.2.1 GPU Context 共享

在 Windows 端 Flutter 支持两种渲染模式 CPU 渲染 以及 DirectX 渲染；其中为了降低上层实现复杂度以及接入成本，在 Windows 端 Flutter 使用 Angle 库将 DirectX 接口封装为 OpenGL 接口，上层实现可与其它端实现共享。OpenGL 适用范围最广，我们即以 OpenGL 的实现来做一下说明。

GPU Context 共享是 LightweightEngine 实现中的核心部分，并且也是完成整个方案关键。并且在 DartVM 底层共享的情况下、不贡献 GPU Context 则会出现因资源访问冲突导致异常，无法正常渲染页面：

在 Windows 端 Platform 层实现中，GPU 相关资源由 AngleSurfaceManager 来管理，为了满足共享诉求，我们需要对 AngleSurefaceManager 做改造，将其内部需要负责上下文管理的部分定义为 AngleEGLContext，各 AngleSurfaceManager 共享 AngleEGLContext 以达到 GPU 资源共享的诉求：

在 EngineGroup 内的所有 FlutterEngine 实例释放之后，AngleEGLContext 方可进入销毁流程，并释放相关 GPU 资源。

5.2.2 Skia Context 共享

在处理完 OpenGL Context 之后，下一步我们要处理的即 Skia Context 问题。此处需要注意，如果 Skia 与 OpenGL 对应生命周期管理出现紊乱，则会出现诡异的渲染问题，例如：

Skia Context 共享的处理方式相比 GPU Context 更复杂一些：GPU Context 完全由上层管理，改造位置相对收敛；但是 Skia Context 与 Sureface 强绑定，由 Embedder 层负责创建，但是因为 FlutterEngine 相关生命周期最终由 Platform 层来控制，因此需要在 Embedder 暴露的 Open API 增加对 Skia Context 的存取接口。

最终核心改造内容包含：

1. SkiaContext 仅对 Embedder 层暴露；Platform 层使用封装类（屏蔽底层实现）持有相裸指针；
2. Embedder 新增暴露接口：
• FlutterOpenGLRendererConfig 新增  SetSkiaContext, GetSkiaContext 相关回调方法；
• 新增销毁 SkiaContext 相关方法；
3. EmbedderSurfaceGL 的 CreateGPUSurface 回调方法实现中，增加从 Platform 层 GetSkiaContext 相关逻辑；读取不到则创建、创建完成之后调用 SetSkiaContext 方法将 Context 传递到 Platform 层保存；
4. AngleEGLContext（钉钉新增）增加持有 SkiaContext（裸指针），并在 AngleEGLContext 销毁是调用 Embedder 提供的销毁 SkiaContext 方法来销毁对应实例；

改造之后的最终效果：GPU Context 与 Skia Context 一一对应，且生命周期基本对齐，至此渲染相关逻辑自洽且闭环。

5.2.3 ThreadHost 共享

在前面的分析中我们有介绍，在移动端由 FlutterEngine 持有的 ThreadHost，在桌面端被拆分为两部分：Embedder 层的 EmbedderThreadHost 以及 Platform 层的 TaskRnner。若实现 ThreadHost 共享，我们需要在 platform 以及 Embedder 层同时做改造。

在进入实际改造流程之前，我们首现需要梳理一下相关实现：

从上图可以大概梳理出相关 Class/Struct 之间的关系：默认情况下各对象是一对一的关系，并且底层与上层之间是通过 lambda 回调。在经过 LightWeightEngine 改造之后，Shell 层实例只会持有一份共享的 TaskRunners 以及 ThreadHost。

在 Windows 端中，Platform 层 TaskRunner 的具体实现类为 TaskRunnerWin32，其最主要的动作是在触发回调时，调用 Embedder 层接口，在与其绑定的 _engine 实例上执行相关 Task。

进一步查找底层 RunTask 的实现：

可以发现，最终是调用到 flutter::EmbedderThreadHost 的 PostTask 方法来执行 Task。并且我们从上文分析可知在底层 EngineGroup 内的 ThreadHost 是共享的，即调用 EngineGroup 内的任意一个引擎实例的 PostTask 方法都是合法且一致的。

故此即可得出我们改造处理方案：flutter::TaskRunnerWin32 做封装: TaskRunnerWin32Wrapper，在各个引擎直接贡共享封装之后的实例。在 TaskRunnerWin32Wrapper 内部会关联当前 EngineGroup 内的所有引擎实例，在需要执行回调时，选定任一可用实例来执行：

当所有绑定实例都销毁时，组内关联的 TaskRunnerWin32Wrapper 对象也会进入析构流程，至此即可完成 ThreadHost 部分资源的共享。

6 小结

目前钉钉侧已经完成 EngineGroup(LightweightEngine) 能力对接的绝大部分工作，完成冒烟测试之后，在实验室环境下跑出了很不错的成绩。在短期钉钉 Windows x64 版本无法长期铺开、业务启动性能要求高、内存压力大的情况下，EngineGroup 对我们来讲是一个极具吸引力的性能优化方案，后续会逐步在钉钉桌面端铺开。

后面我们会进一步与 Hummer 团队同学共建，争取能将相关改动贡献进 Hummer 主干，集大家力量来完善繁荣 Flutter 研发应用生态！