MiniApps 标准会议

王子韬：大家好，现在我们重新回到会场，如果大家需要吃点东西或者喝点咖啡，我们可以再稍等一下。如果没有的话，我们就开始Hackathon之后的会议！

10:40-10:50我会进行讲解活动。我是来自华为的王子韬，上午的会议将由我主持，下午的会议会由我的伙伴安勍为大家主持。

刚才有一个小时的Hackathon时间，由于疫情的原因，线上的同学参与热度情况不是很友好，刚才我们同步了一段视频，是由京东同学介绍了Taro的这一统一开发范式多端的思路。现场的table，欧洲的同学做了通过统一范式开发的快应用，我们和百度、阿里共同开发了一套支撑标准的转换工具适配到现在已有的一些内容，让大家实现一端开发多端部署的实现。

后续我们会把相关的材料和视频放在W3C的MiniApp工作组下面的git上，大家有兴趣可以直接下载，可以在本地讨论。

刚才简短的总结讲了一下我们的Hackathon活动，以及关于这次的回顾内容。现在正式开始下一段的分享。

第一段是华为王子韬为大家介绍一下MiniApp的标准化。有请子韬！

大家好，我是华为子韬，是MiniApp工作组的主席。同时我认为也是会场上最不靠谱的标准代表。

现在我给大家介绍一下MiniApp Standardized Solution。因为W3C的会进行归档，我的材料是进行英文准备，后期大家可以下载，应该可以很清楚的了解我想要传达的信息。

我们现在讲讲小程序。先回顾一下小程序有多伟大，这个主题就是good work MiniApp。

现在生活中的每一天都会遇到小程序，作为公司来说，小程序每天都在帮助公司赚钱。我们可以看到一个统计数据，之前从阿拉丁网站上下载的，大家注意我这里分子尊重它的知识产权，这里已经标注了下载网址。

从2017-2021年，小程序的DAU日活数据都是用亿统计，17年就已经达到了1.7亿，截止21年上半年统计数据已经达到了4.5亿，这是日活数据。大家想象一下，日活是用亿进行结算的话，这是多么可观的一个数字，背后又是多么可观的市场以及多么可观的钱。

这是从给厂家赚钱的角度，首先我们要会算经济账。下面算一下一些职工的便利。相信大家不少是杭州当地的同学，还有五湖四海，不管是坐高铁还是飞机，下来的第一件事情就是小程序扫码，如果没有小程序不可以的。现在衣食住行很难离开小程序，所以小程序是非常好的东西。

厂家能赚到钱，老百姓能依靠它获得足够的生活便利。

但是，大家都好。厂家赚钱了，然后我们得到方便了。还有一部分人快被逼疯了——开发者。不得不说小程序做得很好，但小程序真的容易避疯开发者。

[多媒体演示]

这是20年的一个研究报告，上面显示大致已经形成了这么多家平台，包括腾讯系、阿里系、百度、字节、安卓手机厂商以及京东的，这么多平台这么多小程序都有独特的开发和一套独特的开发逻辑。

这些开发逻辑一定程度上可以拉齐，但为什么造成了种种的困难、种种的墙，这是为什么呢？一部分是有品牌的原因，一部分有独特设计的原因，另一方面设置就是为了差异而差异。如果我是一个独立的开发者，让我学习这么多系的小程序、这么多平台、这么多APP，甚至某一个平台的APP还不太一样，让我学习，重复学习，重复劳动，我真的会比逼疯。在一定程度上，我做这个标准的时候，看各家差异想办法拉齐差异，现在我已经有点精神恍惚了。

所以，这个问题提给了业界，也是提给标准组，小程序很好，作为开发者，已经快比你们逼疯了，你们不能只为了赚钱，某种程度上我们也是站在用户的角度上，我们也是用户。

重复学习是非常boring的事情，真的不要逼疯开发者。

好处是我们想到的困难，业界已经想到了。大家可以在Hackathon的间歇看到我们京东同学介绍的Taro这套统一开发项目，非常不错，不愧是奥特曼的总队长，能力非常强，拉齐了不同厂家、不同平台，抹平了一些差异，通过一套统一开发范式，实现了一套开发多平台跑通的逻辑，非常感谢Taro的同学！Thank You Ultraman！

