Taro架构构析(2)：Taro 设计思想及架构

从之前微信公众号的开发经验来说，以及腾讯开放平台的接入等经验来看，一直对腾讯的开放文档有心理阴影。

微信小程序从文件组织上看，一个小程序页面或组件，需要同时包含 4 个文件：脚本逻辑、样式、模板以及配置文件（page.js、page.wxss、page.wxml 、page.json），在开发一个功能模块时，就需要在 4 个文件之间切换，而当功能模块多的话，就需要在多个文件之间切换，这样显然非常浪费时间。

从开发方式上看，在前端工程化思想深入人心的今天，小程序的种种开发方式显得有些落后了，主要体现在以下几个方面：

没有自定义文件预处理，无法直接使用 Sass、Less 以及较新的 ES.Next 语法；
字符串模板太过孱弱，小程序的字符串模板仿的是 Vue，但是没有提供 Vue 那么多的语法糖，当实现一些比较复杂的处理时，写起来就非常麻烦，虽然提供了 wxs 作为补充，但是使用体验还是非常糟糕；
缺乏测试套件，无法编写测试代码来保证项目质量，也就不能进行持续集成，自动化打包。

所以，从开发方式上看，小程序开发没有融入目前主流的工程化开发思想，很多业界开发模式与工具没有在小程序开发中得到相应体现，像是从前端工业时代回退到了刀耕火种的年代。

最后，从代码规范上看，小程序的规范有很多不统一的地方，例如内置组件的属性名，有时候是全小写，有时候是 CamelCase 格式，有时候又是中划线分割的形式，这样就导致编码的时候得不时查阅文档才能确定写法。

探索多端可能性

多端统一开发一直是所有开发人员的共同追求。在终端碎片化的大背景下，前有 Hybrid 模式拉开序幕，后有 React Native、Weex 风起云涌，再到如今 Flutter 横空出世，种种这些都是为了能够 Write once, run anywhere 。给每一种终端单独进行开发的成本是昂贵的，所以一个能够尽可能抹平多端开发差异的开发解决方案就显得极为重要。

多端转换原理

开发时我们遵循 React 语法标准，结合编译原理的思想，对代码文件进行一系列转换操作，最终获得可以在小程序运行的代码。而 React 最开始就是为了解决 Web 开发而生的，所以对代码稍加改动，也可以直接生成在 Web 端运行的代码，而同属 React 语法体系下的 React Native，也能够很便捷地提供支持。同理其他平台，如快应用、百度小程序等，将源码进行编译转换操作，也能获得该平台下的对应语法代码。

抹平多端差异

基于编译原理，我们已经可以将 Taro 源码编译成不同端上可以运行的代码了，但是这对于实现多端开发还是远远不够。因为不同的平台都有自己的特性，每一个平台都不尽相同，这些差异主要体现在不同的组件标准与不同的 API 标准以及不同的运行机制上。

小程序和 Web 端上组件标准与 API 标准有很大差异，这些差异仅仅通过代码编译手段是无法抹平的，例如你不能直接在编译时将小程序的 <view /> 直接编译成 <div />，因为他们虽然看上去有些类似，但是他们的组件属性有很大不同的，仅仅依靠代码编译，无法做到一致，同理，众多 API也面临一样的情况。针对这样的情况，Taro 采用了定制一套运行时标准来抹平不同平台之间的差异。

这一套标准主要以三个部分组成，包括标准运行时框架、标准基础组件库、标准端能力 API，其中运行时框架和 API 对应 @taro/taro，组件库对应 @tarojs/components，通过在不同端实现这些标准，从而达到去差异化的目的。

参考内容：

为何我们要用 React 来写小程序 - Taro 诞生记 https://aotu.io/notes/2018/06/25/the-birth-of-taro/index.html

转载本站文章《Taro架构构析(2)：Taro 设计思想及架构》,
请注明出处：https://www.zhoulujun.cn/html/webfront/AppDev/taro/8497.html