【会议开始】

[与会成员进行自我介绍]

[主持人介绍会议讨论形式] 由主持人先分享该标准的技术进展，然后进行10-15分钟相关讨论，包括：
该技术目前在公司产品是否有应用
国内是否有类似技术或者实践
该技术在国内落地的可能性，是否存在问题
是否有必要开展后续专题讨论
国内有没有需求可以输出

WebXR

安勍（阿里巴巴）: 今年W3C WebXR工作从社区组转入工作组
... 阿里加入W3C Immersive Web工作组， 开始参与WebXR工作
... AR在国内的落地相比国外更快，在国内也有很多场景应用和活动
... AR很有前景，不过现在正在开发的WebXR Device API规范没有完全暴露出来，例如人脸检测等

林作健（阿里巴巴）: 是否有实际的展示？

安勍（阿里巴巴）: 工作组当前进展及未来规划在小组页面 https://www.w3.org/immersive-web/

徐嵩（中国移动-咪咕）：为什么国内AR比VR使用更广？

安勍（阿里巴巴）: 用户使用成本、占有率
... 未来眼镜对用户来说可能是比手机更好的终端
... 手机还需要扫码等操作，眼镜的话可以大大提升用户体验，更好地与日常生活结合
... AR与用户场景关联度更好些

陶清乾（百度）: 富侨现在为大家展示XR的应用场景
... 展示链接：https://ada.is/grid-slides/webxr/ac.html
... 欢迎大家尽可能探索未来可能的合作

王兴楠（华为）: 这些场景对标准的诉求在哪里？

安勍（阿里巴巴）: 购物，AR为主，如3D模型、服装、家居
... 线下的实际购物体验，支付，人脸识别，自拍识别，手势，3D模型展示标准
... 各家模型不同，如何低成本地建模展示

刘守群（小米）: 现在有没有WebAssembly与WebXR的应用结合研究？

安勍（阿里巴巴）:可以通过小组的GitHub页面发起相关讨论

孙冰心（华为）: 用户目前对XR/AR的接受度如何？

安勍（阿里巴巴）: XR还是有很好的应用场景
... 比如我们会选择一些跑过数据的品类（如女装），用户销量会有提升，这是需要长期的数据积累

Web Packaging （演示文稿）

陶清乾（百度）: Web Packaging是让浏览器更容易地存储页面，让用户更加快速地访问，是一种更安全的代理模式，在国内适用的场景比较多

杨智行（谷歌）: Web Packaging
... 看来大家很多人对此都比较熟悉
... 今天的 Web 让人感到navigation的慢
... AMP是Google推出的一个移动网页加速项目，一种用于提升移动页面加载访问速度的技术
... 三层不同的加速方式：AMP HTML & JavaScript；AMP CACHE; 平台 Pre-render
... AMP在页面、场景上的实现
... 将AMP功能带到Web平台，实现稳定可靠的加载，提升用户体验，保障用户隐私
... 方案#1: Prefetch 隐私问题！
... 方案#2: Prefetch + Cache
... 方案#3: Prefetch + Cache + 授权加载
... Web Packaging的功效：你的 resource 应该有个 proof-of-origin 来证明这个 resource 确实是属于你的
... Exchanges，HTTP请求/响应
... Signed Exchange，已加密签名的Exchanges让浏览器验证resource来源
... 相当于增加一层（layer）
... 开发者生成 Signed Exchange，解决之前AMP之前遇到的大部分问题
... Bundled Exchanges目前在早期研发阶段
... 愿景是可以离线加载多个站点内容 ，存储+分享页面给附近的人，实现更加快速的加载
... 开发路线图如图所示
... 最终把AMP的学习经验带到整个Web

林作健（阿里巴巴）: 假如加速了某个页面，然后更多的人访问某个页面，会不会导致产生过多的公钥验证？

陶清乾（百度）: 这个验证过程类似HTTPS，可以有证书链（certificate chain）的缓存，这样子就不会进行频繁校验。如果有Bundled Exchanges，那么校验的量会更小。

徐嵩（中国移动-咪咕）：对于多媒体例如视频直播资源的考虑？

陶清乾（百度）: 针对资源媒体也是值得用Web Packaging加速的，通过Web Packaging可以把media拿到更接近用户的地方，那么对资源加载会有很大提升

诸剑俊（英特尔）:Cache会不会加大网页访问量，会不会耗更多用户流量和电量

杨智行（谷歌）: prefetch 是一个can，不是must，浏览器能智能调配资源

