李安琪：大家好！欢迎来到 W3C MiniApps 工作组的线上分享会。会议包括对 MiniApps 工作组及其开发中的规范的介绍，以及开放问答讨论，交流国内相关厂商、开发者和其他利益相关者的想法和所关心的问题。
W3C 于本月初正式成立了 MiniApps 标准工作组，miniapp（主要是小程序和快应用）国内外厂商将联合通过 W3C 这一平台制定 miniapp 相关技术规范标准。考虑到国内与此相关的厂商、开发者和用户的兴趣和需求，我们希望通过这次分享会跟行业的利益相关者分享这项工作的出发点，现处于什么阶段，以及未来的走向。选择在这个时间举办交流会其实非常重要，行业的反馈对我们后续的标准制定是非常有帮助的。在方向上我们可以提前考虑这些需求该怎样实现，如何更好地改善用户体验，以及提升标准质量等等，这是今天这个线上分享会的初衷。
大概两年前，W3C Web 中文兴趣组成员包括百度、华为、阿里、小米等识别了对 miniapp（小程序、快应用）的标准化需求，促进 miniapp 的开发效率和跨平台互通。于是多家厂商联合在2019年9月初步梳理了 miniapp 的概念、需求以及潜在的标准化方向，并发布了《MiniApps 标准化白皮书》。
同年9月，在 W3C 年度全球技术大会期间成立了 MiniApps 生态社区组（MiniApps Ecosystem Community Group），开始孵化关于标准的一些想法。之后通过与 W3C 全球会员代表的沟通，表示国内厂商希望通过 W3C 这一平台制定 miniapp 标准，增强不同 miniapp 平台的互操作性以及内外部更好的兼容。一开始国际厂商对此有些疑问或顾虑，有人认为 miniapp 里包括 Manifest, Packaging, Lifecycle 等与 W3C 现有规范例如 Service worker 或者 Web Manifest 有一定重合。于是去年7月份，社区组举办了关于 MiniApps 标准化的国际研讨会，也邀请了 W3C 的技术架构委员会（简称 TAG，负责审阅 W3C 所有技术文档并给出建议，确保标准的设计符合 Web 整体设计原则）参会，目的是澄清 MiniApps 标准化的内容是 W3C 现有工作尚未覆盖到的，或者说是对已有工作的有益补充。那次会后，我们已经基本准备好了 MiniApps 工作组的标准化章程。同年的 W3C 全球技术大会上，我们明确向全球社区介绍了关于配置文件、包结构、生命周期等几个清晰的标准化方向。
与此同时也做了大量的线下工作，例如澄清 MiniApp Manifest 与 Web Manifest 的区别，为什么要专门的 MiniApps 标准等，多家厂商都参与并做了大量工作。MiniApps 社区组在12月份基本完成了对工作组标准化章程，计划变得更加明朗。经过 W3C 全球会员代表的投票、与几个重要相关的国际厂商反复沟通，最终获得了支持并成立了 MiniApps 标准工作组，正式开始制定有关标准。
这里简单介绍一下社区组（Community Group）和工作组（Working Group）。社区组主要是对标准化想法进行孵化，技术提案孵化出来之后就走向工作组，进入正式的标准化流程。标准化过程中不断进行技术完善，互操作性测试，通过安全、隐私、无障碍、国际化这些横向审阅最终发布成正式标准。同时，如果厂商们认为还有其他新工作需要孵化，可以继续在社区组中进行，然后输入给工作组。目前社区组讨论活跃，每月中旬的周四召开包含中国厂商和国际厂商的全体成员的电话会。 刚成立的标准工作组章程中明确了两类文档，一类是正式的技术标准（包含配置文件、包结构和生命周期），另一类是需求文档（包括寻址、卡片）。接下来有相应厂商的技术专家为大家介绍这些文档。工作组是一个开发正式标准的地方，目前仅向 W3C 会员开放，有特定的 IPR 政策，也有专门的成员邮件列表供日常讨论。下面有请各规范的主要编辑向我们介绍这几份规范的内容。
MiniApp Packaging 和 MiniApp Manifest
张永靖：来自华为，目前任 W3C MiniApps 标准工作组联合主席。首先向大家补充一个概念：工作组名称是 MiniApps，它覆盖的范围包括我们熟知的小程序和快应用，是这两种技术形态的融合。所以相关技术规范的开发和讨论是在标准层面尽可能地融合这两套相近的技术方案，这是工作组的目标之一。
接下来我简单介绍一下我们已经孵化的两个提案：Packaging 和 Manifest。Packaging 规范定义打包的基本要求，也就是说作为一个程序的包，这里面应该包含哪些基本的内容或者文件，每个文件的功能和定位，以及它们之间的组合方式和关系。当前组内讨论的初步的共识是 MiniApp 包是基于 zip 的打包文件，里面会包含一系列子文件。这个包我们可能会注册一个新的MIME type。包里面我们主要的定义的内容包括 manifest 的JSON文件（这个在后面我也会进一步展开来讲），主要对 MiniApp 的全局配置做一些描述。此外就是 app.js 和 app.css，两者构成了整个 MiniApp 的主入口，主要应用逻辑和整个应用的基本样式都在这里面进行配置。
pages 目录里有一系列跟页面相关的文件，包括每个页面具体单页面上的应用逻辑、样式配置、布局描述，会有一系列子文件来描述。关于页面布局的规范和单页面配置方案还在讨论中。pages 下也有不同的方式去组织，可能是基于每个页面有单独的子目录或者文件夹去管理，相对灵活；common 目录包含一系列公共基本资源，比如公用的 UI 组件、模版、脚本；还有 i18n（国际化）多语言配置目录，多语言字符串管理和替换等等的文件会在这个目录里面。目前考虑的是每种语言都有单独的检索文件，具体技术方案还没有展开，这也是后续要开展的工作方向。另外，package 需要安全保护机制，最基本的是签名保护，来确保用户所下载执行的包是安全可信的，来自可信的开发者、分发者或者应用市场。
用户从整个 MiniApp 的获取到执行的基本的操作包括几个步骤：首先是从外部获取一个 miniapp 包，包的获取渠道没有限定，具体方式比较灵活；本地客户端收到包之后要做一些基本签名确认，之后在包的解析过程中识别其中的主要的入口、软件，包括它的配置文件，里面描述的基本兼容性要求信息、运行时环境；之后加载主要的应用逻辑入口，包括首位页面的加载来执行这个应用。
简单来说，虽然它是利用很多 Web 资源打造的技术，但它跟 Web Packaging 和 PWA 依然存在差异。MiniApp 的打包资源更多是应用本身所需要的脚本以及页面布局等方面的数据信息。Manifest 包含基本的应用信息，名称、描述、标识、图标、语言等等。MiniApps 特有的信息包括控制的配置、页面风格的约束、权限的管理。整个 Manifest 规范我们在持续讨论完善中，可能添加更多的元素。
MiniApp Manifest 是基于已有的 Web App Manifest 的扩展，都是JSON格式。Manifest规范还在制定中，不是最终的版本，可能还会有新的属性添加进来。基本的属性从 WebApp Manifest 继承过来，但针对 MiniApp 特有的需求和配置信息则需要扩展，包括对运行环境的要求、最小版本号、标识信息等，要做到跨平台的兼容性。因为其运行环境的差异性或异构性，那么要求在窗口配置页面管理各方面有一些特殊的配置和约定。
MiniApp Lifecycle
安勍（阿里）：虽然存在着 PWA、Service Worker 这些并行的 Web App 相关生命周期规范，但由于 MiniApp 和 Web App 在底层引擎、运行时层面的差异，所以还是需要 MiniApp 生命周期的规范。MiniApp 分两层：app layer和 page layer，因此相应的生命周期也会包括应用层和页面层。思路很直观，首先是基于 MiniApp 的工作机制（比如包括 MiniApp 下载、冷启动热启动、前后台运行、销毁），对应推导出包含的一些应用层的 lifecycle 事件（包括初始化、前后台运行、错误处理），最终在标准里，将会基于 W3C 现在的 Web App 或者 Web IDL 的格式去分别定义应用层的 lifecycle 的 API。 针对页面的 lifecycle，根据事件类型（页面加载、首屏渲染、前台后台运行、页面的销毁）也需要有相应的 page lifecyle 状态和API。 规范里也会考虑隐私和安全因素，包括如何向开发者隐藏用户的敏感信息等等。
MiniApp Addressing
周丹（百度）：我们都知道在一个实现了 miniapp 运行时的宿主环境可以打开各种 miniapp 的，但是宿主是如何知道应该打开哪一个 miniapp 的哪一个页面呢？就像普通的网页需要用 URL 来进行定位一样，miniapp 也用到了统一的资源定位符 URI 来定位资源。不同的小程序以及小程序内的不同资源其实都会分别关联到一个唯一的 miniapp 的 URI。但是区别于 Web 的一点是，为了追求类似原生 app 的一个流畅体验，一个小程序的所有资源通常都会被打包集合在一起，以整体包的形式存在，但是从用户的访问层面上呢，我们的 URI 需要定位这个包资源里的具体的子资源。
除此之外，MiniApp URI 有非常多的一个应用场景，比如说 miniapp 商店、搜索引擎、负一屏、车联网、线下等等。但我们总结 URI 的现状之后，发现不同 miniapp 厂商虽然 URI 关键信息都基本一致，但是协议的规则却千差万别，这会使得用户的认知体验非常不一致，而且也会给未来跨平台访问miniapp 带来了比较大的一个困难。 我们从宿主的角度上来讲的话，通常在访问一个 miniapp URI 的时候，宿主会并行的进行一些操作，比如请求包的同时会去加载并且初始化运行时环境，目的是为了减少首次打开的耗时，提升启动性能。这里体现了一个非常关键的诉求就是宿主需要通过某种方式（可以是 URI 或者是别的方式）来预判小程序。
综上，这也是为什么需要制定 MiniApp Addressing 提案的原因。目的就是为了定义 miniapp 资源的访问形式，而且定义一种通用的访问协议，并设计一种能够预判小程序的实践方式。我们提出了提案的初稿之后，和国际厂商以及 W3C 技术架构委员会进行了多轮讨论，最终结论是为了避免新增scheme协议头会破坏 Web 架构的设计原则，所以在工作组中，这项工作会从规范URI scheme转变为规范 addressing。也就是说以规范 miniapp 的定位方式来继续进行新的工作。在这个过程中是不会新增 scheme 协议头的，对此GitHub 上面有非常详细的讨论（#34）。
我简单介绍一下目前已有提案的语法部分：对于 scheme，我们是不做约定的，各家厂商都可以使用自己的方式。authority 部分包含 miniapp 的定位信息，包括 id、version 以及能够用于获取包的 host和port。id 是任意长度的，并且是在 host（host 是这个厂商的包服务器）下是一个唯一的字符串 id。
version 和 id 是能够共同标识一个唯一的包，这里的 host 和 port 字段都是可选项。当 host 或 port 为空的时候，就会由打开这个 URI 的宿主来决定用什么方式来作为默认的行为打开这个指定 id 的小程序/快应用。
Addressing 提案相对于之前的 URI Scheme 提案会有很多变化，我们也会在工作组中不断完善。希望，也非常欢迎大家能够参与到我们在 GitHub issue 的讨论中来。
在线问答
李安琪：感谢各位的介绍！接下来我们进入互动问答环节，各位有什么问题欢迎畅所欲言。
问题一：启动 MiniApps 标准工作组是不是在 forking the Web？
祖明：来自百度，MiniApps 工作组联合主席。从我们的愿景，以及过去很长一段时间参与miniapps标准相关工作的过程来看，我认为大家的工作是非常积极和开放的，如果涉及到W3C已有的一些标准有相关性，我们会充分和已有标准工作组进行沟通与合作，以判断是沿用、增强已有标准，还是新建。对于我们未来会在MiniApps 工作组去推动的一些，目前看来是miniapp比较特有的一些标准，我们希望未来这些标准能够早日成为Web生态的组成部分。所以小组的工作并不是 forking the Web。
问题二：业界厂商如何参与 MiniApp 标准化工作？
张永靖：渠道很多，首先欢迎大家加入刚刚成立的 W3C MiniApps 工作组（需要大家以会员公司成员的身份加入）进行技术讨论和标准制定；如果还不是会员公司成员，小组的工作和技术讨论也会开放在 GitHub 上，欢迎大家关注并参与，随时提 issue 和意见，我们都会认真审视；此外，也欢迎加入上面提到的 MiniApps 生态社区组，社区组是更加开放的交流环境，任何公众个人都可以参加，那里有非常多的技术专家都在参与技术方案的讨论和前期孵化。 吴小倩（W3C）：除了小程序/快应用引擎公司，今天的参会者也有很多来自框架/应用开发等不同背景的公司。各位可能会有多样的深入思考或业务需求，欢迎提炼相关用例，或者认为现有架构中需要改善之处，以上这些都可以作为需求和建议输入到工作组。
问题三：国内外厂商目前参与情况如何？
张永靖：这项工作通过 W3C 这个平台进行，也是看中 W3C 汇集众多国际厂商的资源优势。在生态社区组的早期孵化中，已经有来自全球厂商的参与，除了今天会上的国内厂商之外，国际厂商包括 Google、Facebook、Intel 等都有人在参与跟进相关讨论。新成立的工作组刚刚成立，后续也会有更多厂商陆续加入，参与到正式标准的制定中。
问题四：如何保证标准落地实现？
李安琪：从一开始各 MiniApp 厂商联合成立生态社区组时就考虑过这个问题，也本着严肃认真的态度在推进。大家参与进来就带着对未来标准的实现意向，当初的设想是至少有两家小程序/快应用平台厂商愿意将来实现相关标准，我们才同意开始启动孵化工作。在后面的正式标准化流程中，W3C 标准制定流程也要求一份标准有至少两个以上厂商的独立实现。目前 MiniApps 工作组和社区组都认为这份标准的落地实现性还是很强的。我们也很开心地看到，在 W3C 全球会员代表投票过程中，已经有相当一部分国际厂商表示未来愿意基于这些标准来开发相应应用或原型。所以我们对 MiniApps 工作组交付规范的落地前景持乐观态度。
问题五：会有相关的 IDE 推出么？
祖明：IDE 应该属于开发者的生态或业务相关角度，不包含在MiniApps 工作组的标准化范畴内。 张永靖：实现厂商可能会根据各自的需求诉求推出一些 IDE，后续可能会考虑随着标准化进程的推进，来看是否会有配套的工具，但目前尚未可知。 周丹（百度）：我也认为在规范完善过程中，可能会有一些通用的但属于目前IDE范畴的功能，需要统一的诉求会促进相关的标准化考虑，但这目前不是小组的优先任务。
问题六：MiniApps 规范会细化到组件和 API 层面的统一，还是最多到生命周期层面的标准？
张永靖：大家可以看一下小组章程是包括组件和 API 的。只是当前还没有具体提案，计划先在社区组进行前期讨论和孵化，相对成熟后会迁移到工作组进行正式标准化。
李安琪：是的，小组标准化范畴里确实为组件和 API 预留了标准化空间，后续还需要讨论具体工作细节。
会议总结
李安琪：欢迎大家后续加入 MiniApps 生态社区组与全球厂商的月度电话会议（周四晚上20:00）继续讨论新的标准化想法。工作组的电话会议时间和 GitHub repo 将发布在工作组主页，请大家关注。社区组进行孵化，工作组将章程内已有的规范提案交付成正式标准，今年年底前，工作组现有的五份文档将发布出来形成稳定版本。工作组计划下半年开始考虑再将哪些由社区组新孵化的提案纳入标准化流程。
今天的线上分享会就到这里，感谢大家的参与！