开发过一段时间小程序了，对于我们现在使用的业务来说，使用小程序开发上手很快，所以反思了一下，那么小程序的原理到底是怎么样的呢？我自己总结一下。
小程序的架构（官网原话）
当小程序基于 WebView 环境下时，WebView 的 JS 逻辑、DOM 树创建、CSS 解析、样式计算、Layout、Paint (Composite) 都发生在同一线程，在 WebView 上执行过多的 JS 逻辑可能阻塞渲染，导致界面卡顿。以此为前提，小程序同时考虑了性能与安全，采用了目前称为「双线程模型」的架构。
新的架构：
在 Skyline 环境下，我们尝试改变这一情况：Skyline 创建了一条渲染线程来负责 Layout, Composite 和 Paint 等渲染任务，并在 AppService 中划出一个独立的上下文，来运行之前 WebView 承担的 JS 逻辑、DOM 树创建等逻辑。这种新的架构相比原有的 WebView 架构，有以下特点：
界面更不容易被逻辑阻塞，进一步减少卡顿
无需为每个页面新建一个 JS 引擎实例（WebView），减少了内存、时间开销
框架可以在页面之间共享更多的资源，进一步减少运行时内存、时间开销
框架的代码之间无需再通过 JSBridge 进行数据交换，减少了大量通信时间开销
而与此同时，这个新的架构能很好地保持和原有架构的兼容性，基于 WebView 环境的小程序代码基本上无需任何改动即可直接在新的架构下运行。WXS 由于被移到 AppService 中，虽然逻辑本身无需改动，但询问页面信息等接口会变为异步，效率也可能有所下降；为此，我们同时推出了新的 Worklet 机制，用以高性能地构建各种复杂的动画效果。
本质
1:小程序一直以来采用的都是 AppService 和 WebView 的双线程模型，基于 WebView 和原生控件混合渲染的方式，小程序优化扩展了 Web 的基础能力，保证了在移动端上有良好的性能和用户体验。（官网的原话）
2:小程序的视图层和逻辑层是分开的。
逻辑层是JavaScript编写，运行在 JSCore 中，它用于处理数据并将其发送到视图层，并接收来自视图层的反馈。
视图层托管平台会将布局语言（例如 WXML）转换为 JavaScript 对象。 当逻辑层数据发生变化时，通过宿主平台提供的方法将数据从逻辑层传递到视图层，然后生成前后DOM的diff。 之后，差异将应用于原始 DOM 树并呈现更改后的 UI。
总之，js是单线程的，小程序是双线程，逻辑层和视图层（渲染层）是分开的，同时运行的。
通信
又因为小程序是双线程的，任何逻辑层和视图层的数据传递都是线程之间的通信，所以具有一定的延时，所以页面的更新就成了**异步操作。**
异步会使得各部分的运行时序变得复杂一些，比如在渲染首屏的时候，逻辑层与渲染层会同时开始初始化工作，但是渲染层需要有逻辑层的数据才能把界面渲染出来。
如果渲染层初始化工作较快完成，就要等逻辑层的指令才能进行下一步工作。
运行机制
小程序启动运行两种情况：
1.冷启动（重新开始）：用户首次打开或者小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动，即为冷启动。
2.热启动：用户已经打开过小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需要将后台态的小程序切换到前台，这个过程就是热启动。