赵锦江（阿里巴巴）: Web Packaging 主要的应用场景？

杨智行（谷歌）: 保证URL和内容在预期上达成统一，把内容打包在其它渠道分发

侯鹏（阿里巴巴）: cache在哪个层次做？ 更加smart的pre-fetch？

杨智行（谷歌）: 在分发平台做，例如搜索引擎的搜索结果页。

陶清乾（百度）: 关于更smart的思路，有两个，一个是提升预取效率，例如搜索结果页越靠前的页面，被访问的概率越高，预取效率也约好。另一个因为pre-fetch比较消耗资源，所以可以通过performance的API判断当前环境是否适合做pre-fetch。

Media （演示文稿）

徐嵩（中国移动-咪咕）：大家在看6月的世界杯时，主要用什么平台？
... 除了机顶盒等平台外，Web 也是我们着重的一个方向
... W3C 的 Media & Entertainment IG是由Web & TV IG演化而来，开始关注电视以外的内容
... Web平台是一个提供媒体的很好的平台
... 无论是播放MPEG、ATSC、HbbTV还是H.265，Web都是一个非常重要的途径
... MEIG每两年都会更新章程，调整自身发展的方向
... 欢迎大家参与这个兴趣组
... 分享的主要两个方向：1) 微博、微信Web视频；2) 世界杯直播中的HTML5应用
... 以前使用手机看直播的人非常少
... 现在已经非常多了
... 服务器端已经做好了视频的采集、推流后，客户端（浏览器）可以直接进行接收
... 我们遇到过一些问题，如HTML5 HLS必须为H264+AAC编码
... 现在有些直播平台还在使用Flash，CPU占用率较高，安全风险也较大
... 关于Web直播的用例，包括送礼物、评论、弹幕等
... 我们在W3C具体要做的事情，包括以下几个：音视频倍速播放（完善video playbackRate）
... 音视频清晰度切换控制：目前还没有相关的W3C标准
... 视频弹幕控制：对于一些年轻的用户，弹幕有时比视频本身更容易引起兴趣
... 弹幕在很多国家的使用都没有中国广泛，这是中国较为独特的一个用例，W3C目前也没有相关的标准
... 这是我们可以去投入和推广标准的一个很好的方向
... 另一个用例是视频打点
... 很多人看视频的时候不想一下看完，可以通过视频的一些标记过的时间点去直接跳转到对应时刻进行播放，目前W3C还没有相关的标准
... MEIG是一个很有意思的兴趣组，希望大家能够加入进来！

李根（阿里巴巴）: MEIG目前没有在直播方面有很多需要做的东西，将来还有新的计划吗？

徐嵩（中国移动-咪咕）: 在今年6月14日做世界杯的直播之前，我认为没有多少人使用手机和Web观看世界杯
... 但是事实看来用户量还是很大的

吴小倩（W3C）: 国内有些直播厂商已经开始使用WebAssembly进行编解码，并使用WebRTC进行直播
... 目前世界上很多大的直播厂商都在中国
... W3C已经意识到了这方面的需求
... 也欢迎大家去提更具体的技术提案

余枝强（华为）: 对于新特性的部署，除了实现者以外，内容提供商也是很重要的
... 请问咪咕在这边有什么计划吗？

徐嵩（中国移动-咪咕）: 目前W3C在媒体方面的负责人Francois也提到过，关于视频打点目前虽然有一些提案，但是没有比较好的提案
... 也希望我们能在用例上有更多的研究

下一代移动Web应用

百度智能小程序

吴萍（百度）: 今天给大家分享一下百度智能小程序的进展
... 标准能成为一个标准，除了技术之外，也需要生态的支持
... 希望能和大家共同建设开放的小程序生态
... 目前上线的小程序已经突破1000个，月活跃用户1.5亿
... 11月1日百度成立了开源联盟，包括百度内部的app，也包括第三方app
... 小程序为什么要做开源和标准？
... 标准的产生对用户来说，是一个更无缝的体验；对开发者来说，可以一次开发、多端运行；对宿主来说，可以基于自身生态的流量特性和分发能力提供小程序
... 首批联盟宿主的MAU总数已超过30亿
... 我们希望统一小程序的接入流程
... 简化了开发者的接入流程
... 更加统一的开发者的工具和文档
... 智能小程序的runtime core大小约为1-2 MB
... 为了保证各宿主在接入小程序的runtime之后能够有更好的兼容性体验，我们有一个测试集