这样的范围造成了多端不统一，造成了难以抹平的差异。

刚才讲了如果各厂商对标准化的支撑不到位，同样有一些问题难以抹平，非常简单的是大家对CSS的理解，大家对同一事件、同一命名的UI表现会有不同的理解，相同名字的UI表现有不同的理解，这都是不得不说的问题。

现在大家怎么办呢？最简单直白甚至有一些笨的办法，就是强行的做一套自己的理解，这样就不得不让整个project越来越大，甚至越来越不亲密。

如果说我们能有一套标准部署下去，各家平台认可，无论这几家平台做得什么样，哪怕内部对标准有什么样的适配，但可以对外统一的呈现、统一的表现，不管是工具链或者独立的开发者，都可以通过这一套标准实现他们的理想。

就是通过写一套代码，跑在不同的平台上，可以收获三个平台的入口三个平台的流量，甚至可以获得更多的流量打通，获得更多潜在的用户数据，可以挣更多的钱。

刚才说的问题很好，现在我们意识到了有这样的问题，首先我们要解决的问题是识别。识别的问题就是现在我们缺少了一个标准化的解决方案。

最左边就是散乱的支撑情况，如果没有一套标准，就会造成非常混乱、乱麻一样的方式，甚至无法抹平。

线下我和网易的陈老师讨论，这种情况相当于是进入一个大厅，看上去各种情况都可以通起来，实际上几面墙都是不平的，感觉上还是非常痛苦的事情。

下一阶段我们要做什么呢？我们要重点讨论的是标准化解决方案的思考，我们想提供一套标准化MiniApp的解决方案。

在当前比较适合或者是比较现实的方式是用插件的方式实现从标准到现有的标准前部署的抹平，对外呈现的是一个黑盒，我可以提供标准的组件，可以提供标准的解决方案，可以提供标准灵活部署的插件，提供出去，开发者可以直接通过标准化的开发方式来做。

同时，一些工具链包括类似于刚才介绍的Taro等工具链厂商可以适配到这套标准上来，真正为开发者提供一套从里到外统一呈现、统一表达的解决方案。

未来，标准是有周期的！从开始第一步，到一步步成熟，未来标准化的方式如果能让大家普遍接受，如果标准化的方式都让大家认可，无疑平台的厂商，像百度、支付宝、华为等等，能不能对平台直接做改造，一步到位，让标准运行在各个平台上去，这是最终的目标。

我认为，做成这一步，我们的标准是真正成功的，也能真正为小程序的开发者提供一套最为合理、最为有效的解决方案。

标准组是21年成立，一年了，我们干了什么。第一期主要有几个Specification，像Lifecycle、Manifest、Packaging等等。

后来由于W3C标准发布的流程，后续需要提供各平台的兼容性测试，对标准进行一些部署测试。这些也在推进中，这是工作组整体的进展。

但是，我们还是要落脚到“but”，我自我表扬一下，我自认为我们工作组进展还不错，但是还不够。

[多媒体演示]

这是我简单化的MiniApp的Specification。标准落脚在Lifecycle，非常开心，我们可以用讨跑通一个“Hello word”，然后我们只能跑通一个Hello Word。

再进一部分，我们不能只为用户提供Hello Word。后面怎么办？UI、API，去年我们就已经开始讨论，我们要进行UI和API的标准探索，要开发标准的UI，要提供一套标准化的UI解决方案。

但是，大家看到进展，如果我们进展了，那Hackathon就可以给大家演示这套统一的UI是什么样，但现在的问题是标准上的进展，在UI讨论上陷入了僵局。

它的问题是什么呢？先说good news，给大家一点信心，good news就是我们认识到了不得不讨论标准化的布局、标准化的推动，所以工作组尤其是MiniApp group会定期讨论标准化的方式，并且也开了一个仓，用以讨论MiniApp UI的一些设计，也有了意向书这样的东西，阐述标准化UI的必要性，以及标准化的必要内容，所谓的标准UI应该长什么样子、标准里要写什么内容。

