跨端动态化技术知多少

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

技术路线一、自渲染

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描述生产真正的 Flutter
控件。一句话介绍MXFlutter，就是用JavaScript，以Flutter的写法开发Flutter。

转自：https://zhaoshuming.github.io/2020/10/13/flutter-dynamic/

Flutter之上套json

Fair（58同城）

json生成界面实现逻辑方面弱
优点：界面编写较为简单、该库刚开源更新频率较高
缺点：定义逻辑方面弱

见：https://juejin.cn/post/6896655572910014478

某电商公司

json生成界面实现逻辑方面较弱

优点：可以直接使用已经定义好常用的小部件生成JSON 开发成本低该库持续更新了两年目前依然在持续更新逻辑方面有定义了一些事件比FAIR强点
缺点：定义逻辑方面没有MXFlutter那么灵活

见：https://github.com/dengyin2000/dynamic_widget

基于OS做自渲染，上层套JS

华为仿照Flutter之上套JS的技术路线，在OS层做了类似的事情：
https://mp.weixin.qq.com/s/K-lY7coYwKRVOuKup7ALKA

google的fuchsia的操作系统上，内置了flutter，相当于操作系统层集成了跨端方案
https://fuchsia-china.com/fimage-flutter-support-guide/

技术路线二、DSL来渲染布局，聚焦卡片场景

Plaster（知乎）

1、它可以简单开发测试后上线，不用跟随版本迭代；2、其性能良好，可以放在首页运行；3、可以和已开发的native卡片出现在一个页面。于是Plaster应运而生，Plaster是面向运营和产品的方案，它的动态能力体现在通过新增或修改样式Xml和后台数据，即可达到动态调整页面布局的目的，无须做客户端代码的任何改动

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

tangram（阿里天猫）

对于上述问题，解决思路其实是比较通用的，要动态更新界面视图，就需要用界面模板描述视图，模板与数据分离。将动态下发的模板和数据在端上绑定渲染。要提升性能，也有三大着力点——减少视图层级与个数，结构尽量扁平化；异步布局渲染流程，解放主线程计算量；回收与复用组件，减少内存开销。

新的组件体系就是在模板化描述视图，动态更新视图，减少视图层级几个方面做文章，至于组件的回收复用，则是在页面级别统一完成；而异步布局渲染流程，则是后续的优化方向。

转自：http://pingguohe.net/2017/12/07/Tangram-2.html

Morph （知乎）

综上考虑，最终我们决定采用基于 Flexbox 的 DSL Native+ 动态化方案即 Morph。Morph 方案在业务上具有如下优势：

和现有技术栈完美融合。知乎 App 信息流基于 ComponentKit 实现的，几乎几乎不会产生额外的学习成本；
快速上线，后期维护成本较低：整体方案的上手难度低，不需要学习新的技术，能够快速进行功能迭代开发；对包体积影响小：整个方案只是增加了
Google-FlexboxLayout、Yoga 两个轻量级开源布局框架，对体积影响可以忽略不计；
这个方案还带来了一个额外的好处：支持现有实验系统，很好的满足样式实验、数据采集的需求。

转自：https://www.infoq.cn/article/rrvp-kli8awex6tub1ag

MTFlexbox（美团）

MTFlexbox是美团内部应用的非常成熟的一种跨平台动态化解决方案，它遵循了CSS3中提出的Flexbox规范来抹平多平台的差异。MTFlexbox适用于重展示、轻交互的业务场景，与现有HTML、React
Native、Weex等跨平台方案相比，MTFlexbox具备着性能高、渲染速度快、兼容性高、原生功能支持度高等优势。但其缺点在于不支持复杂的交互逻辑，不适合复杂交互的业务场景。目前，MTFlexbox已经广泛应用在美团首页、搜索、外卖等重要业务场景。本文主要介绍在MTFlexbox中使用Litho优化性能的实践经验。

转自：https://tech.meituan.com/2019/09/19/litho-practice-in-dynamic-program-mtflexbox.html

技术路线三、类RN方案

Weex（阿里）

为什么移动端要强调动态化的能力？

原因有如下三大点：

  业务迭代太快。当下大部分团队都是敏捷开发的模式，即使两周做一次迭代，产品周期还是会觉得长，有些应用不能及时上线。应用市场审核慢。安卓基本当天发应用市场，当天就能够有更新。但 iOS 需要约 3-4 天来审核。假设有些功能需要定时上线，iOS 审核时间必须要考虑进去。用户升级周期长。统计表明，每一个安卓版本发布，一周内会有 70% 的用户更新，一个月其余用户才能陆续完成更新。

移动动态化方案共性，有如下三点：

跨平台。
布局。约定 DSL，保证渲染性能。
逻辑。Android 和 iOS 必须共用解释器。

转自：https://blog.51cto.com/wangxy/1957349

rax(阿里)

阿里先出了weex，但weex最早只支持vue前端框架，而阿里这么大一家公司，react的使用方也是众多的，这给支持react前端框架的动态化技术出现埋下了种子。

见：https://www.zhihu.com/question/54738521

Muise(阿里)

阿里内部研发中。

AJX(高德)

高德内部研发中，高德动态化发展思路见：
https://blog.csdn.net/amap_tech/article/details/106132289

mpaas（阿里）