@@: 刚才提到的分发平台，目前是百度自己在维护的，其他公司如何使用？

吴萍（百度）: 共享分发平台对整个小程序生态都是利好，我们也欢迎第三方合作者的参与

董岩（阿里巴巴）: 百度的标准化的诉求主要在哪里？

吴萍（百度）: 刚才提到了很多，其实多媒体的相关标准也是我们的关注点之一
... 还有性能，我们在4年前就提过一个首屏渲染的提案
... 还有人工智能

快应用

孙冰心（华为）:我是来自华为的孙冰心，今天给大家介绍一下快应用
... 快应用的概述、使用场景、进展等
... 快应用无需安装，可以方便地分享（可以通过微信、手机浏览器等方式分享）
... 快应用可以在桌面创建快捷方式，方便用户打开

[截图展示]

孙冰心（华为）: 对开发者来说，快应用是一个简单的.rpk包
... 包括manifest.json、app.ux和页面
... 分为template、style和script

[截图展示]

孙冰心（华为）：从架构上讲，整个runtime都是包含在操作系统里的，包含前端框架
... 华为在快应用的AI/AR也有进展，比如对人脸识别的支持

李伟涛（京东）: 快应用联盟的厂商之间如何协作？

孙冰心（华为）: 联盟有一个委员会，大家可以去提草案，通过后可以去实现这个标准

李伟涛（京东）: 具体谁去实现？

孙冰心（华为）: 每个厂商各自有自己的实现，但标准是统一的

董岩（阿里巴巴）: 我是来自阿里巴巴的董岩，今天给大家介绍一下Weex
... Weex主要是渲染引擎层的工作，小程序属于更high-level的技术

[展示Weex的应用情况]

董岩（阿里巴巴）: Web的开发效率很高，而性能却不足；而原生应用的性能很高，但开发效率还不够高
... Weex提供了原生的能力和接近前端的开发效率
... Weex目前面临的问题主要是：1) 性能优化 2) 三端一致性
... 微信有自己的DSL，支付宝有自己的DSL，快应用也有自己的DSL
... 这些DSL很接近，但又不完全一致
... 站在Weex的角度，我们希望能够标准化一套基于MVVM的reactive API

Hippy

裴伟（腾讯）: 今天给大家介绍一下Hippy
... Web的开发效率高，可以跨平台、动态发布
... 原生应用的性能较好
... Hippy可以通过脚本语言（JavaScript）高效率地开发出跨平台、高性能的应用
... 可以缩短开发周期、节省人力成本
... Hippy的架构大概分为三层
... 第一个是JavaScript层
... 第二层是native framework层，大部分的逻辑都在这一层
... X5在做Flutter的渲染方式
... 第三层是portable UI层
... Hippy兼容React和Vue
... 支持CSS常见的布局、外观样式和选择器
... RN、Weex和Hippy对CSS的支持情况是不一样的
... 这些框架的接口也是不一样的
... 我们希望能够定义一个标准化的接口集

@@: Hippy打算什么时候开源？

裴伟（腾讯）: 目前已经开始准备了，计划明年年初开源

Picasso

周鹏飞（美团点评）: 今天给大家介绍一下Picasso

[展示Picasso运行机制截图]

周鹏飞（美团点评）: Picasso的基本布局是锚点布局
... 我们提供了一套布局函数（hlayout/vlaout/flayout）
... 锚点布局中的布局表达和布局计算可以同时发生
... Picasso还提供了渲染的预计算功能
... 支持Android、iOS、HTML5和微信小程序

[展示Android、iOS、HTML5和小程序版的Picasso使用短视频]

周鹏飞（美团点评）: 大众点评和美团钱包的一些页面使用了Picasso

Taro

李伟涛（京东） 今天给大家介绍一下Taro
... 刚才大家介绍了很多相似的技术
... Taro是一个多端统一的开发框架
... Taro可以解决很多开发小程序的痛点
... 支持微信、百度、支付宝的小程序，以及HTML5和React Native
... 技术上，Taro分为代码编译和运行时适配两部分

[展示Taro的技术架构]

李伟涛（京东）：对于W3C来说，我们认为可以标准化的地方包括组件库的组件参数、 API 和钩子函数
... 我们希望能够开放、透明地标准化这些技术，也希望标准委员会能够有一定的执行力，推动各个厂商更多地参与标准的实现

余枝强（华为）: 现在请刚才演讲的各位上台
... 欢迎大家提各种相关的问题！

