第三方小程序框架原理前言本章内容分解：小程序框架都有哪些框架之间的原理有什么不同具体实现方式是怎样的第三方框架

前言

本章内容分解：

小程序框架都有哪些
框架之间的原理有什么不同
具体实现方式是怎样的

第三方框架

为什么会出现第三方框架呢，换一种方式来说的话就是小程序在基于当前的情况下还有什么弊端？

这一章我们就来聊一聊这个方面。

首先webpack工程化小程序就不支持。还有预编译也是不可以的，原来我们开发的时候可以使用less、sass写起来很方便，规避一些问题，做一些嵌套、类的选择，集中处理一些问题。

如果直接使用小程序规则开发，对于开发效率方面会有一些影响，也不方便定制工程化的流程。会有一些回归到最原始的html+css+js的开发模式年代的感觉。

为了解决上面的问题，出现了很多的小程序第三方框架。这些第三方框架基本上都是围绕着两种语言来的，vue & react。或者说类vue、类react。

那么我们就来聊一下框架。

三种框架

预编译

什么是预编译的框架呢？还记得我们讲解WXSS的时候，WXSS的文件会编译成js再执行。像这种执行前就进行编译的手段就叫做预编译。这种框架就是预编译框架。wepy、taro就是这样的框架。

我们先用taro的代码来举一个例子。

代码上我添加了一些备注，预编译框架正是分开编译了这三个部分，在执行之前就将小程序需要的文件编译出来，比如return内容编译为WXML，less编译为WXSS，生命周期及方法等编译为js。

预编译框架自身定义了一套DSL(语法规则)，这里taro的语法规则就是类似react的语法规则，也一直是taro主打的优势对吧。然后DSL解析编译为抽象语法树AST进行词法分析和语法分析。最后还原为小程序的代码。

可以看出预编译框架的核心思想就是DSL+ 语法解析。刚看了一下taro最新的文档，已经支持react hooks这样的写法了。

如果taro支持react hooks类似的写法的话，那么taro团队一定需要写一套关于hooks的语法解析，把hooks的逻辑转换为小程序的js逻辑。换句话说，taro已经把react的语法解析写的差不多了。现在还支持了vue及Nerv版本。

可以看的出来的是上面的截图中有一句话：

本篇文档只会介绍在 Taro 中可用的 Hooks API 和部分与 React 不一致的行为，其它内容大体的内容和 Hooks Reference 相同。

与React有不一致是很正常的事情，自己写语法解析终究会有一些环境掣肘，毕竟是两个平台之间的兼容，我认为主要是小程序平台的规则较为简陋导致解析不过来。

不过taro自身也推出了一些类似hooks的api可以使用。这样的话就可以弥补一些与react hooks不一致的情况，业务场景覆盖还是很全的。

我们再换成wepy来看一下。wepy也是预编译框架，看一下wepy的模版是怎么样的。

可以看到模版中的语法与vue模版语法相似，只不过有些许地方不一样，比如page的声明，template中的结构，小程序独有的config模块。

与taro一致，只不过wepy定制的是类似vue语法结构的DSL，模版中的四个模块分别会编译为小程序的四个文件。style模块编译为WXSS，template模块编译为WXML，script模块编译为js，config模块编译为小程序配置json。

小程序预编译框架的原理就如上述讲解，我们可以想象一下预编译框架的坏处有什么呢？

react或者vue后期再出一些新特性的话，预编译框架都需要在进行语法解析扩展编写。
兼容问题，比如小程序不支持的一些属性，如果不支持，预编译框架要进行兼容。

因为如上因素，半编译半运行框架随之推出。

半编译半运行框架

半编译半运行框架有什么呢，美团开发的mpvue。

虽然还没讲到运行时框架，但是要了解到是，基本上运行时的框架都是基于vue的框架才可以达到运行时的目的。可以看一下mpvue的Github简介

这个项目就是直接从vue项目fork过来修改的。那么它改了什么东西呢，我们接着往后看。

首先看一下vue的渲染框架：

最后的node就是web端渲染真实node节点了，达到页面更新渲染的目的。

