关于javascript:跨端小程序框架-Taro演进

Hybrid App（混合模式挪动利用）是指介于 web-app、native-app 这两者之间的 app，兼具“Native App 良好用户交互体验的劣势”和“Web App 跨平台开发的劣势”。

客户端提供 webview 控件, 能在 App 内应用 H5 技术开发页面, 如果须要调用到零碎能力的性能须要客户端实现, 两者建设桥梁通信实现交互

具备残缺 webview 性能
可间接应用零碎原生性能
随时更新无需发版

性能差距显著
白屏工夫长, 用户体验差
零碎操作须要客户端原生反对提供办法
有时候受限客户端起因, 须要非凡兼容

「触手可及，用完即走」

小程序提供了本人的视图层描述语言 WXML 和 WXSS，以及基于 JavaScript 的逻辑层框架，并在视图层与逻辑层间提供了数据传输和事件零碎，让开发者可能专一于数据与逻辑。

框架的外围是一个响应的数据绑定零碎，能够让数据与视图非常简单地放弃同步。当做数据批改的时候，只须要在逻辑层批改数据，视图层就会做相应的更新。

小程序并非凭空冒出来的一个概念。当微信中的 WebView 逐步成为挪动 Web 的一个重要入口时，微信就有相干的 JS API 了。

2015 年初，微信公布了一整套网页开发工具包，称之为 JS-SDK，凋谢了 拍摄、录音、语音辨认、二维码、地图、领取、分享、卡券等 几十个 API。

JS-SDK 是对之前的 WeixinJSBridge 的一个包装，以及新能力的开释，并且由对内凋谢转为了对所有开发者凋谢，在很短的工夫内取得了极大的关注。从数据监控来看，绝大部分在微信内流传的挪动网页都应用到了相干的接口。

JS-SDK 解决了 挪动网页能力有余的问题 ，通过裸露微信的接口使得 Web 开发者可能领有更多的能力，然而在更多的能力之外，JS-SDK 的模式并 没有解决应用挪动网页遇到的体验不良的问题。

用户在拜访网页的时候，在浏览器开始显示之前都会有一个白屏的过程，在挪动端，受限于设施性能和网络速度，白屏会更加显著。因而设计了一个 JS-SDK 的加强版本，其中有一个重要的性能，称之为“微信 Web 资源离线存储”。

微信 Web 资源离线存储是面向 Web 开发者提供的基于微信内的 Web 减速计划。

通过应用微信离线存储，Web 开发者可借助微信提供的资源存储能力，间接从微信本地加载 Web 资源而不须要再从服务端拉取，从而缩小网页加载工夫，为微信用户提供更优质的网页浏览体验。每个公众号下所有 Web App 累计最多可缓存 5M 的资源。

在内部测试中，咱们发现离线存储可能解决一些问题，但对于一些简单的页面仍然会有白屏问题，例如页面加载了大量的 CSS 或者是 JavaScript 文件。除了白屏，影响 Web 体验的问题还有短少操作的反馈，次要体现在两个方面：页面切换的僵硬和点击的通畅感。

微信面临的问题是如何设计一个比拟好的零碎，使得所有开发者在微信中都能取得比拟好的体验。这个问题是之前的 JS-SDK 所解决不了的，须要一个全新的零碎来实现，它须要使得所有的开发者都能做到：

疾速的加载
更弱小的能力
原生的体验
易用且平安的微信数据凋谢
高效和简略的开发
无需装置

而毛病也很多:

组件较少
webview 限度很多, 一般页面开发区别很大
行为限度很多, 包体积大小, 资源应用, 页面关上层级等等
不同机型的兼容问题也是比拟多

这就是小程序的由来。

网页开发渲染线程和脚本线程是互斥的，这也是为什么长时间的脚本运行可能会导致页面失去响应，而在小程序中，二者是离开的，别离运行在不同的线程中。

网页开发者能够应用到各种浏览器裸露进去的 DOM API，进行 DOM 选中和操作。而如上文所述，小程序的逻辑层和渲染层是离开的，逻辑层运行在 JSCore 中，并没有一个残缺浏览器对象，因此短少相干的 DOM API 和 BOM API。这一区别导致了前端开发十分相熟的一些库，例如 jQuery、Zepto 等，在小程序中是无奈运行的。

同时 JSCore 的环境同 NodeJS 环境也是不尽相同，所以一些 NPM 的包在小程序中也是无奈运行的。

开发端	开发场景
网页开发者	各式各样的浏览器
PC 端	IE、Chrome、QQ 浏览器等
挪动端	Safari、Chrome 以及 iOS、Android 零碎中的各式 WebView
小程序	两大操作系统 iOS 和 Android 的微信客户端，以及用于辅助开发的小程序开发者工具

