MiniApp 标准化白皮书版本 2

MiniApps 的普及有助于让共享单车成为一种无缝服务，而不是一个笨重的 应用。

• 用户在其移动设备上选择任一 MiniApp 平台，该平台通常是一个用户已经登录的超级应用；
• 用户在该超级应用中扫描贴在共享单车上的二维码标签；
• 托管应用将自动导航到共享单车 MiniApp，并立即解锁 单车；
• 到达后，用户在 MiniApp 上锁车；
• 交易完成，支付详情消息会发送给用户。

对于用户而言，MiniApps 可以从几个方面带来便利：

MiniApp 开发者可以简单地使用 HTML/CSS/JavaScript 作为编程语言，但 MiniApp 更灵活，因此它擅长在日常工作中快速开发复杂功能。

该 MiniApp 试图用 AI 技术构建一个 AR 动物园来识别动物。开发者可以 通过添加一些提供原生能力或高级功能访问能力的组件或 API，轻松做到这一点（例如，图像识别、AR 3D 动物模型渲染、用于语音 合成的语音 API，以及由地图 SDK 提供的 AR 导航）。

MiniApps 可以被搜索引擎、托管 应用中的 MiniApp 商店或二维码发现。

对于开发者而言，开发 MiniApps 的激励非常明显。

MiniApp 的目标之一是连接不同平台上的信息和服务，因此 它非常适合 IoT 应用，例如智能汽车、语音控制音箱和智能电视。

如今，可以转换一些 MiniApps 以适配车载屏幕和系统。此外，一些 MiniApp 厂商已经构建了专为车载系统设计的 MiniApp 平台，以帮助 向各种车型分发或升级应用。这将数百万 Web 开发者带入了 汽车应用生态系统。

这些汽车 MiniApps 可以服务许多用户场景，包括加油、洗车、 电子不停车收费、保险、餐厅预订或娱乐。例如，当 系统检测到剩余燃油少于 20% 时，可以向车主推荐一个加油 MiniApp。用户可以获得最近加油站的信息并前往那里完成 加油，包括在 MiniApp 内完成支付，实现“加油不用下车”。

IoT 设备正在成为运行 MiniApps 的另一种载体。面向 IoT 的 MiniApp 旨在实现 多个 IoT 设备平台和操作系统之间的互操作性。通过 引入面向 IoT 的 MiniApps，开发者无需处理多个 IoT 设备平台和 IoT 操作系统之间的 差异，只需要专注于 IoT 设备上的应用开发。

一个示例是 HVAC（供暖、通风和空调） 应用开关面板，它具有屏幕和几个物理按钮。在这种情况下，通过 引入面向 IoT 的 MiniApp，开关面板的屏幕 UI 可以使用 Web 技术来设计和开发，以显示 HVAC 信息。例如，可以显示由 物理按钮输入的目标温度值以及测得的实时温度值。

另一个示例是带触摸屏的智能音箱。在这种情况下，通过引入面向 IoT 的 MiniApp， 智能音箱的触摸屏 UI 可以使用 Web 技术进行设计和开发，用于播放 音乐和视频、控制家中的 IoT 设备以及在线购物。

与运行在手机上的 MiniApps 不同，手机上的用户交互依赖于触摸屏，而 运行在电视上的 MiniApps 的用户交互切换为电视遥控器面板键盘加电视屏幕 焦点。

通过面向电视的 MiniApp，用户可以通过电子商务 MiniApp 在电视上购买商品。

此外，用户还可以通过游戏 MiniApps 在电视上玩游戏。

在 MiniApp 中，视图层通常与逻辑层分离。

视图层负责渲染 MiniApp 页面，包括 Web 组件和原生 组件的显示，这可以被视为混合渲染。例如，某些 Web 组件可能 不受 WebView 支持或存在性能限制，因此 MiniApp 也依赖原生 组件，例如地图、视频等。

逻辑层使用 JavaScript Workers 实现。worker 负责 MiniApp 的事件 处理、API 调用和生命周期管理。

扩展的原生能力通常来自托管原生应用或操作系统，包括支付、文件 处理、图像扫描、电话呼叫等。这些特性通过特定 API 调用。当 MiniApp 调用原生 API 时，它会通过 JavaScript Bridge 将 API 调用传递给扩展的 原生能力以供进一步处理。它再通过 JavaScript Bridge 从扩展的原生能力获取 结果。

worker 为每个 Render 建立连接，将需要渲染的数据传输给 Render 以供进一步处理。

如果某个事件由 MiniApp 页面中的组件触发，该页面的 Render 会将事件发送给 worker 以供进一步处理。同时，Render 会等待 worker 发送的数据，以重新渲染 MiniApp 页面。

渲染可以被视为无状态，所有状态都将存储在 worker 中。

