W3C 首次发布小程序标准化白皮书，小程序要实现统一了吗？

2019 年 9 月 12 日，W3C 首次公开发布了小程序标准化白皮书，该文档介绍了这种非常流行的混合解决方案，既依赖 Web 技术，也集成了原生应用的功能。此标准一出，各家小程序将来有望实现统一吗？

文档状态

本节介绍本文档发布时的状态。本文档可能会被其他文档取代。可以W3C技术报告索引中找到 W3C 当前发布列表和本技术报告的最新版本。

目前这项工作仍在推进中。该提案正在W3C中文Web兴趣小组中孵化。本文档由中文 Web 兴趣小组作为首次公开的工作草案发布。

GitHub问题列表是讨论本规范的首选场所。或者你可以向我们的邮件列表发送评论。请将它们发送至public-chinese-web@w3.org。

发布第一个公共工作草案并不意味着获得 W3C 成员的认可。这是一份草案文档，可能随时被其他文档更新、替换或废弃。引用这份文档时应当指出它尚在推进中。

制作本文档的小组是基于 W3C 专利政策运营的。该小组没有预期该文档会成为 W3C 推荐标准。W3C 维护一份所有专利披露的公开名单，与该小组的交付相关；该页面还包括披露专利的说明。如果个人拥有关于一项专利的实际知识，并且他认为这些知识包含“基本要求”的内容，那么他必须根据W3C专利政策的第6节披露该信息。

本文档受2019年3月1日W3C流程文档的约束。

介绍

问题

原生应用程序在我们的日常生活中颇受欢迎，但它们在很多层面上也有改善的空间。

• 在用户从原生应用程序获取服务之前，他/她往往要先下载 - >安装 - >注册应用程序才行。由于存储能力的限制，用户只能在设备上保留数量有限的原生应用。在不同的原生应用程序之间共享数据并不容易。

• 要开发原生应用时，开发人员可能需要学习一些新的编程语言。为了向各个平台的原生应用程序提供相同的服务，开发人员可能需要为不同的平台维护重复的产品。

Web 是能够避免这些问题的一个理想平台，但到目前为止，它仍然不够完美。

• 与原生应用相比，Web 应用很难利用系统提供的功能。此外 Web 应用程序的性能很难媲美或超过功能类似的原生应用程序。

• 在移动设备上，用户经常要获取浏览器之外的服务或内容；显然，他们希望系统中的所有应用程序在用户帐户、登录状态和用户交互上保持一致。此外，有时用户可能希望与应用程序共享某些数据（如果他们真的信任它），但是一些经常请求的信息（例如当前设备的个人移动电话号码或联系人列表）很难在 Web 应用上提供许可。

小程序是什么？

小程序是一种新的移动应用程序格式，是一种依赖 Web 技术（尤其是 CSS 和 Javascript），但也集成了原生应用程序功能的混合解决方案。

小程序受到了一些超级应用程序的欢迎，因为它的一些特性有助于填补 Web 和原生平台之间的鸿沟。

• 它不需要安装。

• 具备多个 Web 视图以提高性能。

• 它提供了一些通过原生路径访问操作系统功能或数据的机制。

• 它的内容通常更值得信赖，因为应用程序需要由平台验证。

• 小程序可以分发到多个小程序平台（Web、原生应用，甚至是 OS）。这些平台还为小程序提供了入口，帮助用户轻松找到所需的应用。

我们简单地使用 PWA 不行吗？

小程序并不是要取代 PWA、Web 或原生应用的。

• 目标

• PWA：渐进式 Web 应用程序提供的用户体验与原生应用程序相似，对离线和推送 API 有更好的支持。

• 小程序：小程序通过在原生应用、Web 应用和 OS 中共享数据和功能来提供无缝服务。

• 宿主环境

• PWA：浏览器。

• 小程序：小程序平台有一些原生应用、Web 应用和 OS 没有的功能。在此平台上实现新 API 更容易。

案例研究

案例 1：共享单车服务

小程序的普及帮助共享单车成为一项无缝服务，无需繁琐的应用程序。

小程序的共享单车服务

• 用户进入移动设备上的某个小程序平台，一般来说是他/她已经登录的某个超级应用程序；

• 用户在超级应用内扫描共享单车上的二维码标签；