小程序中三大运行环境也是有所区别的

运行环境	逻辑层	渲染层
iOS	JavaScriptCore	WKWebView
安卓	V8	chromium 定制内核
小程序开发者工具	NWJS	Chrome WebView

网页开发者在开发网页的时候，只须要应用到浏览器，并且搭配上一些辅助工具或者编辑器即可。小程序的开发则有所不同，须要通过申请小程序帐号、装置小程序开发者工具、配置我的项目等等过程方可实现。

小程序的运行环境分成 渲染层 和逻辑层，其中 WXML 模板和 WXSS 款式工作在渲染层，JS 脚本工作在逻辑层。

小程序的渲染层和逻辑层别离由 2 个线程治理：渲染层的界面应用了 WebView 进行渲染；逻辑层采纳JsCore 线程 运行 JS 脚本。一个小程序存在多个界面，所以渲染层存在多个 WebView 线程，这两个线程的通信会经由微信客户端（下文中也会采纳 Native 来代指微信客户端）做直达，逻辑层发送网络申请也经由 Native 转发，小程序的通信模型下图所示。

特地须要留神的是 setData 调用形式和机会

setData 接口的调用波及逻辑层与渲染层间的线程通信，通信过于频繁可能导致解决队列阻塞，界面渲染不及时而导致卡顿，应防止无用的频繁调用。
因为小程序运行逻辑线程与渲染线程之上，setData 的调用会把数据从逻辑层传到渲染层，数据太大会减少通信工夫。
setData 操作会引起框架解决一些渲染界面相干的工作，一个未绑定的变量意味着与界面渲染无关，传入 setData 会造成不必要的性能耗费。

小程序提供了一个基于 nwjs 实现的 IDE 开发工具, 能够模仿代码预览成果, 然而实际上并不是真机的 webview 环境, 所以很多时候会发现开发环境跟真机预览的差异存在很多细节问题. 并且因为小程序自身的包体大小限度, 很多时候无奈间接唤起真机调试, 须要非凡解决将体积压到 2M 以下才行

微信客户端在关上小程序之前，会把整个小程序的代码包下载到本地。

紧接着通过 app.json 的 pages 字段就能够晓得你以后小程序的所有页面门路:

{
  "pages":["pages/logs/logs"]
}

于是微信客户端就把首页的代码装载进来，通过小程序底层的一些机制，就能够渲染出这个首页。

小程序启动之后，在 app.js 定义的 App 实例的 onLaunch 回调会被执行:

