--- title: "关于微信小游戏与小程序框架的差异" author: "Perrin Yong" author_profile: https://www.pystone.net/profile/ published_by: "Perrin Yong" canonical: https://www.pystone.net/notes/wechat-minigame-vs-miniprogram-framework-diff/ type: note content_role: unspecified visibility: public id_stability: rename-stable source_path: "10-计算机、信息技术与工程/05-游戏图形与运行时/WebGL/关于微信小游戏与小程序框架的差异.md" content_hash: 36d8c7d2ab9f6c41a5c5de7e36af51e34d64fe4cc049a923f7b64b0c9244c35e knowledge_version: 224c990773de.5fa8af6e39fa site_commit: 224c990773de166d23a886306577dd90379529ce notes_commit: 5fa8af6e39fa3891d1b9b4832bfa6c4e0ecaaf0a --- # 关于微信小游戏与小程序框架的差异 # 关于微信小游戏与小程序框架的差异 ## 一、运行时架构差异 ### 小程序（Mini Program） * **视图层 + 逻辑层分离** * 视图层使用 WXML/WXSS，由微信原生引擎直接渲染原生组件； * 逻辑层用 JavaScript 运行在“App-Service”沙箱里，通过双进程（或多线程）与视图层通信。 * **页面栈管理** * 每个页面对应一个 `.js` + `.wxml` + `.wxss` 模块； * 框架维护一个全局的页面栈（最多十几级），提供 `wx.navigateTo`、`wx.redirectTo`、`wx.switchTab`、`wx.onPageNotFound` 等 API 做路由与生命周期管理。 ### 小游戏（Mini Game / Unity WebGL） * **单一 Canvas / WebGL 画布** * 只有一个 ``（或 WebGL 上下文），所有内容都由游戏引擎（Unity 编译后的 WASM + JS 框架）在这个画布上渲染； * 没有多页面概念，也没有原生组件渲染，所有 UI 和场景切换都由引擎负责。 * **纯脚本运行环境** * 逻辑和渲染全都在同一个 JS+WASM 运行时里，没有“视图层进程”与“逻辑层进程”之分； * 微信基础库并不注入小程序的页面栈路由 API，也不维护页面栈。 --- ## 二、技术栈与底层框架 | 维度 | 小程序 | 小游戏（Unity WebGL） | | --------- | ------------------------------ | --------------------------------- | | **UI 描述** | WXML + WXSS + 原生组件 | 引擎内部 Canvas/WebGL + 自绘 UI | | **渲染引擎** | 微信客户端原生渲染（基于 WebView 或原生控件） | Unity 引擎在浏览器/WebView 中渲染 | | **业务逻辑** | JavaScript（V8/JSC/Hermes） | Unity C# 编译成 WASM + JS 桥接层 | | **打包方式** | `.wxapkg` 包，资源独立管理 | WebGL 导出：`game.js` + `.wasm` + 资源 | | **生命周期** | `App.onLaunch`、`Page.onShow` 等 | `UnityLoader` 加载完成后，进入游戏循环 | --- ## 三、为什么小游戏没有页面跳转 API？ 1. **没有“页面”概念** 小程序的“页面”是微信为业务逻辑层提供的多页面路由模型；小游戏一旦启动，就只剩下一个被 Unity 接管的 Canvas，微信基础库不再提供页面栈，也就没有 `wx.navigateTo`、`wx.redirectTo` 这种面向多页面的 API。 2. **所有切换都在引擎内完成** 在小游戏里，关卡、菜单、子场景……都由 Unity 自己的 **场景管理** (`SceneManager`)、**UI 界面**（如 `Canvas` + `UGUI`）来做，根本不需要微信层面再做页面路由。 3. **简化运行时** 微信为小游戏精简了基础库，只保留渲染上下文、输入事件、资源加载等必要接口，去掉了与路由相关、原生组件相关的逻辑，以减小包体与提升性能。 --- ## 四、小游戏典型架构 1. **启动与加载** * `game.js`（由 Unity 导出）在 H5/小程序容器中插入一个 ``； * 加载 `.wasm`、资源包（图集、音频、Bundle）； 2. **引擎初始化** * Unity 在 JS 侧建立渲染循环，下载并初始化 WASM 中的 C# 运行时； * 拆分主线程 / Worker（多线程模式）加载资源。 3. **游戏逻辑循环** * Unity 主循环（`Update`、`FixedUpdate`、`Render`）全部跑在引擎层； * 脚本调用 `UnityEngine.SceneManagement.SceneManager.LoadScene()` 切换场景，不依赖微信 API。 4. **与微信基础库交互** * 只会用到：`wx.getSystemInfo`、`wx.request`、`wx.createInnerAudioContext`、`wx.triggerGC`、少量性能调优 API； * 无页面栈、无原生 UI，所有交互、输入、UI 都在 Unity 内部处理。 --- ## 五、页面与 Unity 场景的关系 * **页面（小程序）** * 如果你把 Unity WebGL 嵌在**小程序页面**里（而非小游戏模式），那该页面只是一个承载 `` 或 `` 的容器； * 小程序层可以通过 `wx.miniProgram.postMessage` 或自定义 JS 接口与 Unity 交互。 * **Unity 场景** * 在引擎层，场景（Scene）是关卡、UI 界面、逻辑分区的集合； * 场景切换不经过微信层，只在 Unity 内部完成，彼此隔离。 --- ### 小结 * **小程序**：多页面、原生组件、微信负责渲染与路由； * **小游戏**：单 Canvas、游戏引擎全权负责渲染与逻辑，不存在微信层面的页面栈； * **页面跳转**：仅属于小程序的业务模型，小游戏省略了这层、依赖引擎场景管理； * **嵌入关系**：在小程序模式下，你可把 Unity WebGL 当作一个“页面”载入；在小游戏模式下，Unity 完全接管，微信只提供最底层的运行时支持。 这样就能理解为什么在小游戏里永远拿不到 `wx.navigateTo` / `wx.redirectTo`，也不需要它们来做场景切换。