Hax: 作为一个开发者，需要面对这么多不同的平台进行开发会很困难
... Web、mobile（iOS/Android）以及众多的小程序平台
... 我也希望大家能够努力地去进行标准化
... 很遗憾今天没有微信小程序的分享
... 如果我们有了一个标准，没有微信小程序的参与，我们应该怎么办？

@@: Taro一开始只支持微信小程序，后来也开始支持更多的小程序平台
... 如果有些特性只有一个小程序平台支持，我们也没有办法
... 这就是我们需要一个标准化委员会的原因

裴伟（腾讯）: 各种前端框架层出不穷，也让开发者很痛苦
... 今天大家能够聚在这里，我也希望各大厂商线下也能够多沟通

吴萍（百度）: 我们也会在各个环节去抹平不兼容的地方，去和其他厂商对接

张翰（阿里巴巴）: 小程序平台现在已经有了很多，将来有可能还会有更多
... 大家能够来到这个会议，相信大家也是有诉求的
... 浏览器厂商达到现在的兼容性也经历了很长时间的磨合
... 我们也需要慢慢磨合

周鹏飞（美团点评）: 大家都看到了标准化的诉求
... 我们希望能够把标准拓展到Web和原生的统一
... 这样将来开发者在开发的时候就不用考虑“端”的问题

余枝强（华为）: HTML5已经推广了很长时间，但是还没有成为大家app开发首选的平台，我个人认为原因是HTML5推动的速度不够快
... 我们看到大家也在努力让API更加统一

余枝强（华为）: 国内厂商在安全和隐私方面是否有相关的考虑？

彭星（百度）: 我想问一个国内厂商关注度不够的问题，安全和隐私问题

孙冰心（华为）: 华为在这方面是非常重视的，因为是系统级的API
... 对于权限的使用，我们是有用户提示的
... 各个应用之间也是有隔离的

吴萍（百度）:百度也很关注安全和隐私
... 小程序的各方面设计都有专门的安全团队审核

@@: 国外很多大厂都在推PWA
... PWA成熟后，国内的小程序标准如何和PWA保证兼容性？

吴萍（百度）：百 度对这方面是比较 开放的
... 我们也有做PWA相关的框架
... 我们做小程序是因为有相关的需求
... 小程序是一个更快速迭代的过程

@@: 小程序的优点是更可控

余枝强（华为）: PWA更多地依赖浏览器
... 也缺乏一些device API
... 另一个缺点是不够轻量，因为PWA提供了完整的Web体验
... 而小程序对Web进行了裁剪，开发和运行都更快

彭星（百度）: 从技术上来讲，PWA是基于W3C的技术标准
... 个人觉得有多方面的原因

Hax: 我不认为PWA比小程序开发更困难
... ServiceWorker是一个low-level的API，不能用ServiceWorker和小程序去比

彭星（百度）：小程序不是一成不变 的，网络拦截的接口也是将来有可能做 的

Hax: Geolocation已经是很成熟了，但是一些现有的小程序平台的相关接口和W3C的API不同
... 希望看到小程序和W3C的API有更好的兼容性

林万铭（英特尔）: 接下来由张敏介绍 WebGPU相关的内容

WebGPU （演示文稿）

张敏（英特尔） : 刚才贺师俊作为开发者代表提出了自己的思考和共鸣，不知道贺师俊作为前端标准坚持者，是不是也支持按照标准方式开发实现标准？
... 我们也看一下WebGPU的进展，我们看到国内很多厂商在互相论剑
... 国外的Chrome和Firefox等浏览器也同样存在竞争
... WebGPU有很多层的能力
... WebGL是在嵌入式系统基础上暴露的Web的JS API
... 现在使用起来也不是很方便
... 所以诞生了Canvas之类的产品
... OpenGL ES 2.0在2007年发布
... WebGL 2.0 2017年才发布
... 只有Chrome和Firefox支持，iOS还暂未支持
... WebGL 在将来不会在iOS上有实现，跨平台有大问题
... WebGL 及 WebGPU对比
... Apple鼓励将Open GL过渡到Metal
... Google 在2018提交了WebGPU的proposal，并intent to implement
... 动机：Web应用对可编程模型和GPU访问需求日益增强
... WebGL很难满足现在的功能需求
... 所以Apple、Google、Mozilla将一起推动WebGPU发展
... WebGPU 驱动层更薄，更适合现在的技术发展
... WebGPU 将由W3C 社区组来开发
... 2017年2月成立了社区组
... 3月确立了章程
... 设计一个新的API，将现代的3D图形和计算功能的原生能力提供到多平台
... 除了Apple 和 Google，也有硬件厂商在参与（Intel，AMD...），也有华为、爱奇艺、阿里巴巴、Adobe等
... 现在的规范和实现进展
... 处于比较初期的阶段
... IDL更改还比较频繁
... 现在一共有三个提案（Dawn from Google, Obsidian from Mozilla, Web Metal from Apple）
... 计划19年完成最初版
... 近期Intel在WebGL/GPU 的工作
... 将Web GP 2.0 Compute 中实现
... 和chromium GPU Team紧密合作，每两周开会讨论WebGPU的最新进展
... WebGPU的工作方式是向chromium贡献代码