最后，整体路径是我们先标准化UI的解决方案，接下来是标准API的方式。

现在又落在了“but”上，你们都识别了问题，都知道标准化怎么样，但是标准拿出来看一下。这涉及到为什么UI标准陷入了僵局，MiniApp普遍遵循或者业界认可的开发范式，类似于model view的方式，实际上它和W3C技术框架认可的这套开发范式，以及它对DOM的理解、DOM的暴露是不兼容的。

大家可以看一下我们提供的那套链接上，在W3C那套规范上，都会涉及到其他工作组的同学，或者对W3C有深入理解的同事，给我们提供的一些建议，说这与W3C已有规范是矛盾的，那怎么办？实际上我们在其他工作组讨论当中，进展很慢，为什么我们的这套会成功？

所以我们又陷入了矛盾，到底是用W3C的标准支撑小程序的开发，还是用什么方式？

当时工作组有对W3C Web技术理解非常深入的同学，提供了一套用W3C的方式，用HTML5的方式来开发小程序的一套解决方案，并在会议上进行了多轮讨论。但陷入的问题是这套和标准兼容，用这套在W3C上做标准没有问题，但和原有的东西又有gap。难道我们推翻原有的东西、原有有的商业基础做标准吗？好像不符合逻辑。

现在陷入了两难的境地，我们想要的最终目标以及想要呈现的标准化解决方案，有一定的gap。这个gap怎么抹平呢？就是我接下来想讲的内容。

这里详细阐述了几套路径。我们提供了一套从W3C角度上、从Web已有角度上，重用所有现有的规范，重有现有的框架，提供一套标准化的解决方案。用标准化的DOM方式，用标准的HTML 5的标准语言方式，结构现在MiniApp UI怎么写、怎么部署下去。

在标准化的角度上，或者说在研究的角度上来说，非常值得一试。因为它遵循W3C已经探索清楚的内容。已经认为一定程度上标准化的最优解，但问题就是标准很美，研究上很通，但是相互兼容怎么办？把这些难度重新丢给厂商，厂商有多少热情来做这件事呢？

厂商做这件事，我把平台按照标准化的方式做，已有的商业部署怎么办？那些已经部署在上面的，重新开发吗？他们会不会跟我拼命？厂商会想他们会不会跟我排名，小程序上以万计的小程序开发者怎么办？让他们重新开发吗？这部分投入怎么办？这个钱谁出？反正W3C不出。

这是一个问题。还有一套路径是什么？我们更务实一点，大家各退一步，到一个大家都能相对节、妥协的路径，各家程序类似的框架model view，类似GS的方式，做一套可能的标准化方案。这套方案不像W3C发布的规范，但可以以工作组的方式发一套技术备忘录一样的东西，但可以说它不是标准吗？它不能在一定程度上解决大家的问题吗？

甚至下一步大家在开放的平台或者一个工作组下提供支撑标准的看法工具、源码以及一整套标准化解决方案，真正为开发者提供一次开发、多端部署的条件，大家认为这是不是标准？我认为这就是标准。首先它有W3C严谨的标准讨论环节，大家的诉求都能被尊重，能够落下去；其次，它兼容了现有的一些厂家已有的部署，尊重在市场上已经被证明、被认可的方式。

那它是不是一种好的方式呢？我认为是一种好的方式。6月份的CG会议上，我们就和大家讨论要用这套方式，而且这套方式的标准进展相对更快一点。因为它省去了一些标准冗长的讨论流程相关的cross review，类似于开源的方式写标准，类似于开发的方式做标准研发，所以这块工作是下半年要考虑的。

下午的标准会议和工作组讨论当中，我们会讨论标准怎么快速开发出来，下午的工作组会进行讨论。

我认为这是一套非常有效而且可行的方式！在之前的一些CG会议和working group meeting的时候讨论的方式，如果大家有更好的方式，如果有更好的方式、更高效，更能把观点落下去、更尊重各方的需求，当然欢迎大家直接点醒我！

