小程序（微信）运行机制
小程序（以微信为例）的核心运行机制是双线程架构 + 原生桥接通信 + 生命周期管理，它将逻辑与渲染彻底分离，通过微信客户端（Native）做安全沙箱与能力调度。
一、核心架构：双线程模型（最关键）
小程序采用逻辑层 + 渲染层分离的双线程设计，区别于传统网页的单线程（JS与渲染互斥）。
1. 逻辑层（App Service）
- 运行环境：独立的 JSCore 线程（非浏览器环境），全局唯一。
- 负责内容：执行
.js 业务逻辑、数据处理、网络请求、调用微信 API（wx.request/wx.navigateTo 等）。
- 关键限制：无 DOM/BOM，不能直接操作
window/document，只能通过框架 API 与视图通信。
- 基础库：注入小程序逻辑层基础库，提供
App/Page 生命周期、setData 等能力。
2. 渲染层（View）
- 运行环境：每个页面对应一个独立 WebView（iOS: WKWebView；Android: X5/系统 WebView）。
- 负责内容：解析
.wxml（结构）与 .wxss（样式），渲染 UI、响应用户交互（点击/滑动）。
- 关键限制：不执行复杂 JS，仅做视图渲染与事件捕获，保证流畅。
- 基础库：注入渲染层基础库（Exparser），提供组件系统、虚拟 DOM、数据绑定。
3. 通信机制：Native Bridge（原生桥）
逻辑层与渲染层不能直接通信，所有数据/事件必须通过微信客户端（Native）中转：
- 数据更新：逻辑层调用
setData → 数据序列化 → Native 转发 → 渲染层更新视图。
- 事件触发：用户点击 → 渲染层捕获 → Native 转发 → 逻辑层执行事件回调。
- 能力调用：逻辑层调用微信 API（如支付、定位）→ Native 执行 → 结果返回逻辑层。
二、启动与生命周期（冷/热启动 + 状态流转）
1. 启动类型
- 冷启动（完整流程）：首次打开、小程序被销毁后打开。
流程：下载代码包 → 解压 → 初始化双线程 → 执行
App.onLaunch → 加载首页 → 渲染。
- 热启动：小程序在后台/挂起状态被重新打开。
流程：直接唤醒逻辑层 → 执行
App.onShow → 渲染层恢复页面 → 进入前台。
2. 状态流转
- 前台：用户可见、可交互，JS 线程正常运行。
- 后台：用户退出（胶囊/返回/切微信），小程序未销毁，JS 短暂运行（约 5 秒）。
- 挂起：后台 5 秒后，JS 线程暂停，内存保留，无法执行代码。
- 销毁：长时间未用、系统内存不足时，小程序被回收，下次打开需冷启动。
3. 生命周期钩子（核心）
- App 全局：
onLaunch（冷启动）→ onShow（前台）→ onHide（后台）。
- Page 页面：
onLoad（加载）→ onShow → onReady（渲染完成）→ onHide → onUnload（卸载）。
三、代码包与更新机制
- 代码包：小程序代码（
app.json/pages/components）打包为一个或多个分包，首次冷启动下载。
- 更新策略：
- 冷启动时，微信检查版本，有更新则异步下载，下次冷启动生效（避免阻塞当前启动）。
- 强制更新：可通过
wx.getUpdateManager 监听并提示用户重启。
四、与传统网页/原生 App 的关键区别
| 特性 |
传统网页 |
微信小程序 |
原生 App |
| 线程模型 |
单线程（JS/渲染互斥） |
双线程（逻辑/渲染分离） |
多线程原生调度 |
| DOM 操作 |
直接操作 document |
禁止，通过 setData 驱动 |
原生控件直接操作 |
| 运行环境 |
浏览器 |
微信客户端（JSCore + WebView） |
系统原生环境 |
| 能力边界 |
浏览器 API |
微信开放 API（支付/定位/扫码等） |
系统全能力 |
| 启动速度 |
依赖网络与缓存 |
冷启动下载包，热启动秒开 |
安装后本地秒开 |
五、性能与限制要点
- 通信开销：双线程通信有序列化/反序列化成本，避免频繁/大量
setData。
- 后台限制：后台 5 秒后挂起，仅音乐、定位等特殊场景可保活。
- 分包优化：主包 ≤ 2MB，分包按需下载，提升冷启动速度。
- WXS 优化：视图层可运行 WXS，减少跨线程通信，提升交互流畅度。