微信小程序原理
一.整体流程图
从技术实现的层面来说，不管是小程序，还是 RN，或者 Weex，都有共同点，比如 JS 和 Native 的通讯机制，比如 JS 直接调用原生组件的渲染，如在 iOS 平台，小程序和 RN 都采用 JavaScriptCore 来执行 JS。但是小程序和 RN 设计初衷和应对的场景不一样，我们知道小程序的场景主要是在当前实际物理场景用户可以即扫即用，用完即走，整个交互都是非常轻量级的，不涉及特别复杂的交互逻辑，所以在设计上考虑尽量简单，首先是系统底层框架简单，其次开发者开发简单，再次用户使用简单，所以小程序大部分的 UI 组件还是 H5 的渲染方式，而不是像 RN 设计成 Native 的 UI 组件。
二、小程序架构
微信小程序的框架包含两部分View视图层、App Service逻辑层，View层用来渲染页面结构，AppService层用来逻辑处理、数据请求、接口调用，它们在两个线程里运行。
视图层使用WebView渲染，逻辑层使用JSCore运行。
视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层把数据变化通知到视图层，触发视图层页面更新，视图层把触发的事件通知到逻辑层进行业务处理。
三小程序框架
1.小程序本身为了解决部分组件性能的问题也采用了 Native 的方式，另外准确的说小程序不仅仅运行在 Webview 里，需要区分不同的部分。
2小程序的渲染层和逻辑层分别由两个线程管理：渲染层的界面使用 WebView 进行渲染；逻辑层采用 JSCore 运行 JavaScript 代码。一个小程序存在多个界面，所以渲染层存在多个 WebView。这两个线程间的通信经由小程序 Native 侧中转，逻辑层发送网络请求也经由 Native 侧转发，小程序的通信模型下图所示。
微信小程序的界面主要由成熟的 Web 技术渲染，辅之以大量的接口提供丰富的客户端原生能力。同时，每个小程序页面都是用不同的 WebView 去渲染，这样可以提供更好的交互体验，更贴近原生体验，也避免了单个 WebView 的任务过于繁重
- 逻辑层以 JSCore 或 V8 引擎为载体。开发者只需编写业务逻辑。
- 渲染层基于多个 WebView 组成的页面栈。
| 运行环境 | 逻辑层 | 渲染层 |
|---|---|---|
| Android | V8 | Chromium 定制内核 |
| iOS | JavaScriptCore | WKWebView |
| 小程序开发者工具 | NWJS | Chrome WebView |
四同层渲染
顾名思义即webviw的渲染的那一层和Native同时存在于一层，优势互补，小程序则主要由成熟的 Web 技术渲染，辅之以大量的接口提供丰富的客户端原生能力，就是通过一定的技术手段把原生组件直接渲染到 WebView 层级上，此时「原生组件层」已经不存在，原生组件此时已被直接挂载到 WebView 节点上，话不多说先上图：
Android 同层渲染原理
小程序在 Android 端采用 chromium 作为 WebView 渲染层，chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，主要用来解析和描述embed 标签。Android 端的同层渲染就是基于 embed 标签结合 chromium 内核扩展来实现的。 Android 端「同层渲染」的大致流程如下:
- 1、WebView 侧创建一个 embed DOM 节点并指定组件类型；
- 2、chromium 内核会创建一个 WebPlugin 实例，并生成一个 RenderLayer；
- 3、Android 客户端初始化一个对应的原生组件；
- 4、Android 客户端将原生组件的画面绘制到步骤2创建的 RenderLayer 所绑定的 SurfaceTexture 上；
- 5、通知 chromium 内核渲染该 RenderLayer；
- 6、chromium 渲染该 embed 节点并上屏。
这样就实现了把一个原生组件渲染到 WebView 上，这个流程相当于给 WebView 添加了一个外置的插件，这种方式可以用于 map、video、canvas、camera 等原生组件的渲染，对于 input 和 textarea，采用的方案是直接对 chromium 的组件进行扩展，来支持一些 WebView 本身不具备的能力。
即开即用
小程序像 Web 技术那样，他是把一份随时可更新的资源包（通过一定技术手段把js和相关资源打包）放在云端，通过下载到本地后解压，动态执行后即可渲染出界面。
