渲染方式
目前前端主流的三种渲染方式
- web技术渲染
- Hybrid技术进行渲染（混合渲染）
- native技术渲染（原生渲染）
小程序在一开始就摒弃了使用原生技术进行渲染，因为如果选择了这种方式进行渲染的话后期的迭代和更新只能跟着微信app来进行，非常的不方便
小程序需要的是那种跟web技术一样，可以随时在远端服务器有一份资源可以进行下载和更新。但是如果选择了web技术来渲染，也有个致命的缺陷：JavaScript的加载会影响到UI层的渲染。而小程序在一开始的定位就是快（加载快 渲染快）所以它也不会选择web技术进行渲染
最后小程序选择了Hybrid模式进行小程序的渲染。同时使用webview控件和原生来进行混合渲染，界面使用web技术进行渲染，然后辅以大量的接口来扩展使用原生的一些功能。而且小程序不是就使用一个webview控件来进行渲染，一个小程序页面会对应一个webview控件
什么是webview
webview是内置在native中的一个控件，可以把它看作是一个微型的浏览器，只不过它没有导航栏，地址栏这些东西。它可以渲染展示我们的html5页面，可以让原生的app在内部打开h5页面
安全性
由于web技术是灵活开发的，js可以随时使用对应的接口来跳转网页，访问DOM进行操作和修改等。如果仅仅是针对这些不安全性的接口进行一一屏蔽的话，工作量会非常的大而且不能保证后期web不会更新出新的东西出来。所以小程序是将js代码放在一个沙箱里面进行运行，只提供js的编译运行的环境。不提供任何其他的浏览器相关的接口。
如何实现呢？其实可以使用另一个线程来运行js，相当于HTML5里面的WebWorker一样开启一个新的线程。 这样子，我们的小程序就变成使用双线程的模式来进行渲染和加载我们的小程序。并且这样子也解决了js会阻碍ui渲染的缺点
双线程模式
- 渲染层：这个线程都是小程序界面相关的渲染工作，通过逻辑层的代码去控制渲染哪些界面
- 逻辑层：创建了一个单独的线程去执行js代码，在这个线程下执行的都是有关小程序业务逻辑的代码
而渲染层和逻辑层的交互通常是两个线程的交互，所以都是异步进行交互的
而这两个层的交互是通过jsBridge技术来进行交互的，我们的H5页面之所以能使用手机上面的一些功能（唤起照相 扫码 上传图片等）都是通过jsBridge来进行。而且两个线程的事件交互 数据交互也是通过JsBridage来进行的
JsBridge就跟它的名字一样就是一座桥梁，打开native和web两端的门
JsBridge有两种方式
- 拦截对应的请求：app端拦截住web端的URL SCHEME的请求，并且进行处理调用对应的功能
- 注入：一次性将原生端的功能注入到js的根元素上面，放js可以直接使用对应的接口来进行操作
总结：小程序通过webview和原生的混合渲染来加载和运行小程序，然后通过JsBridge来扩展我们的小程序的功能和两个小程序之间的交互
