查看原文
其他

EngineGroup:让 Flutter 桌面端引擎“飘”起来

刘太举(驽良) 阿里巴巴终端技术 2022-10-21

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 钉钉内表现

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

表格视频

独立多引擎共享第一个引擎资源
内存开销
70MB*N
内存开销↓50.0% ~ +∞
首个引擎 70MB,其余约 300KB
启动耗时
1.23s
启动耗时(↓63.5%
0.45s

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

2.2 Demo 表现

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

独立多引擎共享第一个引擎资源
内存开销

内存开销(↓65.1%)

启动耗时
0.67s
启动耗时(↓77.2%
0.15s

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 需要共享;
  • 桌面端引擎架构在 ShellPlatform 中间多了一层跨平台的 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 相关方法;
  • EmbedderSurfaceGLCreateGPUSurface 回调方法实现中,增加从 Platform 层 GetSkiaContext 相关逻辑;读取不到则创建、创建完成之后调用 SetSkiaContext 方法将 Context 传递到 Platform 层保存;
  • 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 研发应用生态!






    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存