App({onLaunch: function () {// 小程序启动之后 触发}
})

整个小程序只有一个 App 实例，是全副页面共享的

你能够察看到 pages/logs/logs 下其实是包含了 4 种文件的，微信客户端会先依据 logs.json 配置生成一个界面，顶部的色彩和文字你都能够在这个 json 文件里边定义好。紧接着客户端就会装载这个页面的 WXML 构造和 WXSS 款式。最初客户端会装载 logs.js，你能够看到 logs.js 的大体内容就是:

Page({
  data: { // 参加页面渲染的数据
    logs: []},
  onLoad: function () {// 页面渲染后 执行}
})

Page 是一个页面结构器，这个结构器就生成了一个页面。在生成页面的时候，小程序框架会把 data 数据和 index.wxml 一起渲染出最终的构造，于是就失去了你看到的小程序的样子。

在渲染完界面之后，页面实例就会收到一个 onLoad 的回调，你能够在这个回调解决你的逻辑。

依赖管理混乱、工程化流程落后、ES Next 反对不欠缺、命名标准不对立等。这些问题在当初看来都曾经有了各种官网或非官方的解决办法.

最常见的开发模式就是应用某一套欠缺的开发框架, 他们最次要的区别就是DSL, 类 Vue 或者类 React 语法为主.

在微信小程序之后，各大厂商纷纷公布了本人的小程序平台,多端适配 型框架的需要也就应运而生了,(Taro, uni-app 等)

所以开发技术选型的次要思考因素就是: DSL 以及 多端适配

市面上第一款遵循 React 语法的多端小程序框架, 自研出Nervjs. 同时也反对应用 React/Vue/Nerv 等框架来开发

「Write once Run anywhere」

目前 （Taro3.x） 官网反对转换的平台如下：

H5
ReactNative
微信小程序
京东小程序
百度小程序
支付宝小程序
字节跳动小程序
QQ 小程序
钉钉小程序
企业微信小程序
支付宝 IOT 小程序
飞书小程序

必须满足下述要求：

代码多端复用，不仅能运行在时下最热门的 H5、微信小程序、React Native，对其余可能会风行的端也留有余地和可能性。
欠缺和弱小的组件化机制，这是开发简单利用的基石。
与目前团队技术栈有机联合，无效提高效率。
学习老本足够低
背地的生态弱小

在一个优良且严格的标准限度下，从更高形象的视角（语法树）来看，每个人写的代码都差不多。

也就是说，对于微信小程序这样不凋谢不开源的端，咱们能够先把 React 代码剖析成一颗形象语法树，依据这颗树生成小程序反对的模板代码，再做一个小程序运行时框架处理事件和生命周期与小程序框架兼容，而后把业务代码跑在运行时框架就实现了小程序端的适配。

对于 React 曾经反对的端，例如 Web、React Native 甚至将来的 React VR，咱们只有包一层组件库再做些许款式反对即可。鉴于时下小程序的热度和咱们团队自身的业务偏重水平，组件库的 API 是以小程序为规范，其余端的组件库的 API 都会和小程序端的组件保持一致。

Taro 以后的架构次要分为：编译时 和 运行时。

应用 babel-parser 将 Taro 代码解析成形象语法树，而后通过 babel-types 对形象语法树进行一系列批改、转换操作，最初再通过 babel-generate 生成对应的指标代码。

Babel 的编译过程亦是如此，次要蕴含三个阶段

解析过程，在这个过程中进行词法、语法分析，以及语义剖析，生成合乎 ESTree 规范虚构语法树(AST)
转换过程，针对 AST 做出已定义好的操作，babel 的配置文件 .babelrc 中定义的 preset、plugin 就是在这一步中执行并扭转 AST 的
生成过程，将前一步转换好的 AST 生成指标代码的字符串

如果对 AST 是什么不理解的话能够应用这个网站尝试一下 https://astexplorer.net/

省去整个编译过程失去的后果代码如下

<View className='index'>
  <Button className='add_btn' onClick={this.props.add}>+</Button>
  <Button className='dec_btn' onClick={this.props.dec}>-</Button>
  <Button className='dec_btn' onClick={this.props.asyncAdd}>async</Button>
  <View>{this.props.counter.num}</View>
  <A />
  <Button onClick={this.goto}> 走你 </Button>
  <Image src={sd} />
</View>

<import src="../../components/A/A.wxml" />
<block>
  <view class="index">
    <button class="add_btn" bindtap="add">+</button>
    <button class="dec_btn" bindtap="dec">-</button>
    <button class="dec_btn" bindtap="asyncAdd">async</button>
    <view>{{counter.num}}</view>
    <template is="A" data="{{...$$A}}"></template>
    <button bindtap="goto"> 走你 </button>
    <image src="{{sd}}" />
  </view>
</block>

因为 JSX 的丰盛自由度不是字符串模板能够比较的，所以过后只能反对大略 80% 的写法转换，残余不反对的写法转由 eslint 插件揭示用户批改。

在开源的过程中，Taro 反对的 JSX 写法始终在不断完善，力求让开发体验更加靠近于 React，次要包含以下语法反对：

反对 Ref，提供了更加不便的组件和元素定位形式
反对 this.props.children 写法，不便进行自定义组件传入子元素
在循环体内执行函数和表达式
定义 JSX 作为变量应用
反对简单的 if-else 语句
在 JSX 属性中应用简单表达式
在 style 属性中应用对象
只有应用到的变量才会作为 state 退出到小程序 data，从而精简小程序数据

咱们能够比照一下编译后的代码，能够发现，编译后的代码中，React 的外围 render 办法没有了。同时代码里减少了 BaseComponent 和 createComponent , 它们是 Taro 运行时的外围。

// 编译前
import Taro, {Component} from '@tarojs/taro'
import {View, Text} from '@tarojs/components'
import './index.scss'

export default class Index extends Component {

  config = {navigationBarTitleText: '首页'}

  componentDidMount () {}

  render () {
    return (<View className=‘index' onClick={this.onClick}>
        <Text>Hello world!</Text>
      </View>
    )
  }
}

// 编译后
import {BaseComponent, createComponent} from '@tarojs/taro-weapp'

class Index extends BaseComponent {

// ... 

  _createDate(){//process state and props}
}

export default createComponent(Index)

BaseComponent 大略的 UML（对立建模语言）图如下，次要是对 React 的一些外围办法：setState、forceUpdate 等进行了替换和重写，联合后面编译后 render 办法被替换，大家不难猜出：Taro 以后架构只是在开发时遵循了 React 的语法，在代码编译之后理论运行时，和 React 并没有关系。

而 createComponent 次要作用是调用 Component() 构建页面；对接事件、生命周期等；进行 Diff Data 并调用 setData 办法更新数据。

仅仅将代码依照语法标准转换之后还远远不够，因为不同端的特有原生能力或组件等限度，所以决定了跨端开发必然有局部代码须要开发中实现兼容，而为了最大水平补救不同端的差别，Taro 制订了一个统一标准，在不同端依附它们的语法与能力去实现组件库与 API，同时还要为不同端编写相应的运行时框架，初始化等等。因为最后的设计起源就是小程序，所以决定间接采纳小程序的规范，让其余端向小程序靠齐。

因为咱们有编译的操作，在书写代码的时候，只须要引入规范组件库 @tarojs/components 与运行时框架 @tarojs/taro，代码通过编译之后，会变成对应端所须要的库。

例如，为了晋升开发便利性，咱们为 Taro 退出了 Redux 反对，咱们的做法就是，在小程序端，咱们实现了 @tarojs/redux 这个库来作为小程序的 Redux 辅助库，并且以他作为基准库，它具备和 react-redux 统一的 API，在书写代码的时候，援用的都是 @tarojs/redux，通过编译后，在 H5 端会替换成 nerv-redux（Nerv的 Redux 辅助库），在 RN 端会替换成 react-redux。这样就实现了 Redux 在 Taro 中的多端反对。

开源之初，因为种种原因，Taro 的微信小程序端组件化采纳的是小程序 <template /> 标签来实现的，利用小程序 <template /> 标签的个性，将组件 JS 文件编译成 JS + WXML 模板，在父组件（页面）的模板中通过 <template /> 标签援用子组件的 WXML 模板来进行拼接，从而达到组件化的目标。

实践证明，Template 模板计划是一个失败的组件化计划，Taro 开源初期的 Bug 次要来源于此。因为这一计划将 JS 逻辑与模板拆离开了，须要手工来保障 JS 与模板中数据统一，这样在循环组件渲染、组件多重嵌套的状况下，要保障组件正确渲染与 props 正确传递的难度十分大，实现的老本也十分高。而且，囿于小程序 <template /> 标签的缺点，一些性能（例如自定义组件蕴含子元素等）无奈实现。

所以，在通过艰苦的摸索与实际之后，咱们采纳了小程序原生组件化来作为 Taro 的小程序端组件化计划，并且通过一些解决，绕开了小程序组件化的诸多限度，为 Taro 的稳定性打下了坚实基础，并带来了以下益处：

小程序端组件化更加强壮
尽可能减少因为框架带来的性能问题
依靠官网组件化，不便当前解锁更多可能

退出了对 百度智能小程序 和 支付宝小程序 的反对
为每个平台提供了平台标识

字节跳动（头条）小程序反对
微信小程序转 Taro
CSS Modules 反对
MobX 反对

反对快利用和 QQ 小程序的开发
全面反对 JSX 语法和 React Hooks
大幅提高 H5 性能和可用性
Taro Doctor

以后 Taro 的特点是：

重编译，轻运行
编译代码与 React 无关
间接应用 Babel 编译，导致在工程化和插件方面羸弱

毛病也比拟多：

保护艰难，每次须要新增一个性能，例如反对解析 Markdown 文件，就须要间接改变 CLI，不够灵便
难以共建，CLI 的代码非常复杂，而且逻辑分支泛滥，让很多想要一起共建的人难以动手
可扩展性偏低，自研的构建零碎，设计之初没有思考到后续的扩展性，导致开发者想要增加自定义的性能无从下手

mpvue 是一个应用 Vue.js 开发小程序的前端框架，目前反对 微信小程序、百度智能小程序，头条小程序和支付宝小程序 。框架 基于 Vue.js，批改了的运行时框架 runtime 和代码编译器 compiler 实现，使其可运行在小程序环境中，从而为小程序开发引入了 Vue.js 开发体验。

Vue.js 小程序版, fork 自 vuejs/vue@2.4.1，保留了 vue runtime 能力，增加了小程序平台的反对。

所以本章节 Vue 相干常识都是指 Vue2

彻底的组件化开发能力：进步代码复用性
残缺的 Vue.js 开发体验
不便的 Vuex 数据管理计划：不便构建简单利用
快捷的 webpack 构建机制：自定义构建策略、开发阶段 hotReload
反对应用 npm 内部依赖
应用 Vue.js 命令行工具 vue-cli 疾速初始化我的项目
H5 代码转换编译成小程序指标代码的能力

mpvue 保留了 vue.runtime 外围办法，无缝继承了 Vue.js 的根底能力
mpvue-template-compiler 提供了将 vue 的模板语法转换到小程序的 wxml 语法的能力
批改了 vue 的建构配置，使之构建出合乎小程序我的项目构造的代码格局：json/wxml/wxss/js 文件

Vue 代码

将小程序页面编写为 Vue.js 实现
以 Vue.js 开发标准实现父子组件关联

小程序代码

以小程序开发标准编写视图层模板
配置生命周期函数，关联数据更新调用
将 Vue.js 数据映射为小程序数据模型

并在此基础上，附加如下机制

Vue.js 实例与小程序 Page 实例建设关联
小程序和 Vue.js 生命周期建设映射关系，能在小程序生命周期中触发 Vue.js 生命周期
小程序事件建设代理机制，在事件代理函数中触发与之对应的 Vue.js 组件事件响应

这套机制总结起来非常简单，但实现却相当简单。在揭秘具体实现之前，读者可能会有这样一些疑难：

首先，mpvue 为提高效率而生，自身提供了主动生成小程序代码的能力，小程序代码依据 Vue.js 代码构建失去，并不需要同时开发两套代码。

Vue.js 视图层渲染由 render 办法实现，同时在内存中保护着一份虚构 DOM，mpvue 无需应用 Vue.js 实现视图层渲染，因而咱们革新了 render 办法，禁止视图层渲染。

生命周期关联：生命周期和数据同步是 mpvue 框架的灵魂，Vue.js 和小程序的数据彼此隔离，各自有不同的更新机制。mpvue 从生命周期和事件回调函数切入，在 Vue.js 触发数据更新时实现数据同步。小程序通过视图层出现给用户、通过事件响应用户交互，Vue.js 在后盾保护着数据变更和逻辑。能够看到，数据更新发端于小程序，解决自 Vue.js，Vue.js 数据变更后再同步到小程序。为实现数据同步，mpvue 批改了 Vue.js runtime 实现，在 Vue.js 的生命周期中减少了更新小程序数据的逻辑。

事件代理机制：用户交互触发的数据更新通过事件代理机制实现。在 Vue.js 代码中，事件响应函数对应到组件的 method，Vue.js 主动保护了上下文环境。然而在小程序中并没有相似的机制，又因为 Vue.js 执行环境中保护着一份实时的虚构 DOM，这与小程序的视图层齐全对应，咱们思考，在小程序组件节点上触发事件后，只有找到虚构 DOM 上对应的节点，触发对应的事件不就实现了么；另一方面，Vue.js 事件响应如果触发了数据更新，其生命周期函数更新将主动触发，在此函数上同步更新小程序数据，数据同步也就实现了。

建构流程是整个我的项目最外围的中央之一，通过咱们所熟知的 webpack，实现了 template 转换为 wxml 和款式转换优化以及其余的若干代码的拼接压缩混同等操作，最终使之能够运行在微信小程序的环境中。

除了 Vue2 自身的生命周期外，mpvue 还兼容了小程序生命周期

app 局部：

onLaunch，初始化
onShow，当小程序启动，或从后盾进入前台显示
onHide，当小程序从前台进入后盾

page 局部：

onLoad，监听页面加载
onShow，监听页面显示
onReady，监听页面首次渲染实现
onHide，监听页面暗藏
onUnload，监听页面卸载
onPullDownRefresh，监听用户下拉动作
onReachBottom，页面上拉触底事件的处理函数
onShareAppMessage，用户点击右上角分享
onPageScroll，页面滚动
onTabItemTap, 以后是 tab 页时，点击 tab 时触发（mpvue 0.0.16 反对）

mpvue 的实现同样分为：编译时 和运行时。

在 Vue 源码的 platforms 文件夹上面减少了 mp 目录，在外面实现了 complier（编译时） 和 runtime（运行时）反对。

相比于 Taro 将 JSX 转成小程序模板,mpvue 是将 vue 模板进行转换, 两者的相似性能够简化很多工作程序

<div v-if="condition" :id="`item-${id}`" v-model="value"  @click="tapName"> {{message}} </div>
------------------------------------------- 编译 --------------------------------------------------------
<view wx:if="{{condition}}" id="item-{{id}}" model:value="{{value}}"  bindtap="tapName"> {{message}} </view>

vue 文件次要分三局部: template, script, style

模板局部会经由 vue-loader 进行 ast 剖析, 生成 render 渲染函数

脚本局部会进行 Vue 实例化, 对 data 数据进行响应式解决, 每次批改都会触发 render 函数

render 函数会生成虚构 Dom, 每次新旧虚构 Dom 之间会进行 patch 比照, 失去最终批改后果才去操作实在 Dom 更新

其中 mpvue-template-compiler 作用是将 Vue2 预编译成 render 函数以防止运行时编译开销和 CSP 限度, 只有在编写具备特定需要的构建工具时才须要它。

因为小程序跟 Vue 原理不同, 所以间接移除 Vue 的 dom 操作阶段, 取而代之的是间接交给小程序原生实现

在 Vue 实例化的时候也会调用小程序实例化, 每次 Vue 进行 patch 之后, 会间接调用 $updateDataToMP() 获取挂载在 page 实例上数据, 而后通过 setData 办法更新视图

mpvue 属于半编译半运行, 次要体现在

JS 运行实质上还是用的是 Vue 那一套代码, 除了局部个性因为小程序的限度无奈兼容（如：filter、slot、v-html）
模板代码须要事后进行编译成 WXML 模板

所以两边属于一个割裂状态,vue 负责数据处理, 小程序负责渲染视图, 实际上是不便开发然而没有优化小程序的体验

非侵入式设计 WePY 2 运行于小程序之上，是对小程序原有能力的封装和优化，并不会对原有小程序框架有任何改变或者影响。
兼容原生代码可能兼容原生代码，即局部页面为原生，局部页面为 WePY。同时做到无需任何改变即可援用现有原生开发的小程序组件。
基于小程序原生组件实现组件化开发小程序原生组件在性能上相较之前有了很大的晋升。因而 WePY 2 齐全基于小程序原生组件实现，不反对小程序根底库 < 1.6.3 的版本。
基于 Vue Observer 实现数据绑定数据绑定基于 Vue Observer 实现，同时为其定制小程序特有的优化。
更优的可扩展性对于 core 库提供 mixin、hooks、use 等形式进行开发扩大，对于 cli 编译工具提供更弱小的插件机制不便开发者能够侵入到编译的任何一个阶段进行个性化定制的编译。

WePY 继承了 WXML 的根本模板语法，并反对大部分 Vue 模板语法。

标签	转换后
select	picker
datalist	picker
img	image
source	audio
video	video
track	video
a	navigator
span	label
其它	view

小程序原生的事件零碎应用 bind，catch 等关键字进行事件监听。而在 WePY 中，事件沿用了 Vue 的格调，应用 v-on 或者是 @ 操作符进行事件监听。同时 WePY 中会有一个对立的事件散发器接管原生事件。大抵如下图：

WePY 在编译过程中，会找到所有监听事件，并为其调配事件 ID。同时将事件代码（能够是一个办法，也能够是一个简略的代码片段）注入至 JS 代码中。而后当事件散发器接管到原生事件时，会通过事件 ID，散发到相应的事件逻辑当中。

这样做的益处次要是：

可控性更强。用户可利用相干钩子函数从而解决全局的用户事件。（典型场景：为页面全副按钮对立减少一个点击上报性能）
灵便度更高。绝对于原生只能应用函数名的形式来说，还可应用简略代码片段。（典型场景：@tap=”num++”）

更多是对底层架构的变革，进步拓展性，稳定性，可维护性，升高开发和学习老本

Taro 2.0 的 CLI 将会变得十分轻量，只会做辨别编译平台、解决不同平台编译入参等操作，随后再调用对应平台的 runner 编译器做代码编译操作，而原来大量的 AST 语法操作将会革新成 Webpack Plugin 以及 Loader，交给 Webpack 来解决。

利于保护，大量的逻辑交由 Webpack 来解决，咱们只须要保护一些插件
更加稳固，相较于自研的构建零碎，新的构建会更加稳固，升高一些奇怪谬误的呈现概率
可扩展性强，能够通过自行退出 Webpack Loader 与 Plugin 的形式做本人想要的扩大
各端编译对立，接入 Webpack 后，Taro 各端的编译配置能够实现十分大程度的对立

编译配置调整

异步编程调整

主编译流程钩子

编译增加 Loader

编译增加 Plugin

Taro RN 依赖降级

运行时性能次要分为两个局部，一是更新性能，二是初始化性能。

对于更新性能而言，旧版本的 Taro 会把开发者 setState 的数据进行一次全量的 diff，最终返回给小程序是按门路更新的 data。而在 Taro Next 中 diff 的工作交给了开发者应用的框架（React/Nerv/Vue），而框架 diff 之后的数据也会通过 Taro 按门路去最小化更新。因而开发者能够依据应用框架的个性进行更多更轻微的性能优化。

初始化性能则是 Taro Next 的痛点。原生小程序或编译型框架的初始数据能够间接用于渲染，但 Taro Next 在初始化时会把框架的渲染数据转化为小程序的渲染数据，多了一次 setData 开销。

为了解决这个问题，Taro 从服务端渲染受到启发，在 Taro CLI 将页面初始化的状态间接渲染为无状态的 wxml，在框架和业务逻辑运行之前执行渲染流程。咱们将这一技术称之为预渲染（Prerender），通过 Prerender 的页面初始渲染速度通常会和原生小程序统一甚至更快。

作为一个编译型框架，旧版本的 Taro 会进行大量的 AST 操作，这类操作显著地拖慢了 Taro CLI 的编译速度。而在 Taro Next 中不会操作任何开发者代码的 AST，因而编译速度失去了大幅的进步。

正因为 AST 操作的勾销，Taro Next 也轻松地实现了 source-map 的反对。这对于开发体验是一个微小的晋升：

跨端：H5、微信、支付宝、百度、字节跳动 … 小程序

微信小程序转 React/Vue

渲染 HTML 字符串

CSS-in-JS

虚构列表（VirtualList）

开放式插件零碎

预渲染

不同于 Taro 1、2 时代的架构，新的架构次要基于运行时，咱们都晓得应用 React 开发 web，渲染页面次要依附的是 react-dom 去操作 DOM 树，而 React Native 依附的是 Yoga 布局引擎，然而咱们却能通过 React 将他们分割在一起，这次要是通过形象的 Virtual DOM 技术来实现的，通过 Virtual DOM 达到跨平台对立的目标。而小程序中尽管没有间接裸露 DOM 和 BOM API，然而咱们却能够类比 React 和 React Native 的思维，在小程序中模仿实现 DOM 以及 BOM 的 API，从而实现间接将 React 运行到小程序环境中的目标，这就是 Taro 新架构的由来。

指标是能够通过插件的模式扩大 Taro 的端平台反对能力：

插件开发者无需批改 Taro 外围库代码，即可编写出一个端平台插件。
插件使用者只需装置、配置端平台插件，即可把代码编译到指定平台。
开发者能够继承现有的端平台插件，而后对平台的适配逻辑进行自定义。

初 Taro 抉择重编译时的次要起因是处于性能思考，毕竟 同等条件下，编译时做的工作越多，也就意味着运行时做的工作越少，性能会更好 ；另外，重编译时也保障了 Taro 的代码在编译之后的可读性。然而从久远来看，计算机硬件的性能越来越冗余， 如果在就义一点能够容忍的性能的状况下换来整个框架更大的灵活性和更好的适配性，咱们认为是值得的。

Taro 实现了一套高效、精简版的 DOM/BOM API 运行时渲染代码 @tarojs/runtime

Taro 运行时。在小程序端连贯框架（DSL）渲染机制到小程序渲染机制，连贯小程序路由和生命周期到框架对应的生命周期。在 H5/RN 端连贯小程序生命周期标准到框架生命周期。

不论什么框架, 最终都是转成浏览器可执行的代码, 用的都是通用的 DOM/BOM API, 例如createElement、appendChild、removeChild 等

在 DOM/BOM 注入之后，实践上来说，Nerv/Preact 就能够间接运行了。然而 React 有点非凡，因为 React-DOM 蕴含大量浏览器兼容类的代码，导致包太大，而这部分代码咱们是不须要的，因而咱们须要做一些定制和优化。

能够看到 React 大体分三层

React 外围实现源码
Diff/Fiber 算法实现源码, 负责保护虚构树
具体平台渲染实现源码, 负责组件, 事件, 节点渲染等

所以 Taro 实现了@tarojs/react

基于 react-reconciler 的小程序专用 React 渲染器，连贯 @tarojs/runtime 的 DOM 实例，相当于小程序版的 react-dom，裸露的 API 也和 react-dom 保持一致。

其中最重要的的两个实现性能

hostConfig: 关联对应的 BOM/DOM 实现 API, 实现 Dom 操作性能

render: 理论的渲染办法

function render(element, domContainer, cb) {const oldRoot = ContainerMap.get(domContainer);
    if (oldRoot != null) {return oldRoot.render(element, cb);
    }
    const root = new Root(TaroReconciler, domContainer);
    ContainerMap.set(domContainer, root);
    return root.render(element, cb);
}

目前为止曾经实现了代码运行逻辑, 剩下的就是基于组件的 template, 动静渲染页面

抛开已实现的 BOM/DOM API 之后,React 和 Vue 的区别很小, 只须要在运行时的 CreateVuePage 进行一些解决, 例如生命周期对齐等, 其余局部根本都统一

首先的 Taro Next 事件，具体的实现形式如下：

在小程序组件的模版化过程中，将所有事件办法全副指定为调用 ev 函数，如：bindtap、bindchange、bindsubmit 等。
在运行时实现 eventHandler 函数，和 eh 办法绑定，收集所有的小程序事件
通过 document.getElementById() 办法获取触发事件对应的 TaroNode
通过 createEvent() 创立符合规范的 TaroEvent
调用 TaroNode.dispatchEvent 从新触发事件

Taro Next 事件实质上是 基于 Taro DOM 实现了一套本人的事件机制，这样做的益处之一是，无论小程序是否反对事件的冒泡与捕捉，Taro 都能反对。

无论是 React 还是 Vue，最终都会调用 Taro DOM 办法，如：appendChild、insertChild 等。

这些办法在批改 Taro DOM Tree 的同时，还会调用 enqueueUpdate 办法，这个办法能获取到每一个 DOM 办法最终批改的节点门路和值，如：{root.cn.[0].cn.[4].value: "1"}，并通过 setData 办法更新到视图层。

这里 更新的粒度是 DOM 级别，只有最终产生扭转的 DOM 才会被更新过来，绝对于之前 data 级别的更新会更加精准，性能更好。

新的架构根本解决了之前的遗留问题：

无 DSL 限度：无论是你们团队是 React 还是 Vue 技术栈，都可能应用 Taro 开发
模版动静构建：和之前模版通过编译生成的不同，Taro Next 的模版是固定的，而后基于组件的 template，动静“递归”渲染整棵 Taro DOM 树。
新个性无缝反对：因为 Taro Next 实质上是将 React/Vue 运行在小程序上，因而，各种新个性也就无缝反对了。
社区奉献更简略：谬误栈将和 React/Vue 统一，团队只须要保护外围的 taro-runtime。
基于 Webpack：Taro Next 基于 Webpack 实现了多端的工程化，提供了插件性能。

Taro Next 的新架构变成近乎全运行之后，花了很多精力在性能优化下面。

相比原生小程序，Taro Next 多了红色局部的带来的性能隐患，如：引入 React/Vue 带来的包的 Size 减少，运行时的损耗、Taro DOM Tree 的构建和更新、DOM data 初始化和更新。

而咱们真正能做的，只有绿色局部，也就是：Taro DOM Tree 的构建和更新、DOM data 初始化和更新。

Taro Next 的更新是 DOM 级别的，比 Data 级别的更新更加高效，因为 Data 粒度更新实际上是有冗余的，并不是所有的 Data 的扭转最初都会引起 DOM 的更新。

其次，Taro 在更新的时候将 Taro DOM Tree 的 path 进行压缩，这点也极大的晋升了性能。

最终的后果是：在某些业务场景写，add、select 数据，Taro Next 的性能比原生的还要好。

开放式架构

新增小程序性能优化组件 CustomWrapper

原生小程序渐进式混合应用 Taro 开发

拥抱 React 17、TypeScript 4

更快编译速度

source-map 反对

多 React Native 版本反对，拥抱最新版 0.64

更丰盛 API 与组件

API 与组件按需引入

反对应用 H5 标签

小程序反对应用框架的 DevTools

修复百度小程序 flex 布局的问题

反对应用 Preact 进行开发（一款体积超小的类 React 框架，提供和 React 简直统一的 API，而体积只有 5k 左右）

Vue 3 反对 Composition API 版本的小程序生命周期钩子

运行时体积优化

反对适配鸿蒙

小程序跨框架开发的摸索与实际

小程序框架全面测评

多端对立开发框架 – Taro

为何咱们要用 React 来写小程序 – Taro 诞生记

微信官网文档

hybrid 利用

长处

毛病

微信小程序

简介

技术发展史

小程序与一般网页开发的区别

渲染层和逻辑层

开发环境

加载过程

开发痛点

Taro1.x

设计思路

架构

Taro 编译时

Taro 运行时

跨端兼容

小程序组件化

性能更新

1.1

1.2

1.3

技术选型与衡量

总结

mpvue2.0(截至 2018.8.10 已进行保护)

框架原理

要同时保护 Vue.js 和小程序，是否须要写两个版本的代码实现?

小程序负责视图层展示，Vue.js 的视图层是否还须要，如果不须要应该如何解决?

生命周期如何买通，数据同步更新如何实现?

建构流程

生命周期

架构

编译时

运行时

Vue2 原理图

mpvue 整体原理图

总结

Wepy2（已废除）

设计思维

转换流程

HTML 模板标签映射表

事件处理

Taro2.x

CLI

其余

Taro3.x

跨框架：React、Nerv、Vue 2、Vue 3、jQuery

更快的运行速度

更快的构建速度和 source-map 反对

其余

开放式架构

React16+ 实现

Vue 实现

事件

更新

新架构特点

性能优化

Update Date

性能更新

3.1

3.2

3.3

3.4 beta

3.5 canary

参考援用文章