共计 2653 个字符，预计需要花费 7 分钟才能阅读完成。
前言
最近实习中参加了 H5 我的项目向小程序迁徙的工作，在微信官网文档和一些帖子上学习了小程序运行机制和底层原理，以及与 Web 页面的区别，在此基础上又看了一些对于小程序同构计划的内容。以下是我集体的一些学习总结。本文内容参考
微信凋谢文档
如何了解小程序的运行机制
小程序多平台同构计划
小程序是什么？
在小程序诞生前，微信团队开发的 JS-SDK 使 web 开发者能够通过裸露的 API 应用微信原生能力去实现一些事，如调用接口打开微信领取等。针对挪动端设施网络状态不稳固导致的白屏问题，微信又推出增强版 JS-SDK，也就是“微信 Web 资源离线存储”，但在简单的页面上仍然会呈现白屏的问题，起因体现在页面切换的僵硬和点击的通畅感。这个时候须要一个 JS-SDK 解决不了的，使用户体验更好的一个零碎，即小程序。
小程序是一种全新的连贯用户与服务的形式，它能够在微信内被便捷地获取和流传，同时具备杰出的应用体验。
其本质是运行在 webview 上的 H5 利用，但与 H5 又有着实质上的不同。H5 能够了解为运行在挪动端的 web 页面，实质还是由 HTML+CSS+JS 形成的 web 利用。小程序和 H5 的区别也就是小程序和网页的区别。
小程序与一般网页开发的区别
小程序的次要开发语言是 JavaScript，小程序的开发同一般的网页开发相比有很大的相似性。对于前端开发者而言，从网页开发迁徙到小程序的开发成本并不高，然而二者还是有些许区别的。
- 网页开发的渲染和脚本执行是在同一个线程上执行的，这也是网页脚本长时间运行有可能会导致页面失去响应的起因；而小程序的视图层和逻辑层是齐全拆散在两个不同的线程上执行
- 开发网页时咱们能够在 JS 代码中通过 Dom API 对节点进行各种操作，通过 window 对象实现原生事件响应、页面跳转；因为小程序的 JS 代码运行在 JSCore, 与渲染层拆散，所以在逻辑层中无奈取得 Dom 和 Bom，从而无奈应用各种 Dom API
- 网页开发者须要面对的环境是各式各样的浏览器，PC 端须要面对 IE、Chrome、QQ 浏览器等，在挪动端须要面对 Safari、Chrome 以及 iOS、Android 零碎中的各式 WebView。而小程序开发过程中须要面对的是两大操作系统 iOS 和 Android 的微信客户端，以及用于辅助开发的小程序开发者工具
小程序架构
渲染机制
处于性能和实现的思考，小程序采纳Hybrid 渲染机制，这样做有几点益处：
- 扩大 Web 的能力。比方像输入框组件（input, textarea）有更好地管制键盘的能力
- 体验更好，同时也加重 WebView 的渲染工作
- 绕过 setData、数据通信和重渲染流程，使渲染性能更好
- 用客户端原生渲染内置一些简单组件，能够提供更好的性能
架构
如下图所示，原生小程序框架采纳双线程模型：视图层和逻辑层齐全拆散为两个不同的线程。每个页面的渲染在一个 webview 线程上执行，视图层蕴含多个 webview 线程，而逻辑层则对立在 JSCore 上执行。
这样做的目标是避免逻辑层对 Dom 和 window 的操作（如跳转到内部页面），使整个利用变得平安可控。
- 逻辑层：创立一个独自的线程去执行 JavaScript，在这里执行的都是无关小程序业务逻辑的代码，负责逻辑解决、数据申请、接口调用等
- 视图层：界面渲染相干的工作全都在 WebView 线程里执行，通过逻辑层代码去管制渲染哪些界面。一个小程序存在多个界面，所以视图层存在多个 WebView 线程
- JSBridge 起到架起下层开发与 Native（微信零碎）的桥梁，使得小程序可通过 API 应用原生的性能，且局部组件为原生组件实现，从而有良好体验
视图层和逻辑层的通信
双线程模型下，逻辑层代码无奈间接操作 Dom，逻辑层和视图层的数据传输（setData）是通过两边的 evaluateJavaScript 实现的。用户传输的数据，须要将其转换为字符串模式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的模式传递到两边独立环境。
小程序多端同构计划
很多企业都有本人的小程序平台，如微信、支付宝、头条等，现在市面上很多产品都是基于 React、Vue 等框架开发的 web 利用，但 web 端代码是不可能运行在小程序平台上的（详见上述小程序和 web 利用的不同），而开发几套代码的工夫和保护老本又太高，为了节俭学习和开发成本，各大公司都推出了本人的多端小程序计划，使开发者能够用 React、Vue 框架来开发小程序。相似框架有微信的 Kbone、阿里的 Remax、京东的 Taro 等。
Taro 是在编译时将代码适配到小程序平台，而 Kbone 和 Remax 则是在运行时实现这个工作。
以下重点解释 Kbone 和Remax。
Kbone
参照微信官网文档，Kbone 在适配层里模拟出了浏览器环境，让 Web 端的代码能够不做什么改变便可运行在小程序里。
kbone 实现原理是在 worker 线程适配了一套 JS Dom API，下层不论是哪种前端框架 (react、vue) 或原生 JS 最终都须要调用 JS Dom API 操作 dom，适配的 JS Dom API 则接管了所有的 Dom 操作，并在内存中保护了一棵 Dom tree，所有下层最终调用的 Dom 操作都会更新到这棵 Dom tree 中，每次操作 (有节流) 后会把 Dom tree 同步到 webview 线程中，通过 wxml 自定义组件进行 render。
Remax
与 Kbone 下层反对多种框架（React、Vue、Angular）不同，Remax 专门实现 React 利用向小程序的适配。
Remax 实现原理是在 worker 线程保护一棵虚构 Dom tree, 这棵虚构 Dom tree 会通过小程序原生的 setData 办法映射到 render 线程，render 层再把虚构 Dom tree 进行遍历而后渲染。
Remax 和 kbone 相似，都是在 worker 线程保护一棵 Dom tree，再把这棵 Dom tree 传到 render 线程进行渲染，惟一的区别是 remax dom tree 发生变化时，会计算差别，而不须要把整棵树都传到 render 线程，此性能是 react 提供的，就是在 diff 完后找出差别，则把差别传到 render 线程
总结
- Kbone 和 Remax 实现原理基本相同，都在 worker 线程保护虚构 Dom tree, 再把虚构 Dom tree 传到 render 线程渲染
- 二者次要有两点不同：Kbone 下层反对多种框架，而 Remax 仅反对 React；Remax 的 Dom tree 发生变化时会计算 diff，把 diff 映射到 render 线程，而 Kbone 是将整个 Dom tree 传过来