好的。还最后一个问题，做标准的人都在考虑问题，看标准的人都在考虑问题，标准能够不能用？之前我做过IETF，IETF很多标准，现在在9000个浩如烟海的RFC中，翻牌子翻到你，放在招标书上，这套标准才可能用。

W3C非常好的一点是不会出现这样的问题，因为W3C要标准，要发布。

W3C有一个非常明确的要求，有2家已有部署的报告，证明标准是可行、没有问题的，标准才能发布。这一定要鼓掌，证明W3C的标准起码能部署、要部署、有部署才能发布。

现在的问题是我已经自我表扬了，小程序工作组做了那么多标准，你们这些标准怎么做标准、怎么证明部署呢？非常好，现在工作组已经开始讨论了。我们开始要做一个标准化的标准平台兼容性测试项目，工作组已经在W3C下正式开了一个场，大家可以直接看现在已有的标准，通过这个标准想想我们怎么开发测试的标准以及测试的用力，最终测试的报告怎么呈现。

如果认为某条标准就是垃圾、某条标准就是要反对，好的，我们新开了一个组供大家讨论。后续我们会重点把一些已有的部署、已有的标准，按照这种方式开发一些自动化的测试工具，以及自动化的测试用力。最终的测试结果以几个案例的方式反馈给大家，让大家知道这套测试是怎么玩。

我代表工作组这里号召大家参与这个开源项目，希望把这套标准真正的测试跑起来，最终落地下来，真正给业界以信心，发布一套标准化的决定方案。

这就是我们近期的几条重点工作。一个UI API的标准化，是技术备忘录性质；二是怎么落地这样一套开源测试项目的性质，号召大家进一步讨论。同时，希望不管是标准的制定还是开源的测试项目，希望大家能够不要太害羞。

我发现国内标准讨论都太害羞了，通常我这样的情况在海外已经被人拍了好多砖，或者已经有很多激烈的讨论了，所以希望大家不要太害羞，标准是在吵架的过程中逐步完善，标准是在充分交换意见的条件下最终实现有用、好用的标准。

这就是我对标准工作以及对MiniApp工作组的展望，我认为是万事俱备，只欠大家踊跃参与。

我放一些大家可以直接在W3C上检索到的链接，包括一些gap analysis，我们就是希望打通这些gap，从A走到B，大家一起共建一个四通五达的标准化解决方案。谢谢！

谢谢子韬的精彩演讲！现场有没有同学想对子韬进行提问，如果线上有问题的话，也可以进提。

提问：我有两个问题：第一个问题是标准的制定，肯定需要很大的支持，包括这些test建立需要巨大的支持。第二个问题，花了这么大的力气建标准，怎么保证厂商可以迁移到标准上来吗？

王子韬：第一个问题是投入问题。首先，大家可以看到小程序工作组下来是初始会员，其实这个说法不准确，工作组本来是开放的，只要家里不断网，都可以参与讨论。

现在大部分情况下说已有参与的公司，比如阿里、百度、华为，有标准的人员在讨论，同时背后会有一系列产品团队的跟进、讨论，现场会有华为内部的同事，不是我们团队，同时他们会进行一系列的预部署、评判。看起来是几个人在讨论，实际上有团队支持的。

这块相应的代码、投入的活动，也是这些厂家在支持的。所以，平台厂商在这里做出了非常多的努力。

人、钱、代码、工作量，大家都在支持。

投入的问题，当然，投入上不封顶，希望大家多投入，希望大家多讨论，因为标准化的事情不是几家大的平台就能定下来，希望大家甚至个人的开发者都能贡献自己的idea、自己的想法甚至自己的时间。

这是第一个问题。

第二个问题说平台怎么迁移用的问题。刚才说话了短期之内，大家可以看到我们都标准前的位置上，类似自发性质的抹平平台的差异，以第三方项目的方式平台差异。

但大家可以看到即便这些平台厂商没有做什么动作，同样的也有自发的项目干这个事情，证明这一块是有利益可图的。这是第一个。

现在我们想迁移到的方式，大家认为标准前的方式，平台不参与，都是第三方工具链的方式，认为这方面有利可图，不然不可能有人做。