• 平台应用将自动跳转到共享单车小程序并立即解锁自行车；

• 抵达目的地后，用户在小程序上锁定自行车；

• 交易完成后，系统将向用户发送付款详细信息。

对于用户来说，小程序的便利体现在以下几个方面：

案例 2：AR 动物园

小程序开发人员只需使用 HTML/CSS/Javascript 作为编程语言即可，但小程序比传统应用更灵活，因此团队可以在日常开发流程中快速开发复杂的功能。

这款小程序构建了一个采用 AI 技术的 AR 动物园来识别这些动物。开发人员可以添加一些组件或 API 来轻松实现这一需求，这些组件或 API 提供对原生功能或高级功能的访问，诸如图像识别、AR 3D 动物模型渲染、用于语音合成的语音 API、由地图 SDK 提供的 AR 导航等。

小程序可以通过搜索引擎、宿主应用程序中的小程序商店或二维码来获取。

AR 动物园小程序

对于开发人员来说，小程序的好处显而易见。

案例 3：用于物联网的小程序

小程序的一个目标是在不同平台上连接信息和服务，因此它是智能汽车、语音控制扬声器和智能电视等物联网应用的理想选择。

为车辆屏幕和系统适配小程序是可行的；为此，一些小程序供应商已经构建了专门为车辆系统设计的小程序平台，以帮助应用程序在多种车型上分发和升级。这使数百万 Web 开发人员进入了汽车应用程序生态系统。

这些汽车小程序可以服务于许多用户场景，包括加油、洗车、电子收费、保险、餐厅预订或娱乐等。例如，当系统检测到剩余燃料低于 20％时，它可以向车主推荐 Gas Pumping 小程序。用户可以获取最近的加油站信息并前往那里加油，包括付款流程在内都在小程序中完成，实现“不下车加油”。

用于智能汽车的小程序（加油应用）

小程序概述

核心功能如下：

分离视图层与逻辑层

在小程序中，视图层通常与逻辑层分离。

小程序的一般架构

视图层负责渲染小程序页面，包括 Web 组件和原生组件渲染，可以将其视为混合渲染。例如，Web 组件渲染可以由 WebView 处理，但 WebView 不支持某些 Web 组件渲染，或者是性能受限；小程序还依赖于某些原生组件，例如地图、视频等。

逻辑层是用 JS Worker 实现的。Worker 负责小程序的事件处理、API 调用和生命周期管理。

扩展的原生功能通常来自宿主原生应用程序或操作系统，这些功能包括支付、文件处理、扫描、电话等。它们通过某些 API 调用。当小程序调用原生 API 时，它会将 API 调用传递给扩展的原生功能，以便通过 JS Bridge 进一步处理，并通过 JS Bridge 从扩展的原生功能获取结果。

调用 API 时小程序的数据流

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

如果事件由小程序页面中的组件触发，则此页面的 Render 将向 Worker 发送事件以进一步处理。同时，Render 将等待 Worker 发送的数据来重新渲染小程序页面。

渲染过程可被视为无状态，并且所有状态都将存储在 Worker 中。

视图层和逻辑层分离有很多好处：

• 方便多个小程序页面之间的数据共享和交互。

• 在小程序的生命周期中具有相同的上下文可以为具备原生应用程序开发背景的开发人员提供熟悉的编码体验。

• Render 和 JS worker 的分离和并行实现可以防止 JS 执行影响或减慢页面渲染，这有助于提高渲染性能。

丰富的 API 和组件

小程序平台提供了许多组件来帮助开发人员构建精美的 UI，包括 View、Form、Image 等基本组件以及 Maps 等高级组件。

小程序供应商还为开发人员提供了许多 API，以便访问 Web 和原生功能；这些 API 既有 UI 显示 API 和图像 API 这样的基础选项，也有账户 API、地图 API、支付 API 等高级选项。

API 通常与组件一起使用。当用户单击小程序页面上的某个组件时，它将调用相关的 API 来完成用户的交互，并在需要时刷新当前的小程序页面。

小程序构造

为了获得与原生应用程序相似的用户体验，小程序资源通常打包在一起。下载并安装小程序软件包后，用来显示应用程序页面所需的所有静态页面模板/CSS/JavaScript 文件都已经在用户的设备上就绪了。在下次更新之前，这些资源始终可用，无需任何额外下载内容。