余枝强（华为）: WebGPU在性能上有什么提升？

张敏（英特尔）:Apple有Demo，但还没看到数据

Hax: 通用计算部分和现有的异构计算工具和框架有什么不一样 :)

张敏（英特尔）:其实我不太了解

Hax: 其实我也不太了解（笑）

林作健（阿里巴巴）: 开发具体是做什么工作？

张敏（英特尔）: 具体将API暴露给Web
... 在chromium做

沈毅（百度）:Metal比较偏硬件，将开发者要做的事情交给硬件去做了，有没有风险造成操作系统崩溃？
... 怎么从设计上规避这些风险？如果规避的话会不会导致性能或开发遍历不存在了
... 硬件兼容性如何？

张敏（英特尔）:需要各个厂商适配 ？

沈毅（百度）: PC上各个厂商的硬件的兼容性如何？

张敏（英特尔）：Vulkan 设计之初就是为了更好的进行CPU和GPU的调用和管理？你的主要问题是啥？

沈毅（百度）：Vulkan 的主要接口是对硬件有要求的，是不是所有手机/设备在硬件上都支持？

张敏（英特尔）：Vulkan有个dashborad会列出来每个硬件平台对于 Vulkan的支持。

Web Neural Network API （演示文稿）

张敏（英特尔）:现在ML 和深度学习非常火热
... 很多公司有很多丰富的应用经验
... Web 上有很多JS框架在支持
... ConvNetJS、WebDNN、TensorFlow.js
... 这些框架都有性能问题
... 列出性能问题对比图表
... 即便通过WASM优化，也达到了很多倍的差距
... 无论是云端、WASM、WebGL2，都有很大的性能问题，相对于原生NA
... 提议引入Web Neural Network API
... 暴露系统ML API给Web 浏览器和Web 应用使用
... 利用硬件加速，由系统底层完成
... 分层架构是基于底层的神经网络API来做的
... BNNS充分利用CPU能力
... MPS能充分利用mac 的CPU和GPU能力
... 开发者只需要使用Core ML API，不需要考虑底层的API差异
... 未来能灵活适配JS框架
... 中间层有很多碎片化问题，里面有很多TensorFlow Lite格式，各个公司（Apple FF）格式不一样
... 他们也在做神经网络训练的格式的统一
... 是不是应该在W3C中做标准的训练模型格式
... WebNN API POC
... Web NN API实现有两个方面
... 现有浏览器引入WASM和WebGL2
... 在chromium原型有新的实现
... MAC OS基于 BNNS/MPS
... Chrome 基于 @@
... 现有功能支持元数级别运算
... MAX_POOL_2D,MUL等等
... 基于原生API的映射
... 图像分类示例
... 目标检测示例
... 500+ 测试用例
... 有Benchmark做performance检查
... 一个性能对比
... Web NN对比WebGL Polyfill 16倍
... iOS上接近原生的性能
... Web NN API的合作支持
... 和TensorFlow.js、Chrome、Firefox都有合作
... W3C TAG也加入了讨论
... Web NN API标准规范依然处于社区Draft阶段
... 现在计划通过用例推动社区的规范起草和规划
... 社区组的主席是Intel的Anssi Kostiainen
... 章程是希望在浏览器中孵化用于Low Level的 API
... 欢迎在座的各位加入社区组
... 微软也将在 We Are Developers大会上推广 Web NN
... 暂时没有开源实现
... 给大家展示一下Demo
... 这是一个人脸检测的Demo
... 转换为WASM的话帧率会急剧下降（1帧）
... 转换为WebGL2的话是4帧
... Web NN可以在30帧以上
... 看一下目标检测的Demo
... 可以识别图片中的物体
... WASM/WebGL2/WEB NN的性能对比
... 谢谢大家！

