WebView与native：

WebView：android中的一个重要控件，用来展示一个web页面。使用webkit引擎，4.4版本之后，直接使用Chrome作为内置网页浏览器。（理解为浏览器上浏览H5页面即可）

native：理解为我们android/ios上的App

WebView的体验：

WebView的性能，给人最直观的莫过于：打开速度比native慢。

一个webview的打开会经过以下阶段（无反馈，白屏，loading，展现）

小程序的css样式跟普通web一模一样，但是体验却比webView要好很多，为什么？

界面渲染机制：

目前，页面渲染的方式主要有三种：

1. Web 渲染。

2. Native 原生渲染。

3. Web 与 Native 两者掺杂，也即我们常说的 Hybrid 渲染。

小程序最终的呈现形式，是 WebView + 原生组件，Hybrid 方式

由于小程序的宿主是微信，如果用纯客户端原生技术来编写小程序，那小程序代码需要与微信代码一起编包，跟随微信发版本，这种方式跟开发节奏必然都是不对的。

如果用纯 Web 技术来渲染小程序，在一些有复杂交互的页面上可能会面临一些性能问题。这是因为在 Web 技术中，UI渲染跟 JavaScript 的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源。

因此小程序选择了 Hybrid 的渲染方式，可以用一种近似 Web 的方式来开发，并且还可以实现在线更新代码。同时，引入原生组件有以下好处：

扩展 Web 的能力。比如像输入框组件（input, textarea）有更好地控制键盘的能力

体验更好，同时也减轻 WebView 的渲染工作

绕过 setData、数据通信和重渲染流程，使渲染性能更好

双线程机制：

小程序是双线程设计，即视图渲染与业务逻辑分别在运行在不同的线程中。这个设计主要是解决传统web技术中的一个痛点：

传统的web页面开发渲染线程和脚本线程是互斥的，长时间的脚本运行可能会导致页面失去响应或者白屏，体验糟糕。

小程序为了更好体验，将页面的渲染线程和脚本线程分开设计在不同线程中执行，具体实现：

1.视图view层在webview中渲染，一个页面对应一个webview

2.业务逻辑Appservice层运行在同一个JSCore线程中，具体ios是JavaScriptCore，android是X5 JSCore，开发者工具是webview中；

这样解决了长时间的脚本阻塞页面渲染的情况，但是也带来一些新的问题：

1. 天生的延迟，线程间要通信（双线程通过native通信）

2. 业务逻辑层因为运行在JSCore中无法访问DOM和BOM的api；（管控和安全，阻止开发者使用一些浏览器提供的，诸如跳转页面、操作 DOM、动态执行脚本的开放性接口。）

双线程通信：

逻辑层和渲染层的通信会由 Native （微信客户端）做中转，逻辑层发送网络请求也经由 Native 转发。

于是我们也就可以把 DOM 的更新通过简单的数据通信来实现

1. 在渲染层把 WXML 转化成对应的 JS 对象。

2. 在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。

3. 经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。

我们通过把 WXML 转化为数据，通过 Native 进行转发，来实现逻辑层和渲染层的交互和通信。而这样完整的一套框架，基本上都是通过小程序的基础库来完成的。

小程序的基础库：

小程序的基础库是 JavaScript 编写的，它可以被注入到渲染层和逻辑层运行。主要用于：

1 在渲染层，提供各类组件来组建界面的元素

2 在逻辑层，提供各类 API 来处理各种逻辑

3 处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑

由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。这样可以：

降低业务小程序的代码包大小

可以单独修复基础库中的 Bug，无需修改到业务小程序的代码包

小程序架构设计