一篇文章理解 Taro1/3原理

最近在进行 Taro项目的升级，由 Taro1升级到 Taro3，但是细想一下一直都是在使用 Taro，却没有进行深入的了解，本篇文章就深入解析下

什么是 Taro? 为什么要用 Taro

在使用任何一种技术之前，都要了解这两个问题：是什么？为什么要用？
Taro是一个开放式跨端跨框架的解决方案，支持使用 React/Vue/Nerv等框架开发微信 / 京东 / 百度 / 支付宝 / 字节跳动 / QQ / 飞书小程序 / H5 / RN 等应用。 这么说可能不容易理解，简单来说就是代码一次编写，多端使用。现在市面上的小程序种类特别多，包括最火的微信小程序在内还有支付宝小程序、百度小程序、字节跳动等等，还有一些H5、RN等等应用，如果你的项目要在多端上线就不得不编写多套代码，Taro就是为此而生，使用 Taro编写一套代码就可以在多端使用，大大减少了成本。

## Taro的设计思路为了更好的理解 Taro，原理这部分我的思路是先剖析 Taro1，再以对比的方式剖析 Taro3相比于 Taro1做了哪些改动和升级。使用 Taro1上手非常容易，可以说是只要掌握了 React 那就几乎掌握了 Taro，Taro和 React一样，使用声明式的 JSX语法，并且 Taro组件的生命周期和 React完全一致

第一个问题来了：为什么 Taro要采用 React的语法？
按照 Taro团队的说法，之所以选择 React要从设计 Taro的初衷说起，Taro团队认为 Taro框架应该是这样的：

代码多端复用
完善且强大的组件机制
学习成本低
背后生态强大

经过调研后Taro团队认为 React最符合要求，但是对于微信小程序而言，Raact完全没办法进行开发，那么第二个问题来了

如何完成React代码在小程序端的适配？
在讲解这一点之前需要理解几个概念：

Babel： Babel是一款JS代码编译器，举例来说，一些 JS的高级语法，比如 ES6，有些浏览器是不支持的，但是在开发中我们又想去使用这些语法，这时就可以利用 Babel将ES6代码编译成浏览器可以运行的代码，这个代码转换的过程也就是计算机基础中的编译原理的过程：输入源代码 => 词法分析 => 语法分析 => 语义分析 => 转换 => 新代码生成
抽象语法树(AST)： 什么是抽象语法树，网络上的解释过于笼统，按照我的理解，抽象语法树就是将编程语言的特定语法从源代码中剥离，仅仅关注源代码的结构和语意，这很重要。可以通过下面的截图感受下什么是 AST

了解上面的概念之后，上面的问题就有了思路：可以将React代码分析成抽象语法树，根据语法树小程序支持的模板代码，再做一个小程序运行时框架处理事件和生命周期与小程序框架兼容，然后把业务代码跑在运行时框架就完成了小程序端的适配

编译时使用babel-parser将react代码转换为抽象语法树，然后通过babel-types对抽象语法树进行修改，最后通过babel-generator将修改后的抽象语法树转换为小程序代码。这样的实现有以下几个缺点：

1· jsx支持程度不完美，Taro对jsx的适配是在编译时去实现的，但是jsx非常灵活，因此不能做到 100%的适配，Taro团队采用穷举的方式对jsx可能的写法进行一一适配，工作量巨大
2 不支持 source-map，Taro对源代码进行一系列的转换操作之后就不支持 source-map，用户调试很不方便

以上仅仅是设计思路，可以实现，但是还是有问题，仅仅将代码按照对应的语法规则转换，远远不够，因为不同的端会有自己的原生组件，端能力 api等等，代码转换过去可能不能直接执行。例如小程序中的普通容器是而 H5是

;小程序中提供了丰富的端能力 api，比如网络请求、文件下载、数据缓存等等，而在h5中对应的功能 api则不一致，那么第三个问题来了

怎么弥补不同端的差异？
Taro的做法是定制一个统一的组件库标准，以及统一的 api标准，在不同的端依靠他们的语法和能力去实现这个组件库与api，同时还要为不同的端编写运行时框架。在书写代码的时候，只需要引入标准组件库 @tarojs/components 与运行时框架 @tarojs/taro ，代码经过编译之后，会变成对应端所需要的库。举个例子，在小程序端，Taro实现了 @tarojs/redux 这个库来作为小程序的 Redux 辅助库，并且以他作为基准库，它具有和 react-redux 一致的 API，在书写代码的时候，引用的都是 @tarojs/redux ，经过编译后，在 H5 端会替换成 nerv-redux（Nerv的 Redux 辅助库），在 RN 端会替换成 react-redux。这样就实现了 Redux 在 Taro 中的多端支持。

Taro1 与 Taro3

看完上面的内容相信你已经对 Taro有了一个初步的认知，从 Taro1 到 Taro3中间的数次迭代和更新此处不细说了，接下来着重解析这两个版本进行对比。
Taro1 与 Taro3的架构区别
Taro 1/2 属于编译型架构，主要通过对类 React 代码进行语法编译转换地方式，得到各个端可以运行的代码，再配合非常轻量的运行时适配，以及根据标准组件库、API 进行差异抹平，从而实现多端适配的目的，整体架构如下。

Taro3可以大致理解为解释型架构，这个工作就主要是在运行时"对代码进行解释"，怎么理解呢？升级为Taro后你可以发现package.json文件里面多了个（当然不止这一个）@taro/runtime的依赖，Taro3自己实现了一套类似浏览器的BOM/DOM那一套API，通过webpack的plugin注入到小程序的逻辑层，打包编译后，你最终的代码都是基于BOM/DOM这几个API来实现你的具体功能，比如：不管什么平台，都有自己一套元素dom的规则，都有各自平台的类似bom的全局api规则，Taro3做的就是整合这些厂家的规则封装为类似BOM/DOM的思想去用，也就是说，我不管你开发时用的什么框架，我只要保证你运行时能帮你适配到各个平台即可。

这样做的最直观的好处就是前面说到的，不再受限制与框架本身了，理论上来说，Taro不仅可以支持Vue和React，也能用jquery、Angular等等的库进行跨端开发。站在React的使用者角度：通过taro2和taro3两个项目开发经验来说还有一点最直观的感受，taro3中写JSX更加舒服了！其实就更加友好的支持JSX这一点，应该是顺理成章的，因为taro的架构其实就是无限接近于React的开发体验，适配的工作是通过运行时的BOM/DOM去完成的，而不是像之前版本一样，通过穷举的方式对 JSX 的写法进行适配。