林万铭（英特尔）: 大家有问题吗？

吴小倩（W3C）: 两个都是在社区组里的，能不能介绍一下在社区组里的工作模式是什么样的？

张敏（英特尔）：WebGPU是通过github issues、mailing list、irc讨论、F2F Meeting、电话会议（时差问题）

吴小倩（W3C）: 什么动力让大家（厂商）一起快速的、持续的一起做的（一个看不到未来的标准）？

张敏（英特尔）：Intel的角度 希望推动规范在整个业界的推广，从商业角度希望能和芯片业务结合。

WebAssembly （演示文稿）

林作健（阿里巴巴）: 大家好，和大家分享一下WASM目前可能的问题和解决方案
... 调试问题
... 汇编不好调试的问题
... 不太清楚如何处理这个问题
... 第二个问题是c/c++转成WASM，出现全局的stack point
... 转化为VM？不太可能了
... 另外还有一些不完美的指令选择
... 不需要基本块的代码，但把基本块生成出来了
... 试了两个不同编译器都有同样问题
... WASM中，用TypeScript手动管理内存很奇怪
... 接下来是代码生成问题
... V8和LLVM有差别
... 可能是目标的原因产生的差异
... 因为做了适配，不是性能最优的代码
... 编译时间刚才说了一个WASM包一千多个函数，编译时间长达300+ms
... 社区有个Instantiate Streaming只能解决首次加载的问题
... 后续编译也还是性能很差
... 运行时的问题
... 用2块8G内存解决Bound Check问题
... 代价太大，浪费了很多虚拟机的空间
... 缺陷是不能用于RM32的程序包或浏览器
... 间接调用所有的调用都会回到JOT，拿到index function表的指针，方法多会严重影响性能
... 调用本地API的问题，主要是在Open GL API上。
... 目前观察到的WASM的一些问题
... 希望大家讨论一下较为通用的解决方案

林万铭（英特尔）: 这些问题能提供到对应的W3C Issue里或者贡献代码吗？

林作健（阿里巴巴）:目前的技术条件不太允许贡献代码
... 解决编译问题的想法是能不能有一个本地代码生成前的字节码标准，能在本地的V8上执行

吴小倩（W3C）:现在WASM有两块标准化流程
... 在社区组可以以个人身份参与，不用代表公司
... W3C不规范实现，规范API

Web性能 （演示文稿）

陶清乾（百度）: 百度在搜索一直有一些webperf实践
... 今天想跟大家分享一下W3C webperf工作组的标准和新提案
... 工作组的目标：提供监控手段来管理website 性能
... 另一个方面是优化性能的api
... 这是工作组现在相对成熟的标准
... 很多API都在国内落地实现
... 也有一部分还在实现阶段
... 这些新接口可能都是大家关注的新特性
... 我们作为国内的公司比较关注这几个规范
... Long Tasks (TTI)
... 检测可交互时间
... Paint Timing首屏渲染时间
... Device Memory设备性能数据
... 还有浏览器新集成的机制接口

[Long Tasks demo]

陶清乾（百度）: 它帮忙检测网页什么时候出现longtask，有longtask时候页面就堵塞了，不能跟用户交互
... Paint Timing感觉国内各大浏览器都有自己的实现，但这个规范提供了一个统一接口
... Element Timing现在还没有完整实现
... 可以统计某一个元素的性能数据，避免打点的延时
... 今天TPAC大家讨论了很多有意思的新设计
... Input Timing一些输入事件从开始到完成的用时统计
... Scheduling API 主线程任务管理
... Fetch Event worker timing以一个worker为统计单位检测性能数据
... Task Worklet模拟多个worker之间的性能障碍
... Layout Stability页面layout变动程度检测
... Input Timing触发事件到完成的时长
... Scheduling API提供钩子让开发者自己决定性能优化方案
... Task Worklet例子，创建三个worker，数据共享，绕开数据传递问题
... page prerendering很好的提案，但代价太贵，浏览器支持程度不高
... 可以优化的方向，只加载和预渲染该页面的首屏
... 国内有没有web 性能方面的提案和需求？

郑宏（英特尔）: 我们是Intel Graph性能优化
... 浏览器比较依赖于benchmark
... 用户不能直接体验

陶清乾（百度）: 这是个很好的问题
... 浏览器优化和产品优化的确存在gap
... 标准只能提供解决方案