支付宝上，有更高一层的封装叫mpaas
见：https://toutiao.io/posts/7desqc/preview

Hippy（腾讯）

hippy发起的背景是facebook收紧reactnative专利时，hippy同时支持react和vue两套前端框架，性能上做了大量优化。

见：https://cn.hippyjs.org/#/

VideoNative（腾讯）

相对于RN，将CSS、JS的解析处理逻辑，也转了C++实现以获得更高的性能。
见：https://videonative.github.io/

Lynx(字节)

lynx的原理简单说是实现了一个简版的浏览器内核，支持的浏览器标签很有限，聚焦提供比web更高性能的动态化技术。

见：
Git地址：https://github.com/hxxft/lynx-native
文档地址：https://hxxft.github.io/lynx-book/
一篇介绍：https://tzxhy.github.io/2020/02/19/%E5%85%B3%E4%BA%8E%E8%B7%A8%E7%AB%AF%E6%96%B9%E6%A1%88%E7%9A%84%E8%B0%83%E7%A0%94/

hummer(滴滴)

hummer最初采用单线程架构，特定场景跟手上可以做到更优。
见：https://hummer.didi.cn/doc#/zh-CN/

crn(携程)

随着业务使用的复杂度增加，各种问题随之而来，我们就这些问题一一提供解决方案，并建设相关配套系统来支撑业务开发团队使用。本文将从携程内部对
RN（ReactNative 简称，下同）的性能稳定性优化以及相关基础设施的建设来做分享。

见：
https://github.com/ctripcorp/CRN
https://www.infoq.cn/article/21lukw2txmehtxz69ktu

mrn(美团)

美团比较务实，初期基本不动react native内部，重点做落地相关的基建等建设工作。

见：https://tech.meituan.com/2019/12/19/meituan-mrn-practice.html

taro(京东)

Taro 是一个开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发微信 / 京东 / 百度 / 支付宝 /
字节跳动 / QQ 小程序 / H5 / RN 等应用。

现如今市面上端的形态多种多样，Web、React
Native、微信小程序等各种端大行其道。当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高，这时候只编写一套代码就能够适配到多端的能力就显得极为需要。

Taro 3 可以支持转换到 H5、ReactNative 以及任意小程序平台

见：https://docs.taro.zone/docs/README

技术路线四、类小程序的路线

类小程序技术，在技术原理上渲染往往基于web内核来做，重点改动的是上层标签支持范围、CSS支持集合、线程模型等。

微信小程序（腾讯）

相对于web内核，其限制了标签和css支持范围，引入了双线程模型以获取更高的性能，并限制对dom的使用以提升安全性。

见：https://zhaomenghuan.js.org/blog/wechat-miniprogram-principle-analysis.html

mpvue(美团)

见：
https://techsummit.ctrip.com/2018/pdf/huchengquan.pdf
http://mpvue.com/

技术路线五、RN

截至目前，RN仍然是除了Web之外，接入的App个数最广的动态化技术。

RN使用范围广，大家发现的问题也多。另外，一些非RN方案与RN方案的性能对比，对比的场景也往往是线下测试且精挑细选，这点需要明智的您擦亮眼睛。

见：https://gitbook.cn/gitchat/column/5aa8a68b0bb9e857450e2308/topic/5aa8c1500bb9e857450e2987

技术路线六、热更新方案

DynamicCocoa（滴滴）

DynamicCocoa的重点是动态化能力，优势在于完全不用写JS和更多的语法特性支持；对于HotPatch来说JSPatch是更加小巧、轻量的解决方案

见：http://www.cocoachina.com/articles/18400

JSPatch

见：https://jspatch.com/Docs/intro
实现原理见：https://blog.cnbang.net/tech/2808/

技术路线七、Web

这篇文章用假设的方式，描述了Web从Native一路演进出动态化的发展路径，比较有意思：

http://www.ayqy.net/blog/%E5%81%87%E5%A6%82web%E5%BD%93%E5%88%9D%E4%B8%8D%E6%94%AF%E6%8C%81%E5%8A%A8%E6%80%81%E5%8C%96/

路线之争

动态化方案，虽然由于种种原因成为了现在这个阶段中比较流行的方案，但是，动态化方案仍有很多没有解决的弊端，待我们去解决。而且，在我们解决的过程中，也会不断涌现其他各种方案。

总之，动态化方案的出现，不是为了替代谁，更多是为了给用户更好的体验，同时让业务可以更快的迭代，并在不断的尝试中，给用户带来更好的产品。

转自：http://www.e-lim.cn/20180805/

附录：

重要的圈子
公众号 U4内核技术
React Native Blog https://andrei-calazans.com/tags/react-native
美团动态化专栏 https://tech.meituan.com/tags/%E5%8A%A8%E6%80%81%E5%8C%96.html
携程技术专栏 https://www.zhihu.com/org/xi-cheng-ji-shu-zhong-xin/posts?page=2
腾讯hippy ChangeLog https://github.com/Tencent/Hippy/wiki/Hippy-v2.x-ChangeLog
淘系前端团队专栏https://fed.taobao.org/blogs/categories/%E6%97%A0%E7%BA%BF%E5%BC%80%E5%8F%91?spm=taofed.homepage.category-list.3.7eab5ac8dBy6d1