分离视图层和逻辑层的好处包括：

• 非常便于多个 MiniApp 页面之间的数据共享和交互。
• 在 MiniApp 生命周期内拥有相同的上下文，可以为来自原生应用开发背景的 开发者提供类似的编码体验。
• 渲染和 JavaScript worker 的分离及并行实现，可以避免 JavaScript 执行影响或拖慢页面渲染的情况，这有助于提升 渲染性能。

MiniApp 平台提供许多组件，帮助开发者构建精美的 UI，包括基本 组件，如 view、form、image，以及高级组件 如地图。

MiniApp 厂商也为开发者提供许多 API，以访问 Web 和原生 能力，包括 UI 显示 API、图像处理 API 等基础接口，以及 用户账号 API、地图 API 和支付 API 等高级接口。

API 通常与组件协同工作。当用户点击 MiniApp 页面上的某个组件时， 它会调用相关 API 来完成用户交互，并在需要时刷新当前 MiniApp 页面。

为了获得与原生应用类似的用户体验，MiniApp 资源通常会被打包 在一起。下载并安装 MiniApp 包后，MiniApp 所需的所有静态资源（即页面 模板、CSS、JavaScript 文件和其他文档）会保留在用户的 设备上。这些资源在下一次更新之前始终可用，无需任何重复下载。

MiniApp 包是一个压缩的 ZIP 归档文件，包括：

• 位于包根目录中的配置文档。配置文件应当 包括：
  • 整个 MiniApp 的总体描述；以及
  • 页面的描述，包括它们对应的路径和配置，用于 页面设置和打开。
• 一个应用级逻辑文件，其中包含处理应用级生命周期回调的脚本。
• 一个或多个文件，包含用于页面结构的模板代码、用于页面 样式的 CSS 样式表，以及用于页面逻辑的 JavaScript 代码。
• 用于完整性验证的数字签名支持。

为了在搜索和执行时定位特定的 MiniApp，MiniApp 必须在平台上具有 包名或标识符。还需要一个图标用于用户识别。

除了 MiniApp 页面之外，MiniApps 还可以显示为信息片段或 MiniApp 小组件。在这种形式下，开发者可以将其服务和/或内容放入各种宿主场景， 称为宿主环境（例如助手、设备全局搜索等）。此特性 将 MiniApp 的服务和内容与具体场景连接起来，为用户提供 更多便利。

例如，当用户购买旅行火车票时，智能助手上的 MiniApp 小组件会立即显示火车的最新状态。 用户可以点击该小组件，并跳转到全屏 MiniApp 页面以查看更多详细 信息。

与 MiniApp 页面类似，小组件也由 URI scheme 描述。宿主环境通过 URI 路径指定要加载的 MiniApp 包及对应小组件，并通过 URI 查询参数将数据传递给小组件。小组件加载后，会在 宿主环境中显示和渲染。来自宿主和小组件的数据，以及来自不同小组件的数据 都会被隔离，以确保安全性和独立性。

在许多场景中，小组件可以打开 MiniApp 页面以执行更复杂的操作。在这种情况下， 小组件通常需要与其对应的 MiniApp 共享数据（例如，保持一致的登录 状态）。因此，小组件和 MiniApp 的数据可以由双方访问。换 言之，MiniApp 小组件和页面拥有相同的数据访问权限。

小组件的目标之一是让用户忘记传统应用概念，并真正以服务的形式满足 用户需求。因此，除了所有应用调用路径外，小组件还可以 在不同场景中通过不同方式触发，例如文本关键词、语音 分析、图片识别、扫码和事件意图。

注：小组件由中国市场中的快应用实现。

发现、打开和访问 MiniApps 有多个入口。与多 WebView 中的 Web 内容不同，同一个 MiniApp 只会创建一个实例，因此 MiniApp 会在全局范围内以一致方式保持其状态和 数据。例如，当一个用户第一次通过二维码入口打开并登录 MiniApp 后， 当用户下次从 MiniApp 商店等其他入口返回时，用户仍将保持登录状态。

MiniApps 的入口包括但不限于：

• MiniApp 市场
• 搜索引擎
• 智能助手
• 二维码
• SMS/文本
• 物理对象（带 AI）
• 浏览器
• 日历项
• 语音消息（带 AI）

MiniApps 尝试通过一些在实践中被证明有效的机制来提升其性能和用户体验。

打包

借助 MiniApp 的构造器，用户只需要在第一次打开 MiniApp 时下载包，之后 MiniApp 中的静态资源（例如页面、 脚本和 CSS）无需再次下载，从而使后续页面的加载和 跳转更加高效。此特性提升了用户体验并 节省了网络流量。