赵锦江（阿里巴巴）: 有一些CSS的问题
... CSS某些元素可以优先被渲染
... W3C怎么看CSS和性能？
... 比较失望今天没有出现CSS相关的议题

陶清乾（百度）: webperf工作组比较关注Web API
... CSS更多放在CSS工作组
... 建议下次勾股老师下次开个CSS话题

薛富侨（W3C）: CSS的确更多把性能讨论放在CSS工作组
... 比如contain、will-change、Animation Worklet

@@（阿里游戏）：比较关注WebPerf和渲染相关议题
... 感觉prefetch已经能解决很多问题
... 浏览器时间消耗不太大
... 在载入大的3D模型，或者大图时候，prepaint api会很有用

陶清乾（百度）: 百度在这个方向有尝试
... 之后可以合作
... 现在还没有对应的草案
... 可以从demo开始

WebRTC （演示文稿）

诸剑俊（英特尔）:今天来给大家分享一下WebRTC的进展
... WebRTC已经做了5、6年的时间了
... 主要在做两方面：1) Media Capture 方面的标准 2) 核心WebRTC标准
... gUM是一个最近很火的标准，很多厂商都在参与
... 主流浏览器厂商（Chrome、Firefox、Edge、Safari）都已经支持了WebRTC 1.0
... WebRTC Next Version可能会做的事：底层数据访问、机器学习、worker支持和虚拟现实
... 日本的一个大学做过一个demo，将WebVR和WebRTC结合
... WebRTC的实现情况可见WPT（wpt.fyi/results/webrtc）
... 也可见KITE Dashboard（kiteboard.herokuapp.com/score）
... Mozilla写了一篇文章，讨论了WebRTC的演进
... 如果国内的浏览器基于一个较老的Chromium版本，可能会无法支持更新的WebRTC API
... WebRTC的初衷是做客户端到客户端的通信
... 现在也可以做服务器和客户端之间的通信
... 因为HLS等方式延迟较大，部分厂商选择使用WebRTC
... WebRTC虽然是Web标准，但也可以和很多原生应用互通
... 今年TPAC讨论比较多的话题包括：Simulcast and SVC、QUIC transport和WHATWG Streams based APIs

@@: 很多音视频的算法都适合硬件相关的，导致WebRTC的性能较差
... 将来是否有计划暴露硬件的编解码能力？

诸剑俊（英特尔）: 这个和标准的关系较少，和实现的关系更大一些
... 浏览器也在做一些硬件加速
... Intel的会议服务器的转码和混流也在做这方面的优化

Web Payments （演示文稿）

吴小倩（W3C）: 今天给大家介绍一下Web Payments
... 到今天为止，各大银行、发卡组织和很多互联网公司都在参与Web Payments相关的工作
... 开发者只要学习和使用一个接口，就可以提供更好的支付体验

[展示demo]

吴小倩（W3C）:整个设计思路就是Web开发者无需做用户交互，把用户交互交给浏览器即可

[继续展示demo]

吴小倩（W3C）:我们希望提供一个更优雅的体验
... 目前四大浏览器都实现了Payment Request

[展示 jcrew 的 Payment Request]

吴小倩（W3C）:我们希望Payment Request将来能和Web Authentication API结合使用

杨智行（谷歌）: 我去年在Google I/O的时候，他们也在说支付宝和Payments Request的结合，不知道现在的状态如何？

安勍（阿里巴巴）: 我们和Google合作的地方主要是Manifest

总结

陶清乾（百度）: 今天大家很多问题还没有问完
... 比如Web Packaging方面有许多需要讨论的，我们可以组织线下的专项讨论

余枝强（华为）: 今天很荣幸见到了很多朋友和“网友”
... 小程序的生态现在还是处在一个「割据」的状态
... 希望后续能有更好的兼容性
... 一点点推进
... 尤其是新的API

林万铭（英特尔）: 很荣幸能当上这个小组的主席
... 大家提了很多问题
... 我们希望能够整理这些问题，反映给对应的工作组，进而推动整个Web的发展

徐嵩（中国移动-咪咕）: 我们从公司的意愿角度来讲，有很大的意愿
... 也希望W3C中国能够协助大家
... 对于有明确计划的公司，希望将计划能够写在会议的总结里面
... 这是一个小的建议

陶清乾（百度）：我个人觉得这个建议挺好的
... 我个人有一个小的要求
... 比如中国移动对于媒体感兴趣，可以提议什么时候组织一场线上或者面对面的会议，提议具体的action

