小程序与Taro

[Bjkb]

小程序的前世今生

小程序的前世

• 小程序并非凭空冒出来的一个概念。当微信中的 WebView 逐渐成为移动 Web 的一个重要入口时，微信就有相关的 JS API 了。也就是微信提供的 WeixinJSBridge 的 JS SDK。
  • 比如说在微信的浏览器里提供一些原生的能力，诸如 微信分享，调用原生相册 之类的原生功能
  • 但是这跟其它的混合APP应用并没有区别，复杂的页面会白屏，页面切换的生硬以及用户体验的不足。这些种种缺点，使微信迫切的想要一个解决方案，去优化这些问题。

小程序的诞生

传统的混合APP
传统的混合APP，主要依赖于端上内置的JS运行容器，在其上运行混合APP代码，其本质仍然属于传统的JavaScript运行机制，也就是单线程运行的，并且JS引擎线程会跟GUI渲染线程互斥，导致执行长时间的JS操作的时候，页面会失去响应，动画掉帧等，影响用户体验，这也是混合APP最大的一个弊端

小程序的底层架构
小程序的实现逻辑是双线程架构

小程序的运行环境

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

视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务处理。这就解决了混合APP最大的一个问题

小程序与传统编写的区别

• 由于种种的考虑（主要是管控性跟安全性，惨遭阉割的小程序也只能走微信审核上线了），小程序搞出了这有点扯淡的实现，还自己搞了一套模板语法，用于区别开传统的 HTML+CSS+JS的方式
• 小程序由3个文件组成一个小的组件 WXML+WXSS+JS，然后偷偷摸摸的编译一下，本质还是HTML+CSS+JS

WXML

WXSS

依赖于微信平台的Native组件
由于依赖于微信平台，所以在小程序里面，能使用微信提供的原生组件，也就是Native层绘制的组件，Native层绘制的组件会在WebView层之上

所以 微信小程序的本质是由WebView与Native两者组合渲染完成的

小程序的优势

小程序的问题

• 小程序的逻辑层和渲染层是分开的，逻辑层运行在 JSCore 中，并没有一个完整浏览器对象，因而缺少相关的DOM API和BOM API。
• 这一区别导致了前端开发非常熟悉的一些库，例如 jQuery、 Zepto 等，在小程序中是无法运行的。
• 同时 JSCore 的环境同 NodeJS 环境也是不尽相同，所以一些 NPM 的包在小程序中也是无法运行的。

为什么选择使用框架taro

小程序编写方面的不足

虽然小程序为业务提供了一种新的展示形式，但对于开发者来说，开发体验则显得并不那么友好。在前端工程化深入人心的今天，小程序那落后的三件套编写模式，大大的浪费时间。

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

小程序框架对比

列表渲染

点击组件响应速度

社区对比

taro的特点

Taro 采用了 React 语法来作为自己的语法标准，配合前端工程化的思想，为小程序开发打造了更加优雅的开发体验。

• React 是一个非常流行的框架，也有广大的受众，使用它也能降低小程序开发的学习成本；
• 小程序的数据驱动模板更新的思想与实现机制，与 React 类似；
• React 采用 JSX 作为自身模板，JSX 相比字符串模板来说更自由，更自然，更具表现力，不需要依赖字符串模板的各种语法糖，也能完成复杂的处理
• React 本身有跨端的实现方案 - React Native，并且非常成熟，社区活跃，对于 Taro 来说有更多的多端开发可能性。

我们目前这边所使用的前端框架也就是 React，基本只需要很少的学习，就能无缝切换到小程序的开发当中去。

Taro原理以及机制

taro诞生的本质思想跟编译原理有点类似，就是通过编译的方式，将taro代码，通过一系列的操作，转换成目标代码

Taro的优势

• 由于taro的这种实现策略，导致其也能编译成其它环境的代码
• 目前 Taro 代码可以支持转换到 微信/百度/支付宝/字节跳动/QQ小程序 、快应用、 H5 端 以及 移动端（React Native）。
  
  

但是这对于多端开发是远远不够的，因为每一个平台都有自己的特性，比如小程序跟WEB

taro运行机制

编译转换核心
Taro 的核心部分就是将代码编译成其他端（H5、小程序、React Native 等）代码。一般来说，将一种结构化语言的代码编译成另一种类似的结构化语言的代码包括以下几个步骤：

具体的操作
假设我们需要更改 foo的名字 为 bar

jsonStr.replace(/(?<=")foo(?="\s*:)/i, 'bar')

这就是具体的操作了，实现parse的部分是整个框架的核心，肯定不可能这么简单了，但是自己去实现一个parse也是工作量非常巨大的，还好业界有非常著名的 babel

• 利用Babylon(@babel/parser) 将代码转换成AST

import * as babylon from "babylon";

const code = `n * n`;

babylon.parse(code);

转换成这样

然后通过 Babel-traverse (@babel/traverse) 可以遍历生成的树，实现添加，删除，替换的操作。

taro运行时

Taro 组件的 setState 行为最终会对应到小程序的 setData。Taro 引入了如 nextTick ，编译时识别模板中用到的数据，在 setData 前进行数据差异比较等方式来提高 setState 的性能。

taro的不足

• 受限于模板转译的机制，不可能完全支持React的一些新特性，某些方法的使用也遭到了阉割
• 编译代码必然会导致包体积的增加
• 性能相比小程序原生语法，有些许下降

小结

这里只简单介绍了一下小程序的历史以及taro主要的架构，在开发过程中依然有无数的坑在等着你，这个只有等具体实践的时候，再逐步积累了。

参考文章：
微信小程序架构，工作原理解析
Taro多端开发原理与实战
小程序开发框架对比