【跨端动态化技术知多少】

跨端动态化技术知多少

文章摘要：本文对业界跨端动态化技术做了一些归拢，方便志同道合的朋友一起学习交流、开拓视野。附录有收录一些技术专栏，感兴趣的朋友可以收藏。

技术路线一、自渲染

Flutter之上套JS

腾讯和字节的自渲染

2021年GMTC会议上，腾讯、字节都透露了在研究自渲染技术路线，都是基于Skia，仿照Flutter写C++版本的自渲染，替换hippy或者lynx的渲染层，思路大同小异。见：https://gmtc.infoq.cn/2021/beijing/track/1045

Aion（阿里UC）

接下来简单介绍一下行业在 Flutter 这块的一些动态化技术方案。第一套方案是 Web 跟 Flutter 的一个结合，就是前面说的利用
Web 生态 js 的高动态性跟 Flutter
本身的渲染流程去做结合，达到一个既能够满足高动态性，也能满足跨平台一致性以及高性能交互的体验。从结合的点来看，根据节点的选择不同又会细分为几套方案，这里不做展开。

然后说下我们对这个方向的思考，Flutter 的核心优势，来源于 Widget 设计、渲染流水线设计还有 Dart 极致的 AOT
优化，其中每一块都是作为生态的部分去优化演进的，其背后强大的开源生态为其不断技术升级提供了强力的支撑。所以我们的思路还是希望能够基于整个
Flutter 的原生态去解决动态化的问题，这样我们才能够最大化的利用整个 Flutter 生态的优势

第二套方案我把它简单概述成 Simple VM 的方案。整体的方案思路如图，第一块是 Dart 的原始代码，实现了 Widget
视图界面，经过前端的编译生成 AST 产物，然后在编译阶段将 AST 产物转化成 JSON 的数据描述，JSON 文件下发到客户端，在
Dart 层对它做一次解析，把 Widget 描述映射成对应的真实的 Widget，这样就构建了一颗完整的 Widget
树进行渲染，这个是视图层的处理，逻辑这一块会把 AST 里面逻辑去分离出来，然后通过在 dart 层实现简单解释器进行处理。

AST 其实属于一个相对高级的编译产物，基于 AST 的解释执行在语法层面会有比较大的限制，很难做到跟 Flutter
的原生态做一个完美的兼容。所以我们评估这套方案在支持非常复杂的业务场景时，会遇到比较大的瓶颈。当然除了这两个方案之外，其实还有其他的一些像双引擎的方案，这里不做展开

我们的整体技术方案其实是希望把业务的动态化代码能够去剥离出来，然后通过解释器的方式去执行，其它还是基于 AOT
模式运行，通过这种混合执行模式来达到动态化的目的。这里面的技术选型涉及到产物的选取问题。从整个编译链路来看，其实有三种选择，第一种是 AST
产物，这块在上面的介绍中其实已经被否定掉了。剩下还有两条路线可以选择，第一种是基于 Kernel 去解析，另外一种就是基于后端优化过之后的
IL 指令去解析。

基于 Kernel ByteCode
去解析是有完整的解释器支持的。但是它的缺点其实也很明显，它的整体性能因为没有经过后端更激进的编译优化，所以它的整个指令的执行性能会偏低一点。IL
这一块的缺点在于我们需要去进行完整的 IL 解释器开发。我们目前选择了第一种方案，这里面的一个核心技术判断是我们认为 CPU
密集型的计算，像排版渲染这块的执行其实都是在 AOT 中，业务代码其实对 CPU
的占用非常低，这样整个综合下来的性能，折损不会太严重，所以我们最终的方案其实是基于 Kernel ByteCode
作为动态化产物，结合解释器的模式去达到动态化的效果

转自：https://juejin.cn/post/6923060266003333133

MXFlutter（腾讯）

MXFlutter （Matrix Flutter）核心思路是把 Flutter 的渲染逻辑中的三棵树中的第一棵，放到 JavaScript
中生成。用 JavaScript 完整实现了 Flutter 控件层封装，可以使用 JavaScript，用极其类似 Dart
的开发方式，开发Flutter应用，利用JavaScript版的轻量级Flutter
Runtime，生成UI描述，传递给Dart层的UI引擎，UI引擎把UI描述生产真正的 Flutt