同时，MiniApp 具有预下载机制，可以提前下载 MiniApp 包， 或者针对首个页面单独预下载，并在下载过程中并行执行流式 解压，以尽量减少 MiniApp 启动 阶段的耗时，并平衡首次打开时首页性能的损失。

多个渲染视图

MiniApp 使用原生页面栈来管理渲染视图之间的关系，页面切换由 原生代码驱动。因此，页面中的手势操作、页面之间的 切换可以获得与原生应用完全相同的流畅体验。

由于视图层和逻辑层相互隔离，视图层可以独立 渲染。在不被 JavaScript 逻辑代码阻塞的情况下， 页面渲染速度可以得到极大提升。

预构建和运行时环境复用

MiniApp 的运行时环境通常会在启动 mini-app 之前预构建，从而减少 启动 MiniApp 的时间。预构建内容包括渲染视图、静态资源、 开发者定义的预取请求以及 MiniApps 运行时容器。MiniApp 激活后，会接管预构建的渲染视图，然后我们会继续 将新的渲染视图预构建到缓存池中以供下一个使用。渲染 视图数量存在限制。当任何渲染视图被关闭或数量限制被超过时， 最早打开的渲染视图将被销毁。当 MiniApp 应用退出时，运行时 会被销毁，并且应用环境和资源可以被复用。

预定义组件和 API

MiniApp 平台提供非常丰富的组件和 API。 这些组件和 API 通常经过良好设计，以满足开发者的性能 需求。

JavaScript 框架预设和热重载

MiniApp 的运行时环境包含两大部分：由 原生代码提供的基础能力，以及一个框架，其中包括开发者 API 和一些由 JavaScript 实现的组件。JavaScript 框架内置于原生应用中，并会在执行 MiniApp 之前 预先加载到 MiniApp 运行时环境中。JavaScript 框架可以热重载（使用过程中重新加载），这为 提升性能带来了许多可能性。

MiniApp 平台为用户登录 MiniApp 提供了多种方式。如果用户已经 通过身份认证登录到平台，则平台的登录信息可以与 MiniApp 共享， 快速实现 MiniApp 自身账号 系统与平台账号系统的互通，使 MiniApp 的访问流程更加顺畅。

例如，传统的 SMS 验证登录流程更耗时；用户需要 先手动输入手机号，然后在收到 SMS 后输入验证码才能登录。MiniApp 的优势在于，开发者可以使用平台提供的组件 / API， 安全且便捷地获取用户手机号，提示 用户授权使用手机号进行一键登录，这使 整个流程对用户而言更加简单，也降低了开发者获取用户信息的成本。

MiniApp 分包是一种用于改进 MiniApp 包开发过程的构建机制。它 帮助开发者将不同业务模块划分到不同子包中。

对于开发者：MiniApp 默认具有主包；它包含启动页面文件和 公共资源。子包是一种构建类型，可灵活划分开发者的业务 模块。用户可以在按需加载不同子包后打开特殊页面。

对于用户：当用户启动 MiniApp 时，默认会下载主包，并 启动主包中的页面。如果用户需要打开子包中的页面， MiniApp Runtime 将开始下载并加载子包，并启动子包页面。

通过这样的分包构建机制，在多个 团队共同开发时更有利于解耦和协作。当用户使用 MiniApps 时，分包机制可以提高 MiniApp 首页的 加载速度，按需加载子包，并优化用户体验。

在 MiniApp 中，add-on/extension 是一个封装模块，可向 现有 MiniApp 添加特定功能，它可以是组件、JavaScript 模块或页面。add-on/extension 只能在 MiniApp 中执行，而不能单独运行。开发者可以像开发 MiniApp 一样开发 add-on/extension，并将其上传到 MiniApp 平台，以供其他 MiniApps 复用。

MiniApp 支持 add-on/extensions 以：

• 通过代码复用降低开发成本，并帮助开发者轻松添加新特性
• 在开发者无感知的情况下自动更新功能
• 通过不加载未使用功能来减小 MiniApps 的包大小

add-on/extension 机制降低了开发 MiniApps 的门槛，并将更多开发者 带入 MiniApp 生态系统。

MiniApp 是 Web 渲染和原生渲染的混合解决方案。如果有一种好 方法可以结合来自 Web 和原生的渲染结果，那将会很棒。

提议：MiniApp 需要一个标准化 API，以帮助将原生渲染结果集成到 Web 渲染结果中。

MiniApp 希望在页面切换期间提供过渡动画，使用户可以获得 与使用原生应用时类似的体验，但现在几乎不可能做到这一点。

提议：MiniApp 需要一个 API，用于在 MiniApp 页面切换期间添加过渡动画。

MiniApp 可以通过标准化分发格式，为多个 MiniApp 托管平台形成一套包和解析约定。 目前，每个 MiniApp 托管平台都提供不同的 开发工具（不同的打包方式），并且 MiniApp 在不同的 MiniApp 托管环境中会被不同地解析。

