凹凸技术揭秘 · Taro · 从跨端到开放式跨端跨框架

Posted 2021-10-11 我啊我啊

承载 Web 的主战场转移—

2017 年 1 月 9 日凌晨，微信正式推出小程序，为移动端家族增加了新的业务形态和玩法，当大家还在探讨这一新兴平台能做什么的时候，京东率先上线了「京东购物」小程序，随后，更多的电商行业执牛耳者纷纷入驻小程序，从此，承载电商的主战场逐渐从需要自建流量的移动端 APP 向小程序倾斜。

小程序的出现，为电商行业的研发带来了巨大的挑战。继微信之后越来越多的头部流量互联网公司纷纷盯上小程序这一蛋糕，相继推出了各自的小程序平台，比如京东、阿里、百度、字节跳动、360 等等，为了让我们的电商业务能快速移植到这些小程序平台，帮助我们的业务快速拓展渠道，我们开始了新的尝试。

我们开始尝试使用技术的手段，探索一种能够统一所有平台的新技术。

披荆斩棘——初代架构诞生—

用 React 写小程序？

前面有提到，为了解决各大小程序平台带来的多端开发的痛点问题，社区先涌现出了 WePy[1] 和 mpvue[2]，那我们为什么不直接采用，而要选择“造轮子”呢？

在当时的前端界言及前端框架，必离不开依然保持着统治地位的 React[3] 与 Vue[4]，这两个都是非常优秀的前端 UI 框架，而且在网上也经常能看到两个框架的粉丝之间热情交流，碰撞出一些思想火花，让社区异常活跃。

而我们团队也在 2017 年勇敢地抛弃了历史包袱，非常荣幸的引入了 React 技术栈。这让我们团队丢掉了煤油灯，开始通上了电，远离了刀耕火种的前端开发方式。为了解决当时业务环境对极致性能以及低版本 IE 浏览器兼容性的要求，我们还研发出了一款优秀的类 React 框架 Nerv[5] ，并因此对 React 开发思想以及技术栈理解更加深刻。

遗憾的是，当时社区并没有一款使用 React 开发小程序的框架。

与小程序的开发方式相比，React 明显显得更加现代化、规范化，而且 React 天生组件化更适合我们的业务开发，JSX 也比字符串模板有更强的表现力。那时候我们开始思考，我们能不能用 React 来写小程序？[6]

理性地探索

通过对比体验 小程序和 React ，我们还是能发现两者之间相似的地方，比如生命周期、数据更新方式以及事件绑定，都具有非常多相似的地方，这为我们使用 React 来小程序提供了非常良好的基础。

但是，我们也应该看到小程序和 React 之间的巨大的差异，那就是模板。在 React 中，是使用 JSX 来作为组件的模板的，而小程序则与 Vue 一样，是使用字符串模板的。这是两种完全不一样的东西，也是我们方案探索上的巨大障碍。所以，为了实现使用 React 来写小程序这一目标，我们必须解决两者之间巨大差异的问题。

解决差异

既然微信不支持 JSX，那我们只需要将 JSX 编译成小程序模板不久可以在微信上运行了吗，这一步可以通过 Babel[7] 来实现。

Babel 作为一个 代码编译器 ，能够将 ES6/7/8 的代码编译成 ES5 的代码，其的编译过程主要包含三个阶段：

解析过程，在这个过程中进行词法、语法分析，以及语义分析，生成符合 ESTree 标准 [8] 虚拟语法树(AST)

转换过程，针对 AST 做出已定义好的操作， babel 的配置文件 .babelrc 中定义的 preset 、 plugin 就是在这一步中执行并改变 AST 的

生成过程，将前一步转换好的 AST 生成目标代码的字符串

再次回到我们的需求，将 JSX 编译成小程序模板，非常幸运的是 babel 的核心编译器 babylon 是支持对 JSX 语法的解析的，我们可以直接利用它来帮我们构造 AST，而我们需要专注的远程桌面核心就是如何对 AST 进行转换操作，得出我们需要的新 AST，再将新 AST 进行递归遍历，生成小程序的模板。

以上仅仅是我们转换规则的冰山一角，JSX 的写法极其灵活多变，我们只能通过穷举的方式，将常用的、React 官方推荐的写法作为转换规则加以支持。

初代架构诞生

经过我们一次次的探索，我们已经可以将类 React 代码转成可以在小程序环境运行的代码了。但是我们激动之余，冷静下来继续思考，我们还能不能干点别的有意思的事情呢。

我们发现，在平常的工作中，我们业务通常有一些“多端”的需求。就是同一个业务或页面，需要同时适配 小程序、H5 、甚至 React Native 。这个时候，你就会发现，差不多的界面和逻辑，你可能需要重复写上好几轮。

因此，我们希望希望在解决使用 React 开发微信小程序的同时，还能同时是适配到 H5 端、移动端、以及各平台的小程序。Write once, run anywhere，相信是所有工程师的梦想。

但是仔细思考我们又会发现，仅仅将代码按照对应语法规则转换过去后，还远远不够，因为不同端会有自己的原生组件，端能力 API 等等，代码直接转换过去后，并不能直接执行，还需要运行时的适配。因此，我们按照微信小程序的组件库与 API 的标准，在其他端（H5、RN）分别实现了组件库和 API 库。

Taro 从立项之初到架构稳定差不多用了三个月左右的时间，从最初的激烈讨论方案，各种思想的碰撞，到方案逐渐成型，进入火热的开发迭代，再到现在的多个平台小程序端、H5 端和 RN 端的顺利支持，Taro 的未来已来。

初露锋芒——GitHub 开源—

2018 年 6 月 7 日，多端统一开发框架 - Taro 正式开源。

作为首个支持以 React 语法写微信小程序并适配到多端的开发框架，Taro 一鸣惊人。开源不到两个月，在 GitHub 上有 6600 多个 Star，连续数周霸榜 Github Trending；同时已经处理近 300 个 Issue ，还有 100 多个在等待反馈与优化；在公司内、外主动反馈的使用 Taro 的项目已有十多个。

截至 2019 年 12 月 18 日，Taro 已拥有 22254 Stars 和 250 名 Contributors，社区主动提交的开发案例 150+：taro-user-cases[9]，其中不乏多端案例。