目前在小程序互动场景下遇到的业务痛点，并且给出了基于Flutter引擎的解法。基于Flutter引擎，对外提供标准的Web Canvas API和并利用flutter渲染管线，让业务代码在小程序worker线程中直接渲染，缩短了渲染链路，提高了渲染性能。本次分享将由淘宝技术部无线开发专家万红波为大家分享目前在小程序互动场景下遇到的业务痛点，以及基于Flutter引擎的解法。

演讲嘉宾简介：万红波，花名远湖，淘宝技术部无线开发专家。主要从事浏览器内核以及渲染引擎方向的研究。目前在AliFlutter团队主要负责底层引擎以及Canvaa相关研究于应用。

以下内容根据演讲视频以及PPT整理而成。
观看回放
本次分享主要围绕以下六个方面：

业务背景  
业务痛点  
解决方案  
技术改造  
业务效果  
未来规划  

一、业务背景

小程序作为一个商业化解决方案，这几年发展迅速，在头部APP中占据重要位置，与传统H5同，渲染和逻辑分离到各自独立线程，可以做到并行化。Worker和Render之间通过PostMessage或者SetData来通信。

二、业务痛点

小程序的架构可以满足大部分场景，但在互动场景下，业务通常使用Canvas API进行每帧的绘制，每一帧通常包含大量的绘制操作，worker和render之间通信频繁，渲染性能大幅度降低，用户体验较差。其中耗时较大的点在数据的多次序列化和反序列化且多次通过JNI来实现Java和C++的数据传递。在微信小程序和支付宝小程序文档中，提供了一些最佳实践来减低影响，比如PostMessage或者SetData的接口，一秒内调用不可超过20次，且对SetData的数据大小有所限制。但对于互动业务来说，要求每秒FPS的帧率，且每帧都需要大量的绘制指令需要传递，则很难通过这种方式解决。

三、解决方案

我们的解决方案是在小程序worker环境中直接对接渲染引擎，缩短渲染了链路，减少通信损耗，提高渲染性能。Worker中对接独立的2D渲染引擎，不再通过render和worker传递消息。而其他的页面，由于通信并不频繁，仍使用原来的链路渲染。

我们选择了Flutter引擎作为独立的渲染引擎。我们选择Flutter的原因：
1、跨平台的特性，客户端包含安卓和IOS，忽略客户端细节，仅完成渲染，而Flutter引擎可以很好的屏蔽客户端细节；
2、高性能，和传统的H5渲染引擎相比，是一个轻量型的多线程2D引擎；
3、Flutter内部使用Skia作为渲染引擎，其兼容性、性能和适配性已在生产环境中被多次检验，安全稳定。

Flutter渲染管线较短，平台层发出vsync信号，丢到Platform task，调用UI线程已注册的callback，即Animator的BeginFrame函数，其将调用window的BeginFrame函数，window对象在Flutter中较为特殊，其连接上层Framework和下层Flutter engine。图中绿色的区域即为Dart需要完成的事情，当BeginFrame进入Dart层之后，dart层调用Render的DrawFrame函数，做layout和paint，paint过程中图片相关的部分会传递给IO线程抑或请求图片解码，同时在GPU线程上传纹理。上述完成后，调用RenderFrame函数，实现上屏。其中Dart层的绘制指令被组织为Layer Tree这种数据结构，它后续被传递给GPU Task，GPU Task读取Layer Tree中的渲染指令，直接光栅化，之后上屏。RenderFrame做下一次的vsync请求

最终方案：面向业务，提供标准的Web Canvas API，业务感知不到下层引擎变化；通过业务容器引入JS引擎，并把C++实现的Canvas API通过binging方式，注入到小程序worker线程；引入Canvas渲染管线，和原生dart模式共存，提高性能和内存使用率，业务可灵活切换。

四、技术改造

方案对渲染流水线有较大的改造，原先platform线程接收到vsync之后，将其传递给UI线程，UI线程在Dart层做绘制操作。而改造后在小程序环境中，用JS逻辑代替Dart层，业务逻辑在worker线程中完成，vsync被传递给JS线程，JS线程收到vsync后，驱动业务执行JS代码，进行绘制并生成渲染指令生成后依然生成layer tree，传递给GPU线程，光栅化完成后上屏。

改造后的渲染管线，与改造前不同的是：platform线程收到vsync信号后，不再调用原先的callback，而是调用我们自己注册的自定义callback，即OnVsync，将Vsync传递给JS线程。JS线程主要执行requestAnimationFrame的callback，对屏幕进行绘制更新，JS线程执行完成后，调用FlushFrame，将layer tree传递给GPU线程，直接光栅化后上屏。绘制结束后，通过Animator的RequestFrame函数请求下一次vsync。

图片加载流程改造，原先的图片加载流程并不适用小程序环境下，JS线程中的资源请求被丢给平台的手淘图片库，完成图片的下载和解码，解码后的数据传递给IO线程。IO线程生成GPU纹理，并将其缓存在Flutter engine中。业务直接使用引擎中已经生成纹理的图片，可直接上屏。

五、业务效果

安卓低端机上，业务改造前FPS为15，改造后42，效果明显。FPS数据由于测试业务没有通过Vsync来驱动绘制，而是直接使用timer来驱动，使得CPU占用率较高，且改造后FPS提高很大。线下测试中，采用Vsync驱动绘制，改造后的FPS提高30%左右。

目前我们还支持Lottie动画，设计师可以通过Lottie动画设计画面效果。并且支持白鹭游戏引擎。

六、未来规划

未来规划有三个方向，首先接入更多三方游戏引擎，和三方游戏引擎深度合作，其次探索高阶渲染API的实现。支持WebGL API。第三探索独立小游戏容器，能够基于已完成的方案做更多的尝试。

关注「淘系技术」微信公众号，一个有温度有内容的技术社区~