记一下为什么小程序非要使用自己封装的标签
核心原因就是为了解决管控与安全问题
基于Web技术来渲染小程序存在一些问题
- 不可控因素
- 安全风险
Web技术是非常开放灵活的，我们可以利用JavaScript脚本随意地跳转网页或者改变界面上的任意内容。
小程序原本定义了一套内置组件以提供统一的体验，用户进入小程序时，小程序代码包会被拉到本地使得小程序可以离线浏览（只要小程序开发者把一些应用数据缓存到了本地），但要是开发者通过JavaScript 把渲染小程序的 WebView 跳转到其他在线网页，这个体验就变得非常糟。
提供一种可以展示敏感数据的组件（这些数据只能被展示，开发者并不能拿到数据），若开发者可以通过JavaScript 操作界面（DOM树），从而直接获取这些敏感数据，那小程序毫无安全可言。
这就导致必须阻止开发者使用一些浏览器提供的，诸如跳转页面、操作DOM、动态执行脚本的开放性接口。一个一个禁止势必会进入一个攻防战，因为 JavaScript 的灵活性以及浏览器接口的丰富性，很容易遗漏一些危险的接口，而且就算被我们找到所有危险的接口，也许在下一次浏览器内核更新而新增了一个可能会在这套体系下产生漏洞的接口，这样还是无法完全避免。
要彻底解决这个问题，我们必须提供一个沙箱环境来运行开发者的JavaScript 代码。这个沙箱环境不能有任何浏览器相关接口，只提供纯JavaScript 的解释执行环境，那么像HTML5中的ServiceWorker、WebWorker特性就符合这样的条件，这两者都是启用另一线程来执行 JavaScript。但是考虑到小程序是一个多 WebView 的架构，每一个小程序页面都是不同的WebView 渲染后显示的，在这个架构下我们不好去用某个WebView中的ServiceWorker去管理所有的小程序页面。
得益于客户端系统有JavaScript 的解释引擎（在iOS下是用内置的 JavaScriptCore框架，在安卓则是用腾讯x5内核提供的JsCore环境），我们可以创建一个单独的线程去执行 JavaScript，在这个环境下执行的都是有关小程序业务逻辑的代码，也就是我们前面一直提到的逻辑层。而界面渲染相关的任务全都在WebView线程里执行，通过逻辑层代码去控制渲染哪些界面，那么这一层当然就是所谓的渲染层。这就是小程序双线程模型的由来。