小程序包是压缩格式（例如 zip）存档，包括：

• 一个配置文档，位于包的根目录下。配置文件应包括：

• 整个小程序的概述。

• 页面描述及其对应路径，用于页面定位和开启。

• 一个包含 JavaScript 代码的应用级逻辑文件，处理应用级生命周期回调。

• 一个或多个页面文件，包含页面结构的模板代码、页面样式的 CSS 代码和页面逻辑的 JavaScript 代码。

• 支持数字签名验证。

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

卡片

除了以小程序页面的形式渲染之外，小程序还能以信息片段的形式显示，亦即卡片。在这种形式下，开发人员可以将他们的服务和/或内容放到各种宿主场景（称为宿主环境）中，内容可以是助手、搜索页面等。此功能将小程序的服务与场景关联起来，为用户提供更多便利。

例如，当用户购买火车票时，智能助手上的卡片立即显示列车的最新状态。用户可以单击这个小部件并跳转到全屏小程序页面以获取更多详细信息。

从主屏幕到小程序的小部件

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

在许多情况下，小部件可以打开小程序页面以执行更复杂的操作。在这种情况下，小部件通常需要与其对应的小程序共享数据，例如保持一致的登录状态。因此小部件和小程序的数据可以互通。换句话说，卡片和页面具有相同的数据访问权限。

卡片交互

小部件的一个目标是让用户忘记传统的应用程序概念，并以服务的形式真正满足用户的需求。因此，除了所有传统的应用程序调用路径之外，小部件还可以在各种场景下由多种方法触发，例如文本关键字、语音分析、图片识别、扫描代码、事件意图等。

单实例，多入口

用来发现、打开和访问小程序的入口众多。与多 WebView 的 Web 应用不同，同一个小程序只会创建一个实例，因此小程序以全局一致的方式保持其状态和数据。例如，在一个用户通过二维码入口第一次打开并登录小程序后，当用户从小程序商店等另一个入口返回应用时仍将保持登录状态。

小程序的入口包括但不限于：

• 小程序商店

• 搜索引擎

• 智能助手

• 二维码

• 短信/文本

• 物理对象（通过 AI）

• 浏览器

• 日历条目

• 语音留言（通过 AI）

性能和用户体验

小程序试图通过一些已被实践证明有效的机制来改善其性能和用户体验。

打包

使用小程序的构造器，用户只需在首次打开小程序时下载软件包即可，之后无需再次下载小程序中的静态资源（页面/JavaScript/CSS），这样加载和跳转页面就会更快。此功能可改善用户操作体验并节省网络流量。

同时，小程序有一个预下载机制，可以提前下载小程序软件包，或者单独预载第一页，并在下载过程中并行执行流解压，以最大限度地减少小程序启动阶段和耗时，提升初次打开首页的性能表现。

多重渲染环境

小程序在渲染环境之间使用原生页面堆栈管理，页面切换由原生代码驱动。因此，在页面中的手势操作和页面之间的切换可以实现与原生应用完全相同的流畅体验。

由于视图层和逻辑层的隔离，视图层可以独立渲染。不受 JavaScript 逻辑代码的阻碍，可以大大提高页面的渲染速度。

预构建和复用运行时环境

小程序的运行时环境通常在启动应用程序之前预先构建，从而缩短了启动时间。预构建的内容包括渲染环境、静态资源、开发人员定义的预取请求和小程序运行时容器。小程序激活后，它将接管预构建的渲染环境，然后我们继续为缓存池预构建新的渲染环境以备下一次使用。渲染环境数量有一个限制，当任何渲染环境关闭或超出数量限制时，最早打开的渲染环境将被销毁。当小程序退出时其运行时将被销毁，而应用程序环境和资源可以复用。

预定义的组件和 API

小程序平台提供了非常丰富的组件和API，这些组件和 API 大都设计出色，能够帮助开发人员保证工作效率。

JavaScript 框架预设和热更新

小程序的运行时环境包含两大部分，其一是原生代码提供的基本功能，其二是一个框架，包括开发人员 API 和一些由 JavaScript 实现的组件。JavaScript 框架内置于原生应用程序中，并将在执行小程序之前提前加载到小程序运行时环境中。JavaScript 框架可以热更新（在使用期间重新加载），带来了很多性能提升的潜力。