现在我们已经意识到这套方式不行，不然也不会有工作组，各家平台也不会投入。现在已经到了平台意识到有问题，我们要做点什么事情，但是我们要足够尊重已有的商业部署，这时候怎么办呢？可能有平台做内部标准的支撑、对齐，简单的工具链支撑，简单的工具链对齐，同时观望这套解决方案是否对我们真正有用，现在已经到了有限投资的部分。

有限投资让它看到有足够的利益，我们是否可以有一套又兼容又有部署，同时又对未来新的开发者足够友好。

刚才Hackathon的时候，我和陈老师讨论了类似的问题，站在已经部署的平台角度上，主要是做贡献的角度，让更多开发者做贡献的角度，甚至从商业的角度来说，每个平台有自己的重点发展方向。比如鸿蒙，鸿蒙是做跨端，做类似IoT，做应用的流转跨端，交互的场景比较多。阿里是不是类似电商的场景比较多（我随便说的，我不知道大家的具体场景），有重点的发展场景。但是，小程序要全量。

站在平台的角度，肯定是希望自己的小程序提供的服务越全越好，其他的服务类型怎么办呢？我们希望有一套逻辑，希望大家从A擅长的领域到B擅长的领域，最后做成一个全量的领域、全量的应用。所以会让平台觉得通过这样的方式提供这样的一套便利，就能帮助我们建立全量的领域。

未来通过这样的方式，小程序也好，或者使用场景也好，都是在扩展的，不可能固化。如果新的领域能够提供一套标准化的方式，一套解决方案，一套标准和一套范式，多端多平台部署的方式，在新的领域，用到的话，我们是不是就可以实现新的垂域扩展共建，真正实现所有平台的繁荣？

这是我们整个大的逻辑或者我们能想到的商业逻辑。

刚才我在会场上和大家讨论的时候，又有一些新的idea，大家给我输入了一些新的场景、新的方式，其实之前我们没有考虑过。所以，也希望如果大家有这方面的想法、真正能够牵引平台有动力做的想法，也一定要在工作组或者线下多输入，我们可以把这个愿景、把这个饼画得更圆、更大。

谢谢！

提问：我有一个问题，我理解现在小程序现在靠先编译，编译到Web上运行。现在讲的框架虽然有差异，但编译后，最后还是在Web上，还是HTML5的东西在运行。

现在我们想统一UI或者API，我认为API各家在场景上有差异，不一定会做，比如刚才提到华为的例子，华为不做电商，有些可能不会实现。但是在端上渲染，未来有没有可能框架不是开发态的框架，而是运行态的东西。扔掉后端的应用，就做成独立的小程序运行时，大家往后走就直接可以用起来，不需要再编译，从这个问题上统一标准？

王子韬：这个问题也非常好。去年，我们和软件绿色联盟有联合的会议，讨论了这样的问题。现在的问题是标准组织有自己的sgoup以及重点发展的边界。之前我们在小程序和W3C做的这套东西，重点瞄准是统一的开发框架上。但是在绿盟以及其他的开源组织里，正在讨论的是三个态，统一的开发态，统一的运行态，下一步甚至会有统一的运营态，类似于流量的打通，大家互相拆墙，互为流量的逻辑。

可能我的分享上有一些内容没有非常全面的介绍，包括之前我们怎么跟一些产业组织、开源组织讨论的内容。现在我们形成了共识，在标准重点上，W3C上是做统一的开发范式，在进一步的活动上，进一步放在开源里，可能放在产业联盟里进行示范性质的东西，讨论统一的运行时，统一的运营。

所以，这里说了有考虑，会是以组织间合作，大家各自在自己擅长的业务领域里，在自己的业务边界里为这套最终“三态”统一做一部分贡献。

我认为最终的呈现形式，只要组织间合作好，把界限划清楚，定期做cloud leader，最终在小程序开发界面上是完整的“三态”解决方案，以这样的方式进行合作、进行推进。谢谢

王子韬：好的。非常感谢子韬的演讲以及大家的提问。

返回会议总结页面获取其他话题的会议纪要。