徐嵩（中国移动-咪咕）: 我们打算明年办一场M&E IG的专题研讨会
... 希望有意愿的公司能来参加

李安琪（阿里巴巴）：我觉得今天的会收获很大
... follow-up很重要
... 今天梳理了差不多10个topic
... 如果移动的同学感兴趣，可以成立一个媒体相关的Task Force
... 小程序有人感兴趣吗？

余枝强（华为）: 华为感兴趣

陶清乾（百度）: 百度也感兴趣

李安琪（阿里巴巴）:WebRTC/WebML/WebGPU?

林万铭（英特尔）: Intel

李安琪（阿里巴巴）: Web Packaging?

陶清乾（百度）: 百度可以接下来

刘思杨（百度）: 我是百度的AC Rep
... 我们可以定下来一个目标，这样成果更加显性一些
... 最后形成一个report
... 比如10家公司对某一个特性的发展方向有共识，可以以这10家公司的名义向W3C做技术提案

李根（阿里巴巴）: Chinese IG对于社区外宣的工作有什么计划？

贾雪远（W3C）: 感谢你的问题！
... 我们希望能够共同建立一个品牌
... 比如做定期分享，今天的会议总结可以分享给社区

吴小倩（W3C）: 小程序和快应用这两个task force都可以出独立的技术提案
... 其他的task force可以更多地出用例

李安琪（阿里巴巴）: 中国公司在参与标准化工作时，可能会和外国公司有一个针锋相对的过程
... 我们需要提前想好这个问题可能会遇到怎样的质疑
... 把这些提前想好再去提技术提案

余枝强（华为）: 用户场景很重要
... 如果有好的用户场景和现有的实现，并且解决了用户的痛点，推广到标准应该不会太难
... 具体的技术细节可以在提技术方案之前再进行打磨

吴小倩（W3C）:过去5年我和很多厂商接触，大家都有很多的 想法
... 很多公司有过提案，但最大的一个障碍是语言障碍
... 这个兴趣组也希望能够减少参与标准工作的语言障碍

赵锦江（阿里巴巴）: 我个人在前几年在HTML5 Chinese IG做过一些事情
... 当时的参与者没有这么多，所以今天看到这么多人参加，我很开心
... 关于翻译，MDN是一个很好的网站，文章质量很高，也有一些中文翻译
... 相对MDN的文档来讲，W3C的文档对于浏览器开发者更有价值一些，可能对于这些开发者来说翻译的需求较少
... 跳出中国，国外的W3C相关技术分享也是浏览器厂商为主

张秋怡（Igalia）: 兴趣组有没有向web-platform-tests做贡献的计划？

林万铭（英特尔）: Intel做了很多测试方面的工作，如果大家希望贡献，我也很乐意提供帮助

陶清乾（百度）: 百度和UC浏览器也在做运行WPT测试方面的工作

杨智行（谷歌）: 我同意语言障碍是一个非常大的障碍
... 比如你要和一个说法语的native speaker使用法语来辩论一个话题，会很困难
... 如果大家作为一个团体去参与会好很多
... 比如一个人去辩论，如果卡住了，还有另一个人可以去帮他/她补充
... 有一个问题：大家有什么需要给Chrome团队反馈的吗？
... Chrome的文档缺少中文版，这是一个known issue

余枝强（华为）：希望Chrome的技术演讲能够分享到国内

林作健（阿里巴巴）: 我向Chromium提交过代码，因为时区问题，提交代码后2-3天才有回复，而且还是英文的，阅读起来很费劲，后来还要处理很多次review，所以就放弃了

吴小倩（W3C）: Chrome团队其实有很多中国人或者会说中文的人
... 直接联系他们也是一个方法

贾雪远（W3C）: 提到翻译，对于新加入W3C的人来说，了解W3C的一个途径可以是从一份文档开始了解
... 翻译文档也是了解文档的一个途径
... 除了大家熟知的志愿者翻译，W3C还有一个翻译途径是授权翻译
... WCAG标准是一个例子，浙大领头进行了该标准的authorized translation，正式的国家标准也参考这个中文版
... 翻译也是一种承认/认同志愿者贡献的方式
... 夜深人静伴着柔和的灯光，精心翻译一份标准文档，还是很惬意的 :)

陶清乾（百度）: 非常感谢大家能来参加这个会议！

【会议结束】

若您对本次会议有任何反馈，或希望了解/参与W3C Web中文兴趣组工作，欢迎联系我们！