小程序概览

本节介绍了目前主流的一些小程序或相关平台。

支付宝小程序

支付宝小程序运行在支付宝原生应用之上，这是 Web 和原生的混合解决方案。支付宝小程序依赖 CSS 和 JavaScript 等 Web 技术。同时，它还集成了支付宝原生应用的功能，如支付、信用服务、面部认证等。

现在，已有超过 1,000,000 个小程序运行在支付宝原生应用上，DAU（每日活动用户）达 2.3 亿。用户场景包括零售、运输、医疗服务等。

百度智能小程序

百度智能小程序是指基于百度应用和其他合作伙伴平台，智能地将人们与信息和服务联系起来的开放式生态产品。通过百度的 AI 能力和对智能小程序中内容的理解，我们可以准确地将智能小程序和用户对接起来。借助百度的搜索和信息流双引擎，用户可以在智能小程序中实现类似 APP 的体验。截至 2019 年 7 月，我们拥有 150,000 多个智能小程序，MAU 达 2.7 亿。

百度智能小程序是在我们的开源联盟内开源的，该联盟拥有超过 30 个合作伙伴，涵盖超级 APP、移动操作系统、车载操作系统、语音控制扬声器和电视等领域。

快应用（包括小米和华为在内的快应用联盟）

快应用是由快应用联盟的 12 家顶级手机制造商开发的小程序标准，覆盖超过 2 亿 MAU。开发人员可以一次开发就在所有硬件供应商的平台上运行应用。快应用深度集成在操作系统内，在智能手机系统的众多应用场景中只需轻点一次即可获取。快应用引入了原生渲染路径，有效融合了前端开发和原生性能体验。

快应用能够以两种形式运行：类似原生应用页面的快应用页面形式，和用来在场景中显示信息的小部件形式。这两者适应不同的用户需求，将系统和小程序以多种形式连接成一个整体。

360 PC 小程序

PC 上的小程序仍处于早期探索阶段。360 PC 小程序是一款在 PC 浏览器中运行的轻量级应用程序。与传统网页相比，它具有更多功能，更易于与 PC 操作系统交互。

PC 小程序仅适用于经过验证的企业帐户，大多数功能都受到严格的约束，因此可以将它们视为高度可信的 Web 内容。

PWA

PWA 是现代 Web 应用程序的最新统称术语。作为原生应用程序的对应物，PWA 应用程序看起来和用起来都像原生应用，可以安装到主屏幕/启动器/开始菜单；它可以发送推送通知以重获用户关注；它可以离线使用，或在网络状况不佳的情况下运行；它支持具有众多功能的设备，并且仍在不断发展，以及时利用开放式 Web 标准定义的新功能；用户可以在 PWA 应用程序内付款；PWA 应用程序是搜索引擎友好的，并与超链接配合完美。PWA 在技术和业务层面都很成功（被许多网站广泛采用，特别是面向消费者的网站）。

与 Web 配合

本节选择了一些典型的用例，并提出了一些让小程序获得 Web 支持的 API 提案。

应用程序生命周期

混合渲染

小程序是 Web 渲染和原生渲染的混合解决方案。最好有一种很好的方法来组合 Web 和原生的渲染结果。

渲染来自 Web 和原生的结果

提案：小程序需要标准化的 API 帮助来将原生渲染结果集成到 Web 渲染结果中。

过渡动画

小程序希望在页面切换期间提供过渡动画，以便用户可以获得与使用原生应用时相似的体验，但现在几乎不可能这样做。

提案：小程序需要一个 API 调用来在页面切换期间添加过渡动画。

标准化小程序的构建包

小程序可以通过标准化的分发格式为多个小程序宿主平台制定一个统一的打包和解析约定。目前，每个小程序宿主平台都提供不同的开发工具（不同的打包方法），不同宿主环境中的解析方法也不一样。

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

标准化跳转到小程序页面的流程

可以在一个小程序中引用另一个小程序的热页面，并在用户访问时准确引用它。

提案：定义一套标准化协议（URI scheme）以访问小程序。

卡片

与 Android 小部件或苹果 dashboard 一样，用户可以通过卡片直接获取信息和/或完成任务，而无需打开任何 Web 或应用程序页面。卡片可以在 Web 浏览器之外的环境（如桌面或 dashboard）中显示。