提议：MiniApp 实际上是在分发 过程中打包（压缩）的文件集合。我们可以用统一的文件后缀描述 MiniApp（.ma），并指定如何创建 .ma 文件以及如何解析 .ma 文件。

对于 MiniApp 中的热门页面，它可能会被另一个 MiniApp 引用，并且期望在用户访问时 能够被准确唤起。

提议：定义一个标准化协议（URI scheme）来访问 MiniApp。

类似 Android 小组件或 Apple dashboard，用户可以直接获取信息和/或完成任务， 而无需打开任何 Web 或应用页面。MiniApp 小组件可以显示在 Web 浏览器之外的环境中，例如桌面或 dashboard。

提议：

• MiniApp 小组件可以显示在宿主环境中，无论是 WebView 还是原生应用 页面。宿主环境通过对应的 URI 路径加载小组件，该路径描述 一个包和小组件页面。
• MiniApp 小组件可以访问本地数据或服务器数据。同时，MiniApp 小组件可以 与同一包中的 MiniApp 通信。
• MiniApp 小组件应当是交互式的，这意味着它应当响应任何用户 行为/交互。MiniApp 小组件应当具备打开 Web 或应用页面的能力。

MiniApp 需要知道 MiniApp 页面可交互时间（TTI）何时完成。

提议：一个标准化事件，用于通知 MiniApp 页面可交互时间已经 完成。

3D 模型凭借其丰富细节变得越来越流行。结合 AR，它们将 提供比 2D 更好的用户体验。业务案例可能包括在线购物、 广告、教育等。然而，当前 Web 缺少一种标准且便捷的方式来处理 3D 模型。在本文档中，我们提议定义一个 HTML 标签，用于直接处理 3D 模型， 类似于我们使用相应 HTML 标签处理音频、视频和图像的方式：

• 360 视图

  用户可以通过手势从不同角度查看 3D 模型。并且 3D 模型也可以放大/ 缩小。它可以全屏查看，也可以嵌入网页中，与 其他 HTML 内容一起显示。

• 使用 AR 查看

  用户可以借助相机将 3D 模型放置在真实世界中。用户可以指定不同的 位置来放置该模型。

提议：一个 <xmodel> 元素，用于在 Web 上指定 3D 模型并支持 带 AR 的交互式 3D 内容。

人脸跟踪可用于许多 3D 场景。

实时视频中的人脸特效

在实时视频中的人脸上添加特效。这些特效包括全屏滤镜、瘦脸 和妆容、2D 贴纸、3D 头饰等。大多数这类特效都高度依赖来自视频源的实时 人脸跟踪。

游戏

游戏开发者可以基于跟踪到的人脸设计游戏策略，例如当眼睛眨动时触发特定 游戏逻辑，或检查下落的水果是否进入张开的嘴巴。

虚拟试妆

让用户在产品页面试用口红、眼影、眼镜和帽子，帮助他们做出决定。

提议：一个 Face Tracking API 使用视频元素作为输入，并每帧更新人脸跟踪输出， 其包括：

• 每张人脸的边界框
• 每张人脸的 4x4 姿态矩阵
• 归一化的 (x, y) 特征点
• 包括顶点、法线、纹理坐标的人脸几何数据

手势可以用于视频特效和 AR/VR 游戏场景，使应用更具表现力和 交互性。

提议：一个高级 API，用于跟踪手部运动并获取手部轮廓。

MiniApps 中有一些 AR API 是我们希望迁移到 Web 的，因为它们有助于在游戏、3D 模型预览和互动广告中提供更好的 AR 体验。

提议：提供基于 ARCore 和 ARKit 的低级 AR API，其中包括：

用于世界跟踪的相机视图矩阵

提供移动电话空间位置和朝向的 4x4 视图矩阵，开发者可以 用它在自己的 3D 虚拟世界中实时更新相机矩阵。 从而可以将真实世界的位置与 虚拟世界中对象的位置关联起来。

平面检测和跟踪

检测真实世界中的平面并实时跟踪这些平面。提供 4x4 变换 矩阵，该矩阵表示每个平面的中心位置和朝向。它可用于 将 3D 虚拟对象放置在地面/桌面上。

锚点

锚点定义了真实世界中的固定位置和朝向。开发者可以从 4x4 变换矩阵创建 锚点，该矩阵可以通过命中测试获得。此矩阵将每帧更新， 以确保与该矩阵对应的虚拟对象能够固定在真实场景中的一个 位置和方向上。

命中测试

获取表示真实世界空间中与屏幕位置对应的位置和朝向的 4x4 变换矩阵， 以实现点击和放置虚拟 对象等功能。