[自我介绍]
李安琪（阿里巴巴）: 我们有来自于公司、科研机构等各方的参会人员
… 请Judy做一个小程序 chalk talk
朱红儒（阿里巴巴）: 很多人不太习惯讲英文
… 我在AB上提了这个兴趣组的建议
… 我不太适合讲技术，但是我想讲一讲为什么要做标准化
… 我认为标准是「上层建筑」
… 开发者可能认为代码最重要
… 但是「上层建筑」也很重要
… BAT等很多公司都在现场
… 中国从秦朝就开始做标准
… Philippe, China began standardization work since the Qing dynasty
… 我认为最需要标准化的产业是通信产业
… 因为需要互通
[介绍2G -> 3G -> 4G -> 5G移动通信标准]
朱红儒（阿里巴巴）: 有的公司可能认为专利进了标准是一件好事
… 但是不止如此，更重要的是大家一起把蛋糕做大
… 5G如果不进入标准，是没有市场的
… 我不喜欢「话语权」这个词，太政治化了
… 但是我们需要更多的参与标准，而不只是作为一个旁观者
… 刚才我讲了通信
… 物联网标准也很重要
… 开发者需要和服务器以及其他设备相连
朱红儒（阿里巴巴）: 在数据大爆炸时代，还有很多数据相关的标准
… 这里列出了一些W3C标准
朱红儒（阿里巴巴）: 我很高兴今天能够讨论小程序和快应用
… 2018年1月完成了W3C中文兴趣组章程草稿的撰写
… 2018年6月正式成立W3C中文兴趣组
… 我们也讨论了一些proposal，希望能够转化为W3C标准
[展示小程序产业生态图]
朱红儒（阿里巴巴）: 希望我们能够一起撰写一个白皮书之类的文档，定义小程序，并提交到W3C
… 讲清楚mini app, super app, native app的区别
… 小程序为什么需要标准化？
… 现状有两大问题
… 1. 碎片化
… 2. 成本高
… 当年IE6不遵循标准，最后也没落了
… 有的标准是强制的，比如质量标准
… 拥抱标准，帮助开拓市场
… 标准不只是paperwork
… 只写一个提案出来是不够的
… 标准需要运作，需要建立市场
… 需要真正去做事情
… 小程序标准化在2018年11月日本AB会议时最初提出来
… 今年的AC 2019也进行了讨论
… 今天需要讨论「做什么」和「怎么做」的问题
[展示小程序技术栈]
朱红儒（阿里巴巴）: 我觉得在W3C有几种工作方式
… 比如创建一个新的工作组
… 如果在现有的各个工作组里工作，可能不太好找哪部分在哪个工作组
… 我们也可以自己把小程序标准打包一起输入到W3C
… 最后，我希望我们合力一起推动标准
… 对于不适合标准化的部分，我们也无需勉强
… 小程序大部分的市场都在中国，所以在中文兴趣组里先讨论完这个事情再推到W3C效率比较高
… 谢谢大家！
Philippe Le Hégaret (W3C): 很抱歉我不能说中文
… 在W3C，有很多不同方式进行贡献想法让Web更好
… 几年前，我们创建了两种新模式的社区组和商务组
… 帮助大家聚集社区，共同推进想法
… 一个成功的例子是WebAssembly，从Mozilla的一个游戏项目推进成普识标准
… WICG是一个特殊的社区组
… 上面有非常多不同的想法，聚集了很多不同的浏览器
… 在W3C有一个很重要的组，Web技术架构组
… 有点像技术的架构委员会
… 会员提案允许公司把想法提交给W3C，推进成标准
… 一个例子是大众的汽车数据提案
… W3C使用GitHub进行所有的标准讨论
… Strategy Funnel是我们管理所有的新技术话题的GitHub项目
… 欢迎大家加入里面的讨论
… 研讨会，是W3C把一个相关话题聚集在一起共同讨论用例、需求、技术提案的会议
… 下个月我们有个游戏研讨会，讨论云游戏等新技术对Web的需求
… 十年前我们开过一个视频相关的研讨会，为HTML5提供了很多有用的输入
… 非常建议大家进行一个小程序相关的研讨会
罗创杰（vivo）: 如果我想提一个提案，应该去哪个工作组？
Philippe Le Hégaret (W3C): 如果是小程序的话，启动一个新的工作组是一个比较好的方案
罗创杰（vivo）: 我听说正式W3C标准需要2个浏览器实现
… 中国浏览器的实现是否count？还是只包括Chrome等国际上的浏览器？
Philippe Le Hégaret (W3C): 这是一个很有意思的问题
… Edge开始基于Chromium
… WOFF 2.0去年发布，有一个算法只有一个实现
… 因为所有人都用同一个实现
… 那不是一个必要的条件
… 必要的条件是「implementation experience」
[讲者自我介绍]
[PWAs Recap]
元凯宁（英特尔）: 整个session想要覆盖的内容是讲PWA和小程序有什么不同，有什么可以借鉴的
… PWA是Web做application的一种自然的延续，解决要通知用户，桌面打开等问题
… PWA不是一个技术标准，而是一系列技术标准的总和
… PWA还有一个特点是在商业上很成功，由于时间关系，暂时不给大家展示后面的具体商业案例了
… 微软宣布要将PWA应用作为Windows的一等公民对待
… Google宣布应用商店中将要支持PWA
… [Gartner曲线图表，展示大家对PWA的期望曲线]
… Microapps
… 另外一个应用趋势是Android的Instant Apps
… 这两个要解决的问题和场景与小程序的很像
… 另一个传统代表是CS MVC和Apps
… 技术成本比较高，随着技术发展，热度会逐渐降低
… 你的网站如果想要留存客户，推送消息，只需要简单的外挂PWA的Service Worker和Notification就行
… 另一个就是PWA当前只有一些有限的能力
… 刚才提到了Google的fugu，fugu就是开放了很多原来没有的API出来，来增强Web应用的能力
… 另一个常见的误区是PWA和native app
… 是对立的，其实不是，他们适用于不同的应用场景
… 还有一个是PWA没办法在中国使用，其实国内有很多案例，包括163，weibo，csdn
… 我们现在回到小程序，讲一讲小程序和PWA有联系的几个点
… 第一个是比较成功（DAU/MAU）比较高
… 小程序另外一个值得关注的点是标准比较多，有很多个厂商和很多个标准
… 很多个框架，让开发者选择比较困难，这个可能是快速推进过程中的必然，可以理解
… 另一个特点是User Engaging
… 还有实用性
… 抛一个观点，小程序会不会是下一个Copy from China的候选者？
… Facebook会不会复制小程序？
… 小程序是一种新的Web技术还是偏离了Web技术？我没有答案，有待大家一起讨论
… PWA和小程序的区别
… PWA和小程序的共性
… 都是Web的技术来驱动的
… Fast TTM，cost efficient
… 另一个共性是可达的入口很多
… 解决安装App的繁琐流程问题
… 相比App，开发者对更新和分发更可控
… 功能上的需求很多，迭代很快
… 开放标准的方式？促进PWA和小程序其中一些标准的融合
… Intel在其中做什么？
… Intel Web Team有Web标准的实践经验和技术，具体需要Intel Team做什么，我们期待今天讨论的成果，一起来帮助大家。
魏嘉汛（百度）: 刚才提到了PWA和小程序Could be the one
… 问题是现在在国内发展的情况下，小程序和PWA是否是竞争关系？
元凯宁（英特尔）: 也许在API层面上会有，但在市场选择上不一定，这个和商业模式有关，具体用的技术也不需要限制在某一种。
李安琪（阿里巴巴）: 刚才元凯宁讲的，关于小程序走向国际化的时候，需要看看国际的趋势是什么？哪些能为我们所用。
雷志兴（百度）: 阐述一下PWA和小程序的观点
… 都在浏览器运行，但其中的理念和思想有不一样的地方
… 我们认为小程序并不是一个全新的东西，其实还是一种Web的应用形态
… 我们只是对他有一些全新的设想
[自我介绍]
[百度智能小程序案例展示]
[展示总体模块构成]
雷志兴（百度）: 整体分为两部分，一部分是开发部分，另一个是运行时部分
… 开发部分与Web关系不大，是一套开发流程和开发工具的总和
… 小程序开发工具不是浏览器
… 运行时部分包括两部分，一个是渲染框架，另一个是APIs
[整体研发工作流]
雷志兴（百度）: 和Web一个很大的区别是需要用自己的开发者工具完成开发和模拟，并且要将小程序上传到管理平台，审核后上线
… 第一个打开小程序需要下载一个体积较大的数据包
… 百度小程序和其他小程序有一个区别是也可以在浏览器中运行
… 另一个是介绍小程序平台的研发工作流
… 流程是平台/引擎研发，然后是小程序应用研发，然后是在客户端运行
… 简单总结一下，小程序相比起Web的一些区别
… 编程思想、多WebView、原生能力、AI/AR能力、厂商实现近似
… 优势：原生页面转场，原生组建和API（迭代更快）
… 劣势：冷启速度慢，通讯成本，开发调试复杂
… 百度小程序的特点：代码开源，一次开发，多app平台运行，快速接入
… 再讲一下小程序的运行时
… 一部分是端的API，包括端能力和云端能力
… 还包括APP版本控制，多应用的管理，状态控制和页面栈
… 通过JS Bridge传给JS层
… JS逻辑层可以理解为一个V8
… JS视图层可以理解为一个WebView
… 小程序如何渲染，视图层运行的是一个可见的界面
… 逻辑层和视图层隔离一个要解决的问题是安全问题
… 视图层中没有业务JS，只有CSS，所以能做的事情非常有限。
… 另一个是性能有提升（遵循MVVM编程模型），只需要通过setData和getData的操作就能完成视图更新
… 对大部分开发者，自己操作Dom效率会很低
… 在Web（浏览器）中的运行态介绍
… 通过iframe模拟类似视图层的多个视图
[浏览器中访问的Demo演示]
雷志兴（百度）: 浏览器也有视图层和逻辑层，通过iframe来完成隔离，保证安全
… 这个设计能让开发者对运行环境无感知
… 支持Web环境的目的是需要让URI和URL对应上，并且为搜索引擎提供Web中真实的视觉信号
… 最后简单说一下小程序的测试用例（CTS）
… CTS解决的是小程序框架会被合作伙伴修改源码，CTS是一系列测试用例集，保证小程序的能力在所有运行环境中的表现一致
… 大家有什么问题？
侯鹏（阿里巴巴）: 百度智能小程序在标准化部分有哪些思考和建议
雷志兴（百度）: 百度小程序在不断前进探索过程中，我们思路也是开源和开放的，这也逼迫我们需要往标准的方向上思考，包括哪些是我们要强制遵守的原则，哪些是可以开放的。我们也希望拥抱标准，尝试建立标准。
… 和W3C想看怎么能把两种不同的标准的差异融合，推向国际
@@: 前几年百度在推MIP的技术，两个技术不同的区别是一个会加载SDK
… 两者有什么区别和后续的发展？
雷志兴（百度）: MIP更像AMP，在任何浏览器都能跑起来。小程序需要端能力集成。MIP更像纯Web世界的东西，小程序更像Web+客户端结合的世界的东西。
… 对于业务上来讲，更多的会投入到小程序里面来，对技术上来说，不同技术应用于不同场景，不冲突。
李安琪（阿里巴巴）: 茶歇时间，11:03回到会场
[信息无障碍的概念介绍]
王炜（浙江大学）: 任何人在任何情况下都能平等、方便地理解、交互和利用信息。
[互联网普及规模图表演示]
王炜（浙江大学）: 手机网民占98.6%
… 残疾人PC普及率只有40%，手机普及率有70%+
[Demo: 演示读屏软件遇到的问题]
王炜（浙江大学）: 信息技术在发展时也给残疾人带来了前所未有的基于和挑战
… 当前问题是残疾人不一定能方便的获取到丰富的互联网资源
… 盲人和聋人面临的获取信息问题最为突出
… 盲人愿意用微信和支付宝这些小程序，因为小程序的登录非常方便，不需要验证码
… W3C发布了无障碍标准（WCAG 2.1）
… 国家无障碍标准主要基于WCAG 2.0
… WCAG 合规性测试
… 介绍自研的一套无障碍合规性测试的系统
… 系统包含人工检测和自动检测
… 纳入盲人评价体系来辅佐人工检测和自动检测
… WCAG 2.1 可感知性
… 包括文本内容和非文本内容
… 可感知性的常见问题
… 非图片并未提供具体图片含义
… 控件输入，用户不知道要输入的是什么东西
… 合规案例，邮箱属性标识
… 验证码问题，目前无障碍比较大的问题是支持无障碍的验证码
… 解决方案：语音验证码，问题验证码，数字运算验证码，短信语音验证码，还有其他
… 第二大类是时基媒体
… 时基媒体的可感知性常见问题
… 音视频媒体的替代方案
… 感官特性
… 音频或视频播放器控制问题
… 可操作性
… 主要是键盘问题
… 可理解性
… 鲁棒性
… 总结：无障碍改造需要遵循标准
李安琪（阿里巴巴）: 希望在今天的研讨会里，在做小程序，快应用技术设计的时候，无障碍的标准需要考虑在其内。
… Q&A?
元凯宁（英特尔）: 现在的小程序里无障碍的支持是什么样的？
雷志兴（百度）: 百度昨天刚发布了一个关于无障碍的计划。之前也试了一下读屏软件在百度小程序中的效果，基本能满足，后面会继续提升。
崔广宇（携程）: 百度提到了AI，是否能用AI机器人模拟盲人来进行测试？
王炜（浙江大学）: 机器模拟盲人本身是一个不太可行的方式，盲人很多外部、内部（先天盲、后天盲等）因素都会对测试结果有很多影响，无法很好的模拟出来。
… 可以通过众包的方式解决人工测试问题
[U4内核（UC浏览器内核）介绍]
成国凯（阿里巴巴）: U4是chromium based
… 同时服务web网页和小程序、小游戏等
… 从Web角度看小程序是什么？
… 小程序是基于Web技术往上延伸的一个App开发框架
… Chromium三大技术方向，其中一个是Web Platform往Web App Platform转变
… 无论是PWA还是小程序，都是应用的一个轻量级的解决方案
… 这些技术为什么都选择Web 渲染引擎技术？
… 标准化、跨平台、动态性强、兼容性好
… 富媒体/富文本、排版引擎灵活
… Web引擎有广泛的应用基础，兼容性好
… 另外一个是快速分享，快速迭代更新
… 开发效率高，一套代码多平台复用
… 第二个是技术领先
… 看一下小程序的解决方案是什么样的？
… 有一个独立的逻辑层，保证开发者不能直接接触到底层渲染引擎的实现
… 让开发者不能直接操作DOM
… Web标准广泛，开发者开发水平能力参差不齐，通过逻辑层对开发者实现做限制，在性能上是有很大收益的。
… 另一个是数据驱动的方式，这个在开发模式上和传统Web开发方式有本质区别
… 小程序和普通Web语法上的diff比较
… 小程序解析出来的和Web是一样的
… UC在这一块做了什么？
… UC提供了一些能力已经被广泛使用（例如地图）
… 希望已经实践不错的一部分native能力能融合到小程序中来
… 混合渲染方案
… 混合渲染技术在Web引擎中如何考虑？
… 借鉴了一些Flash插件的理念，把native组件作为WebView中的一些组件，来去拓展属性
… 小程序采用混合渲染技术支持了许多组件，包括：Map，Video等
… 另一个技术是V8服务化
… 让小程序能更好的去拓展端相关的能力
… 使用JS Bridge来打通
… 把V8 Plarform独立出来，实现逻辑层真正的隔离
… 从安全角度来说，这一块很重要
… 小程序监控体系
… 小程序在性能指标、可控性指标上没有标准的方案
… 内核在如何去监控和度量，做了大量的思考和工作
… 从开发者角度，如何评价小程序，也有一些思考和标准化的思路
[展示小程序框架图]
成国凯（阿里巴巴）: 小程序要走的远，其中需要底层技术支持的好，包括性能、安全等方面
… 小程序是数据驱动开发的，所以通信层传入多少数据，渲染引擎如何处理，是需要技巧的
… 开发者接触到的是JS Worker，但有用户UI 事件时，传递的链路很长，需要考虑从底层的渲染引擎直接传递到JS Worker中
… 以类似的思路来解决小程序渲染和交互的性能问题
… 框架演进探索
… 我们有一部分框架是用JS来写的，我们希望其中一部分逻辑下沉到V8里
… 这里抛出一些思路
… 在逻辑层会有一些Virtual DOM，DOM diff通过JS实现性能问题比较大，是否可以用native实现？
… 另一个是sendData链路，能否有更高性能的执行通道
… 一个小程序包完整加载是否能变为渐进式的解析与加载和渲染
… 使用Worker直接监听并处理事件让事件传递性能更好
… 需要结合Native能力来优化，开发者通过JS优化很难达到很好的性能
吴小倩（W3C）: UC和Chromium团队是否有合作？
成国凯（阿里巴巴）: 有的
… BlinkOn上Google邀请了我们
… 和V8、Chromium有很多联动
@@@: 小程序V8这边的能力是UC提供的还是用的国外的？
成国凯（阿里巴巴）: 内核主要提供Low Level API，上层框架通过API实现框架逻辑
… 和小程序是一起联动的
@@@: 浏览器本身包含了JS和渲染引擎
… 小程序是复用了UC的V8，还是单独编译了一个？
成国凯（阿里巴巴）: 代码复用，但是是两个环境
罗创杰（vivo）: 会把DSL放到渲染引擎中去吗？
成国凯（阿里巴巴）: DSL不是引擎能力，引擎会提供能力提升DSL性能
… 不存在阻碍小程序DSL的扩展
刘守群（小米）: 混合渲染部分的问题
… 合成是用内核的渲染器去合成的还是用的Native的View？
成国凯（阿里巴巴）: View组件混合渲染是将Native组件盖在Web组件上面
… Offscreen Buffer混合渲染，借鉴了视频，输出Offscreen Buffer进行流式渲染
刘守群（小米）: 把Native view的Buffer放到Chromium中去解析渲染，会不会性能上开销更大？
成国凯（阿里巴巴）: 没有太大差异
董宏平（滴滴出行）: JS引擎是否有一些限制？
成国凯（阿里巴巴）: JS执行环境不是在Webview中，而是在JS Worker中，没办法直接操作Webview的JS Runtime
… 为什么这么设计，是因为小程序希望减少开发者的开发复杂度，能更高效快捷的开发应用。可能过程中有不合理的机制，但会一直在优化，而且标准上也会有进步。
… 确实可能存在一些diff
董宏平（滴滴出行）: SJS逻辑层执行JS为什么会比视图层的快？
成国凯（阿里巴巴）: 因为提供了性能和功能balance后的最小集，所以能更好一些？
陈胤立（小米）: 大家好，我是来自小米的陈胤立
… 我们在快应用联盟中的工作方式类似于标准化组织
… 重要的是求同存异
… 大家需要提前说出来「为什么要做这件事」
… 和一些超级app上的小程序不同，快应用依赖于系统本身
… 所以「场景化」很重要
… 在场景上，包括智能助理、语音助手、第三方应用等
… 在能力上，包括URL跳转、系统intent、传送门等
… 举一个例子：智能助理
[展示智能助理案例]
陈胤立（小米）: 再举一个第三方app的例子：导航服务
[展示导航服务案例]
陈胤立（小米）: 我们希望在我们的场景和能力上结合各种第三方服务，让系统成为一个有机整体
… 在场景上以卡片化的方式显示内容和服务
… 打开关联页面进行更复杂的操作
… 我们也希望在场景和应用之间打通数据
… 现有的生态：原生应用、web app
… 当然还有小程序
… 原生应用的widget只针对桌面场景，且功能不够丰富
… 而web app可使用的系统能力较少
… web app最初是针对浏览器进行设计的，有些不利于多场景
… 比如去中心化分发可能存在安全风险
… 在多个场景使用同一服务时，因为在不同的进程和WebView中运行，数据是不打通的，可能需要重新登录
… 场景和卡片数据打通也缺少标准
… 我们希望快应用能够使用标准化的调用形式
… 希望在不同场景下的数据能够打通
… 希望能够有中心化的分发
… 希望支持原生渲染，比如在刚才的智能助理场景中，我们希望性能表现优良
… 在小米的语音助手上，会自动分析语音并转化为对快应用的调用，打开相关页面
… 第二种调用方法是隐式的、不明确的调用
… 快应用将内容原子化，并进行重组
… 在日历和短信当中都可以获取火车票信息
… 这个和具体的服务商是有关联的
… 可以在整个系统中保持一个快应用实例
… 快应用卡片和快应用可以通过这个实例来沟通
… 通过快应用卡片，我们把一个快应用的部分功能嵌入到了另一个快应用
… 谢谢大家！
杨刚（百度）: 快应用中WebView在哪一层？
陈胤立（小米）: 我们是原生渲染
… 但我们也提供了webview
Philippe Le Hégaret (W3C): 打开url下载的是包还是什么？
陈胤立（小米）: 是一个完整的包
董宏平（滴滴出行）: 快应用的实现是不是和微信等小程序的实现差别比较大，而更像react-native？
陈胤立（小米）: 对
李安琪（阿里巴巴）: 今天上午的议程就到这里
陶清乾（百度）: 大家好，我是来自百度的陶清乾，下午第一个session来自百度的沈毅、黎欢
黎欢（百度）: AR/AI 及 Benchmark 标准化的探索与实践
… 刚开始做小游戏遇到一些坑
… 转一转启动黑屏问题
… 侠客行，FPS不稳定
… 全民打雪球：场景不稳定等问题
… 目前问题已经全部解决
… 解决了三方面的问题
… 第一方面：启动性能
… 我们采用了流式解压
… 加载相关的性能，刚开始偏线程，使用了第三方解码，后来我们替换了渲染方案
… 第二方面：渲染相关
… 第一是减少切换的次数，同时在恢复和保存的时候做一个diff
… 减少了状态的数量
… 做了省像素的预处理
… 关于字体的渲染
… 按照字体的size做了分区，减少了内存，同时也降低了纹理数
… 第三方面：JS引擎相关问题
… NA调用的问题，减少了JNI ref的使用，算短查表时间，同时优化了数据传输
… 目前优化后传输数据与数据大小关系不大了
… 有7-8倍的收益
… 我们还在做一些版本升级
… 在GC策略方面
… 目前我们在做一些idle GC的事情
… 关于benchmark
… 目前我们需要一个低成本的评估方案
… 我们根据多平台支持等需求自己开发了benchmark
[Benchmark示意图]
黎欢（百度）: benchmark评分策略
… 分数等于每个case得分和
… 支持可视化图表的展示
[Benchmark demo]
沈毅（百度）: 大家好，从开发者角度，我们在开发小程序过程中遇到了很多兼容性的问题
… 实现上的不一致不能完全反映出来，刚开始做小游戏的时候，尽量与现有的接口做一些兼容，如果小程序能标准化，会解决很多这方面的问题
… 接下要分享的AR与AI也是小游戏相关的问题
[Demo展示：AR的应用，可切换视角通过触摸控制改变车的颜色等]
沈毅（百度）: 所有的接口都在探索中，还没有落地，也想听听大家的意见，浏览器层面目前也有webxr的标准
… 自动追踪、平面检测、锚点等介绍
… 环境的预估等
[小游戏代码的示例]
[帧数据更新代码示例]
[点击放置交互代码示例]
[Demo - AR在人脸方面的扩展]
沈毅（百度）: 使用了人脸检测，骨骼模型特征点
… AI有一个更好的用途是去感知周边的环境，我们也在考虑更多的暴露底层接口
… 我们目前准备开放的一些接口
[AI基础能力代码示例]
沈毅（百度）: 刚才介绍的这些在W3C中的标准中都有相应的工作，immersive-web相关的一些信息
陶清乾（百度）: 时间关系，两个topic各提一个问题
余枝强（华为）: AI用的是Web NN API吗？
黎欢（百度）: 不是
余枝强（华为）: 大家好，我来自华为
… 我的topic是Web 3D/AR 标准化探索与实践
… 我从另一个角度讲一下AR体验
… 我们认为手机设备，或者多场景环境 去呈现
… 我们想通过融合的产品去实现3D
… 苹果通过自己的AR的quicklook的方案把3D和AR融合在了一起
… 3D可以有多种开发方式，现在比较简单的是通过手机就可以生产，这样则降低了3D内容的生产
… 社交平台可以将3D内容分享出来，同时购物平台通过AR，对商品做了很好的展示
… 搜索平台中，可以用3D模型展示搜索结果
… 抽象出来为，3D内容平台在服务或云端
… 在本地可以预览浏览，然后再部署到各个平台
… 但目前还有一定问题，开发量将会特别巨大
… AR我很希望能在Web中简单使用，但在Web中，3D开发难度较大，渲染效率低
… 我也希望可以将3D加载在自己周边环境中，目前web内容的处理和分享该类型的3D面临一定问题
… 目前正在推gITF来3D资源
… gITF 的生态链的展示
[gITF结构示例]
[Web 3D-AR demo 演示]
余枝强（华为）: 可以将3D模型添加到现实环境中，且同时对3D模型放大缩小
… 通过<x-model>标签简单地提供一些API
[3D-AR逻辑架构图]
余枝强（华为）: 希望可以通过一行代码、一个链接来开发分享
… 也希望通过这样的模型绕过WebGL的一些局限
… 集合web的便利性
… 标准化的方向，在3D模型方面khnoros在做一些gITF的标准，我们有一些推荐，在声音等
… 在W3C中，我们希望推<x-model>类似的标签
[行业内对3D的支持示例图]
余枝强（华为）: 苹果，Magic Leap，Google和华为在这方面做了相关的事情，我们希望通过<xmodel>在标准化方面做一些努力，让更多的3D资源被使用。
郑锐奇（腾讯）: 这些标签是在web环境中实现的吗？
余枝强（华为）: 很多在native，在用web使用过程中可以调出来这些
… 我们会有切换模式，我们只要引入标签，这些都会在指定位置出现
杨刚（百度）: 如果有标签的话，后续有没有相应的JS提供
余枝强（华为）: 对的，我们觉得xmodel是第一步，在围绕xmodel上我们既可以逐步加入API，也可以与WebXR的API统一，所以我们需要的是开始第一步
… 标签中应该包含什么属性，都是后边可以考虑的
陶清乾（百度）: 欢迎来自阿里的承玉，分享小程序技术实践以及相关 Web 平台能力建议
承玉（阿里巴巴）: 我来自支付宝，今天会介绍小程序在支付宝的发展
… slides中有我的钉钉二维码
… 小程序是蚂蚁开放策略的一个载体，将近20万的小程序数量，2.3亿DAU
… 通过小程序呈现我们多年沉淀的能力，如安全、人工智能、客服保障等
… 一些小程序使用的领域，基本涵盖了所有生活服务
… 技术实现，DSL（小程序语法）-> bundle -> 小程序容器（包含webview、canvas等）
… 主要使用react，并做了一些扩展，同时还使用了native SDK和webview
[开发语言的展示]
[运行架构的展示]
承玉（阿里巴巴）: 渲染模式相对较少
… 采用了混合渲染，这方面并使标准的做法，希望这次讨论找到一些标准做法
… 采用IDE一站式开发
… 支持真机渲染、调试，同时也支持真机性能数据与建议
… 真机数据包含了CPU的数据，也会给出一些建议帮助开发者优化代码
… 支持一站式整合云服务
… 都可以在IDE中完成
… 在开放平台，具有平台监控能力，异常监控，调用统计，报警等
… 正在做一个开源平台
… 官方有两个扩展库，mini-antui和mini-chart，已经开源
… 后续重点在底层上，JS引擎和渲染引擎
… 小程序目前有一个中间层，数据传输效率也是需要优化的一个问题
… 阿里小程序计划已经全面启动
… 会有相应的补贴
… 小程序后台会考虑放在云端
@@: 你们的DSL是react系的吗？会有别的支持吗？
承玉（阿里巴巴）: 目前不会，我们的已经确定了DSL的标准
@@: 制定的这样标准的出发点是什么？
承玉（阿里巴巴）: 不希望分裂，希望生态有一个共同的标准。
魏嘉汛（百度）: TS是标准的TS吗？
承玉（阿里巴巴）: 是的
魏嘉汛（百度）: 目前非标准的东西会比较多，支付宝在这方面有什么标准化的计划吗？
承玉（阿里巴巴）: 这次我们会谈论这个问题，worker和渲染方面，我们都希望有轻量级的东西来支持小程序
陶清乾（百度）: 下边欢迎锐奇，主题是跨平台框架对 W3C 标准的实现达成统一
郑锐奇（腾讯）: 大家好，我来自腾讯，接下来我会讲到框架的标准化，我们在考虑做一个小型的浏览器，这样能很好的与W3C的标准对齐，我们今天在这里主要是为了抹平差异。
… 我们自己做了个框架叫Hippy
… 6月份将讨论是否开源
… 第一部分，现有的框架Hippy/RN/Weex/快应用等
… 不同小程序不支持业界内通用的全端框架，有独立的接口
… 第二，开发者对平台的选择
… 需要多平台适配
… 为了与之前给予react/vue等对齐
… 可自由拓展
… 支持HTML等
… 优点：开发易入门，对react/vue开发友好，跨平台API对齐
… 劣势， CSS支持问题，底层API不一致
… 第三，底层代码API统一的需求
… 底层API对齐上，常规API方面timer、console、canvas、network fetch等的对齐
… 公共能力的api，如平台分享、登录、支付等
… 新能力API，领先于W3C草案的能力，如XR
… CSS方面的对齐
… 几个基本点的支持，flex，盒模型的可定制
… CSS的长度单位的统一
… pt、rpt等不同长度单位
… 支持业务层自由选择JS框架
… 第四，如何对W3C现有标准的拓展
… 与web components 的结合
[代码展示]
郑锐奇（腾讯）: 与现有的W3C的标准对齐，share api的草案，感觉目前share api的字段不能满足国内需求
… 从而减少适配成本
成国凯（阿里巴巴）: 内核这一块基于一些开源项目在做还是从0开始在做？
@@: 整套架构是由不同的团队来支持做的
成国凯（阿里巴巴）: 回到web引擎来看，web排版和渲染灵活度较高
… long list这方面Chromium有@@在做，可以参考这方面来做
… 两位在这方面有什么看法？
@@: 我们最早也是在用RN，从使用到放弃（法务问题，及其他问题），还有别的平台的问题，再遇到各种问题后，我们决定自己做一些东西
@@: 微信小程序，分层渲染没有用X5来实现，你了解相关的问题吗？
@@: 不了解
陶清乾（百度）: 下一个话题为王安的跨端开发一致性实践问题与建议
王安（数字天堂）: 先说一些小程序和HTML5的冲突的一些问题
… 元素、JS API等不一致，小程序也拿掉了DOM等重要的东西，与目前浏览器的运行机理也完全不同
… 微信封装了一些属于自己的部分
… 有很多的混合渲染
… 小程序扩展了一些能力，如扫码等
… 增加平台的开放能力
… 小程序和HTML5在管理层面也有很多冲突
… 小程序不是网页，不基于URL，是本地的JS包
… Web是开放的，而小程序是管理权限属于平台
… 专利问题，如果涉及到专利很难上升到W3C规范
… 把小程序规范纳入HTML规范的难度非常大
… 容易去做的是补充一些组件，如switch等
… 补充一些API
… 一些比较深层次的改进建议
… 考虑增加flexview的组件，只支持flex，大幅提升性能
… serviceworker需要提升
… 重新梳理小程序规范，更加开放
… C/S和B/S的问题，普及wgt的规范
… W3C的API不能灵活更新
… 应该在浏览器内部增加动态扩展的能力
… 目前国内标准统一方面还有很多的问题存在
… 小程序以webview为主
… flex排版等问题
… 互联网厂商目前差异较大
… 如果要统一新的规范，各个厂商的内部规范也是很大的问题
… 统一规范还需要解决规范名称、文件扩展名、API前缀等问题
… 让开发者接触iOS、Android、HTML5、微信之后的第5个新的平台难度较大
… 生态建设难度也比较大
… 这里提几点对互联网厂商的需求
… API的不同，自定义组件的支持不完善，影响uni-app
李安琪（阿里巴巴）: 王总所讲内容是将来小程序能生命力的直接体现，如果这些内容能够做通将对我们有很大的影响，我们也是需要开发者的声音，我们需要好的方案把这件事落地。
崔广宇（携程）: 你所讲的这些问题，我们在开发过程中也都遇到了，定标准的时候，会不会把某个厂商的标准直接定为通用标准
王安（数字天堂）: 确实很难
… 你也可以尝试一下我们的产品
@@: 小程序适合在W3C标准化吗？
王安（数字天堂）: 我的个人观点是直接把某个厂商的东西拿到标准里难度太大，如果底层的webview等足够强大，小程序也可以比较简单的去标准化，呈现百花齐放的模式，如果W3C能做到这些，那么互联网将会更加开放。
陶清乾（百度）: 谢谢王总，中文兴趣组在组织这个会之前，我们也讨论过这个问题，我们并不是希望W3C解决所有小程序标准的问题，但是小程序与web有共性，我们希望把这些问题暴露出来，在这里讨论那些更适合在W3C标准，同时与浏览器厂商的利益也会是我们讨论的问题
张楠（滴滴出行）: 大家好，我会提一些具体的解决方案
… 在做变色龙的过程，遇到了很多的一致性问题
… 界面开发中组件一致化非常重要，所以我想提这方面的建议
[各个厂商组件化对比图]
[各个厂商组件化样式表现对比图]
[各个厂商组件化事件模型对比图]
张楠（滴滴出行）: 建议快应用和小程序能遵循W3C的标准
… 另外一个提议是架构模式方面的问题
… 跨端框架较多使用MVVM模式，建议W3C提供该标准
… 建议提供结构化的调用语法
… 提供一个接口对界面进行更改
… 如果小程序都使用该接口，开发更加简单
… 定义5个标准，框架协议标准、API接口标准、组件标准、DSL协议、多态协议标准
… 组件化包装
… 对比WebIDL标准和我们设计的跨端框架的IDL
… 建议components输入输出显式声明
… 任何的组件都应该显式输入输出
… 无需看完所有代码就能知道输入输出
… 如果有显式声明，则可以废除observerAttribute
[小程序和web组件继承能力对比图]
张楠（滴滴出行）: 建议小程序开发组件遵循W3C的继承方案
… 对W3C组件能力加强
… 小程序和W3C组件的视图表现调用一致，组件基础能力一致
吴小倩（W3C）: 对于你刚才提到的显式输入输出等技术提案，W3C的webcomponents repo里也有相关讨论，希望中国厂商能够有所输入，可以去GitHub参与
陶清乾（百度）: 感谢大家的参与，我们以后无论线上还是线下还会继续开展讨论，做一些有效输出，会议到此结束，晚上还会有一个沙龙，有兴趣的同学可以参与交流。
... 我们将在会后和公众分享本次会议的现场讨论纪要及总结，如需做任何修改，请联系 W3C 中国团队成员。