提案：

• 卡片可以在宿主环境中显示，后者可以是 Webview 或原生应用程序页面。宿主环境使用其对应的 URI 路径加载小部件，该路径描述程序包和小部件页面。

• 卡片可以访问从服务器或本地数据。同时，卡片可以访问同一个包中的小程序。

• 卡片应该是交互式的，这意味着它应该响应任何用户行为/交互。卡片应该能够打开 Web 或应用程序页面。

性能和调优

在小程序中定义时间事件来交互

小程序需要知道小程序页面的交互时间（TTI）何时完成。

提案：一个标准化事件，用于通知小程序页面交互时间已完成。

图形和媒体

模型元素

拥有丰富细节的 3D 模型愈加流行，它与 AR 结合将提供比 2D 更好的用户体验。其商业案例可能涉及网上购物、广告】教育等。然而，当前的 Web 平台缺乏处理 3D 模型的标准和便捷方式。在本文档中，我们建议定义一个 HTML 标签来直接处理 3D 模型，类似于我们使用相应 HTML 标签处理音频、视频和图像的方式：

• 360 度视图

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

• 用 AR 查看

用户可以使用相机将 3D 模型放置在真实世界环境中。用户可以指定放置模型的不同位置。

提案：元素，用于在 Web 上指定 3D 模型并使用 AR 为交互式 3D 内容提供支持。

面部跟踪

面部跟踪可用于许多 3D 场景。

实时视频中的面部效果

在实时视频中添加面部效果。这些效果包括全屏滤镜、面部重塑和化妆、2D 贴纸、3D 头饰等。大部分效果都高度依赖对视频源的实时面部追踪。

游戏

游戏开发者可以根据跟踪到的面部数据设计游戏策略。比如在眨眼时触发特定的游戏逻辑，或者检查水果是否掉进了嘴里。

虚拟化妆

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

提案：一个面部追踪 API，使用视频元素作为输入并在每帧图像更新面部跟踪输出，其中包括：

• 每张脸的边框。

• 每张脸的 4x4 姿势矩阵。

• 归一化（x，y）地标点。

• ace 几何数据，包括顶点、法线和纹理坐标。

手势跟踪和识别

手势可用于视频效果和 AR/VR 游戏场景，可以使应用程序更加互动、更吸引人。

提案：用于跟踪手部动作的高级 API，获取手部轮廓。

基于 ARCore 和 ARKit 的底层 AR API

我们将在小程序中把一些 AR API 迁移到 Web 上，因为它们有助于在游戏、3D 模型预览和交互式广告中提供更好的 AR 体验。

提案：提供基于 ARCore 和 ARKit 的底层 AR API，其中包括：

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

提供移动电话空间位置和方向的 4x4 视图矩阵，可由开发人员用来实时更新其 3D 虚拟世界中的摄像机矩阵。这样一来，现实世界的位置就可以与虚拟世界中对象的位置相关联。

平面检测和跟踪

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

锚点

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

命中测试

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

更好地支持 AR 的 API

安全和隐私考虑

小程序利用 HTTPS 来支持安全连接。同一宿主环境中的多个小程序彼此独立。

小程序中的用户交互需要不同级别的用户权限：

W3C 前景展望

为了满足小程序的使用场景和要求，并使 Web 标准更好地支持小程序，我们希望在 W3C 中加入以下工作事项：

• 建立一个小组来协调 W3C 中与小程序相关的标准化工作，并与其他相关的 W3C 小组协作。

• 探索用户代理的创新，丰富 Web 内容。

• 横向审查（安全、隐私、i18n 和 a11y）。

具体来说，我们讨论了以下技术工作：

• 进一步检查现有小程序 API 与 Web API 之间的差异，完成差异分析。

• 根据小组选择的用例和要求起草小程序标准的路线图。

• 制定当前供应商的功能规范。目标功能包括但不限于：

• 包构造器

• 小程序 URI scheme

• 混合渲染 API

• 3D 模型标签

• 面部跟踪 API

• 小部件

• 设计针对未来，适用于 Web 和小程序环境的 Web API。

词汇表

英文原文：https://www.w3.org/TR/2019/WD-mini-app-white-paper-20190912/