我们可以想象一下一个问题，如果想让vue运行在小程序中，需要做哪些工作？

通过前面章节的讲解我们可知微信小程序的视图渲染与逻辑是分开的，逻辑层通过setData更新视图渲染。

那么就可以修改patch流程不直接生成真实node，而是触发setData来更新视图层。

可以想象一下，如果把vue的template编译成WXML就变为了小程序的视图层。vue本身预编译的代码为js，这个js是可以在逻辑层中运行由于js-core，然后当数据变动的时候走vue的渲染流程，patch流程改为setData来触发视图层更新。这样的话是完全没问题的。

所以为什么这个框架的名称叫半编译半运行框架，半编译讲的是vue的template需要单独编译为wxml，半运行讲的是vue整体的特性都会在逻辑层中运行。为了符合小程序的渲染框架，修改了vue的框架，最终达到了这个目的。

看一下mpvue的官网介绍。

可以看到介绍中提到的compiler实现就是讲vue中的template抽离并且编译为wxml的模块。mpvue的源码中可以看到具体实现。

备注都是中文还是很友好的。

另一处修改就是vue的runtime下的patch模块。

可以看到触发了一个this.$updateDataToMP()方法。这个方法在runtime/render.js中。

在this.$updateDataToMP()方法中就进行了setData的一个调用。还可以看到有另一个方法为initDataToMP初始化方法。

在初始化中setData中data是全部的，然而在updateDataToMP阶段可以看到做了一个diffData数据的比对，有修改的data才会触发setData。

并且随后的是throttle函数，减少setData的次数。优化双线程通讯的性能。在函数上方备注的也很清楚。

这两点也是印证了上面我们所阐述的，核心修改就是这两处，当然还需要一些额外的工作才可以，比如说生命周期的对称、监听等等，都是修改runtime下的文件。

大家可以看一下mpvue的源码，并且备注十分齐全。

运行时框架

可以借鉴一下半编译半运行时框架的原理思考，如果要把半运行时框架变成为运行时框架需要做什么？

首先为什么mpvue需要compiler模块将vue中的template编译为WXML？为什么不直接生成真实node。

我们需要缕一下思路。

首先vue或者react如果生成真实node后，需要插入到HTML中去，怎么插入呢，一般是通过操作DOM的api比如innerHTML类似。

在小程序双线程架构中，渲染层是没有开放任何操作DOM的api给逻辑层的。逻辑层是没有办法通过操作DOM来改变视图的。所以我们看到了半编译半运行时框架通过半编译，把vue的template模版提前编译为wxml，然后通过setData把data数据传输过去。

然而纯运行时框架就是要解决这个半编译的问题。

届时有几个问题需要解决：

通讯方式只能通过setData到渲染层
vue、react最终需要操作DOM

看似无解的两个问题。如果vue运行时在逻辑层，那么逻辑层终究没有操作DOM的api。

首先需要解决的问题就是动态地渲染DOM问题。

针对这块的话有一个契机，小程序的template模版机制。我们先看一下什么是小程序的template模版。

小程序模版template

WXML提供模板（template），可以在模板中定义代码片段，然后在不同的地方调用。

定义模板：

使用 name 属性，作为模板的名字。然后在<template/>内定义代码片段，如：

<!--
  index: int
  msg: string
  time: string
-->
<template name="msgItem">
  <view>
    <text> {{index}}: {{msg}} </text>
    <text> Time: {{time}} </text>
  </view>
</template>

使用模板：

<template is="msgItem" data="{{...item}}"/>

Page({
  data: {
    item: {
      index: 0,
      msg: 'this is a template',
      time: '2016-09-15'
    }
  }
})

is 属性可以使用Mustache语法(一个logic-less（轻逻辑）模板解析引擎，下方例子中的{{}}就是Mustache语法)，来动态决定具体需要渲染哪个模板：

<template name="odd">
  <view> odd </view>
</template>
<template name="even">
  <view> even </view>
</template>

<block wx:for="{{[1, 2, 3, 4, 5]}}">
  <template is="{{item % 2 == 0 ? 'even' : 'odd'}}"/>
</block>