背景
在我理解的小程序里是依赖于宿主环境（微信，支付宝）的快捷应用，或者说特殊网页。小程序之于宿主环境的作用在于丰富整个宿主环境微信的功能，对于整个微信的生态有着指数级的增长帮助，而微信之余小程序最为重要的是提供了快捷入口和用户流量，第三方公司开发成本更小。 用一个不恰当的比喻：微信是一个王国，管控着众多小程序（商城类的（美团），政府信息类（我的长沙），餐饮类的（喜茶等））。
什么是双线程架构？
一条线程负责处理逻辑层一条线程负责处理渲染层。线程之间通过native层通信。
为什么要选择双线程架构？
-
1.最重要的点： 这个一个基于安全于管控的方案
-
2.其次：比纯web更好的交互体验，
-
3.原生版本迭代更为便捷
小程序选择的是webview+原生组件的形式，hybrid方式，既享受到了webview页面的低门槛和在线更新，🈶️可以使用部分流畅的native原生组件，并且最重要的是空对开发的内容进行一定程度按的管控，同时在安全问题从设计层面就予以了解决。
为什么说小程序有着相对较好的交互体验呢？
首先说小程序的交互体验肯定是比不上原生app的，app的响应速度肯定是最快的，相对指的的h5 web，网页开发的渲染线程和脚本线程是互斥的，二者是共享一个线程的，也就是说在运行脚本线程的时候可能会让页面失去响应，所以这也是为什么我们在开发网页的时候需要将script脚本的引入放在body的后面然后winow.onload去知道已经渲染完的节点。而在小程序中渲染线程和逻辑（脚本）线程相互独立，不能直接干扰对方，渲染线层和逻辑线程可以同时运行。联想一下，这是不是从设计层面就规避了react16推出fiber架构所为了解决的最重要的问题问题（一次大的更新任务会长时间占据着当前线程的资源，导致页面无法响应带来的交互问题！）。
在版本迭代上小程序又有哪些优势呢？
我们都知道原生渲染的体验优势，这也是为什么会出现夸端框架的weex,react native ，flutter的框架去直接生成原生应用的方式来进行开发，但是小程序是依赖于宿主环境的，小程序的发版不可能说随着微信的大版本去迭代，如果是这样我觉得就和小程序分质治理的理念不合了，也会有很多的弊端，并且也不能发挥web的优势。
那么web的优势是什么呢？--答案是在线更新。--（有啥bug随时修完！甚至产品经理都感知不到！），小程序也是在线更新，但是小程序比h5多了另外一项优势--底层资源的动态注入。h5的脚本资源都是通过请求获取的，获取完了之后还要解析，然后再去运行实际的业务层面的代码。而在小程序中在初始化的时候，native(原生层)就会将WXSDK(设备信息，hls流视频处理工具，基础版本库等)动态的加载注入到新打开的页面中，由于小程序的pageFrame（快速渲染设计）技术，在后续打开的页面中，直接读取缓存中准备数据，直接省去的解析的过程。小程序这些优化直接的效果是（包体积变小，减少了网络请求sdk的时间。）
小程序现在版本迭代的模式下，忽略微信审核的环节的话，基本上可以做到99%用户的在线更新。但是并不完全，在有新版本迭代的情况下，虽然微信不支持强制更新，但是我们可以在交互层面上，强提示交互让用户更新。但是不知何种原因（估计是用户微信版本和小程序基础库版本的问题）无法做到100%,这是从后台监控的sdk所反馈的数据。
：问题： 这也是我们在实际开发过程中遇到的问题，小程序的很多能力是依赖于微信的基础版本库的，在小程序的官方文档中常常会更新很多新的api，新的好用的组件，类似skyline渲染引擎，最近新推出的长列表组件等等，这些一般都依赖于较高版本的基础版本库，而用户手机微信中的基础版本开众多版本分云，从开发层面相当于要为新api的版本之上和版本之下的用户都要做兼通，成果过大，而且在后台监控的数据中版本较低的用户基本能占到百分之10，那么是否会为了使用新的更为好用的一些api而去取舍调这百分之10的用户呢？我相信答案是否定的。
为什么说双线程架构最重要的是安全与管控呢？
在我看来，双线程架构最重要的因素是安全与管控。小程序是依赖于宿主环境的，也就是说小程序流量与能力都来源于宿主环境，所以说不可避免的要宿主环境的制约，如果是某个小程序涉嫌一些违法的勾当并造成较大范围的影响，宿主环境肯定也是承担一定的法律责任。所以这也是为什么小程序getUserInfo这接口经常动来动去的原因吧。所以说小程序发版要经过微信的详细审查，要让微信知道你这小程序大概都干了些啥，是否违法。微信的监控力度还是很大的，像茶颜悦色很多次的营销推广活动都被封了，有一定程度的恶心分享都会被检测到，这也让很多公司的营销产品苦不堪言！
而双线程架构对安全与管控又起到了哪些作用呢？h web技术中，我们可以在脚本中随意的去操作dom,改变其中的内容，可以随意的跳转网页。所以web网页也容易遭到crsf攻击，发起一些都有特殊目前的请求。也可能被往页面的中注入脚本操作dom的xss攻击的等。但是小程序的逻辑层是的运行环境是一个js沙箱环境，小程序使用的的javascriptCore/V8框架作为作为解释引擎，阻止开发者使用一些操作dom的api，跳转网页的api,还有动态执行脚本的api(eval等)，（包括现在你在项目中的引入的实现eval能力的sdk都会被检测出来！）等等。小程序不支持动态的载入脚本，每个wxml元素在编译时就会过滤掉不支持的危险属性。并且从逻辑层不能操作渲染层的dom节点，只能通过setData方式去传递数据。所以说从设计层面就解决了xss攻击。
