大会吸引我的地方实在太多了，先写一下10号我的一些感受和见闻，11号的明天更新。

这次来上海参加GDD已经是第二次了，去年18年的GDD我就跑过来了体验了一次，也在世博中心举行。

一早的动车到了上海站，地铁里遇到了好多背着去年GDD发的书包的程序员宅男。

从中华艺术馆下车步行400多米就到了，这次参会没有让在外门合影，简单的照了一下门口的logo，还是去年的味道和感觉。

看右下的大哥发型，就知道这是一场不一般的聚会。。。

排队进站之后上午是集中在主会场进行的开幕仪式和一系列介绍类型的Topic演讲，不得不说这一届最吸引我，最喜欢的是过场时的BGM，真的非常带感，我都在座椅上都快跟着抖起来了。

开幕式前的几个视频小短片我也很喜欢，比如介绍ARCore的一些实际应用场景的广告：

之后又介绍了一些TensorFlow的使用场景，重点推荐了智绘甲骨还有观妙中国这两个使用场景，去了的人都知道，很有意思的Google文化和艺术跟科技以及深度学习框架的各种可能性和结合点。

其他商业方面的案例比如：

1. 有道作业宝，机器学习检查作业，整页判题。
2. 美团外卖，机器学习推荐菜品，机器学习配送系统。
3. 出门问问，智能硬件音箱，解决方言问题，粤语交互，TensorFlow语音建模云识别。

到了9点半正式开始，第一个主题是陈俊廷的大会致辞：

其中重点说了Google成长计划 ，包含了开发者 企业 学生和老师三个方面，利用Google的技术帮助中国的各种人群做技术赋能。比如提供微信小程序的接口，做国内的免费IT课程面向教育机构和老师们，还请来了百年职校的17届学生，帮助他们了解IT技能和程序开发。

第二个分享是我们大家都熟悉的金安娜，一位说着津味和东北口音的美女工程师（逃。

主要分享的是关于TensorFlow最近升级的一些情况，比如TensorFlow的2.0的特点。

TensorFlow面向的人群定位，以及主要功能。

如何在中国的商业产品中被企业采用和落地。被点名的有网易的严选商品推荐，还有一个微信里学习手语的小程序。

然后是TensorFlow的下载量已经达到4100w下载量，社区维护工作做的也非常好，经常组织一些线下交流，在11号还做现场的TensorFlow Roadshow。

第一页就秀了一把所有特性列表，然后开始重点介绍一些亮点功能，比如Android 10 原生支持5G。

整个系统支持省电的夜间模式，深色主题。

然后介绍了Android开发者都熟悉的Kotlin语言，有超过50%的Android开发者在使用，语言增长速度排github第一。

比如说模板代码极其简短，左边Kotlin，右边原生Java：

还有Kotlin的一些其他优势，比如工具改进，更多的demo，可控性注释，udacity课程，对程的更多支持等，还有开发语言上的一些优化，比如Java10 对语言特性的脱糖，OpenJDK源码库的脱糖，改进的C++17支持，和NDK文档。

说完了Android方面的一些事情之后，进入我比较关注的主题了，web环节是由paul kinlan带来的chrome v8的新特性和开发者工具相关的一些介绍。

比如这张图，后边好几个分享都反复提到的chrome新特性API，提供给开发者们更多的可能，只不过很多还在实验室阶段。

进行了增强的API还有分享功能和分享target功能，还有对应Web也支持了省电的夜间模式。

当然Lighthouse也已经都内置到了chrome开发者工具中，方便开发者对页面性能进行检测和打分。

去年没提过的还有一个web.dev的内置，它可以帮助开发者分析自己的web app，帮助开发人员学习并将 Web 的现代功能应用到其站点和应用中。

还有Firebase和Google Analytics的结合，帮助你优化你的网站和用户访问行为，帮助你做更好的推荐等等。

接下来是我比较关注的Flutter相关的一个介绍，来自Flutter产品经理 樊舟颖的一个分享。

首先介绍了什么是Flutter，解决了什么问题，比如跨端，免费开源，易扩展，让你的应用开发成本降低等等好处和特性后，总结了Flutter这一年来的进步和增长趋势。

然后和去年一样当场宣布的了Flutter1.9的上线，并且介绍了一些这个版本的新特性。

比如把网页版的编译合并到了Flutter的主干上，让大家更方便的编译web端的视图程序。还给大家演示了一段如何把Dart的语言demo编译成web端的JavaScript demo，然后还通过对比webview内置web端展示效果和Flutter的端内编译效果对比，来给大家看到了对比后的性能反馈结果，Flutter的还原度和流畅性是非常高的。

接下来是Wear OS的一些特性介绍，比较吸引我的是加入了卡片的设计，让表盘的灵活度和使用率，空间展示都扩大了许多。

还有就是对特定的使用习惯加入了很多场景Card，比如通勤，运动，天气等。

之后是ARCore的一个介绍，和一开始我发的视频差不多，举例了很多国内的应用实际场景。

最吸引我的一个场景就是滴滴的AR提示找路的场景，简直太适合我了，在商场里不分东西南北的人也可以通过ARCore提供的能力来对车辆停靠点的一个指引提示，说是计划很快会推出到生产环境了，我非常期待。

接下来是负责Google 文化和艺术的一个分享。

比如在观妙中国APP里在线进行艺术品画作的各种细节观赏能力的展示让我非常感叹，技术的进步确实可以带来无限可能。

通过人脸识别算法提供肖像画和用户照片的匹配，帮助人们认识和了解更多的大师肖像画。

最后，也是上午开幕式的最后一个分享，是北京Google研发中心的负责人，主要讲了一些Google对开发者社区的一些组织贡献和Google的技术产品在中国的一些普及情况等等。

上面这部分是开幕的一个我个人的总结，都是比较吸引我的点。然后是后边的分会场讲座，我的专长是web领域，所以上午听了2个场次的web分享。

第一个是《渐进式web应用，从移动设备到桌面设备》

从标题我们就知道，这是要说PWA了。

首先这次ppt分享的非常接地气，因为都是中文哒，开篇就介绍了网页和应用也就是PWA的区别对比，介绍了网页能做的和PWA能做的各个方面能力。

然后是总结了桌面应用的一个优势，主要是体验上的好处。

然后引入了PWA的一些必要和突出功能，比如应用的manifest文件配置，如何修改状态栏样式，UI等，还有sw的重要性，操作系统功能的打通，和一些未来的api。

后边详细介绍了Workbox，它是一个帮助更好的处理Service Worker的一个辅助库。

如何处理PWA安装逻辑的代码展示。

使用了PWA和非PWA的实际对比结果：

同样的这张图出现过好多次，就是未来的一个chrome新特性API：

以及这些API的开发计划和进度：

第二个关于web的分享是《实现适用于web的新功能》，这个分享继续了PWA的这个分享，开始详细介绍，一个新的API的研发周期和流程步骤，并且对这些API的具体能力进行了讲解。

比如剪切复制功能的升级，支持了async的调用方式，方便你去处理剪切板的数据：

还有Badging的API，也就是小红点提示。

选择通讯录的能力，必须用户行为才能触发，保证用户隐私和安全。

定期同步数据的能力，每次打开应用获取最新的后台同步好的推送数据。

处理本地系统文件的能力，保存修改另存都可以轻松实现了，帮助开发云IDE做了基础。

上午的分享基本就这么多，中午吃饭的时候基本人都是爆炸状态，在饭厅还碰到8年前在阿里UED的前端开发同事，感谢Google开发者大会让老朋友多年又相见。

中午饭还不错，香蕉挺好吃的（毕竟都是程序猿，我知道为什么发香蕉，我有这个觉悟。。。

下午时间比较轻松了，web场的分享只有一个比较感兴趣，就是TWA，没错，我一开始也是懵逼的，PWA，AMP我都是知道的，但是TWA是个啥东东？

1：45去听了这个《如何在应用中使用TWA》：

这个小姐姐有点紧张，不过后边放开了，不说演讲者了，我们进入正题：

使用方法很简单，几步导入即可，然后介绍了一下app和TWA的交互方式，就是互相调用的机制，类似一套路由匹配系统。

然后TWA是向前兼容的，目前android的设备支持率达到了95%，android4.4以上的版本都可以使用。

要构建一个符合沉浸式的TWA应用要符合以下几点，比如首先要是一个完整的PWA应用：

整体总结下来就是TWA始终和chrome保持一致，展示的内容也能始终使用chrome中的最新功能，TWA就是android应用中的chrome，代替简陋的webview，提供更好的用户体验。

基本上web的内容，10号就这么多，剩下的时间我又去客串了一下Flutter的分会场，嗯。。爆满了。

《腾讯，字节跳动和Grab等公司有些共同之处？他们都使用Flutter构建应用》

这个主题开始的部分和开幕式有一部分介绍是重合的比如，Flutter的1.9版本特性等，这里就不展开说了，主要说一下在腾讯，头条和Grab的实践和收益，当然除了这几家公司之外还有很多公司也在使用Flutter构建跨端的应用。

在腾讯的英语君中，他们采用了Flutter的一个特性，利用Flare来进行动画的直接转义，大大降低了动画的调试成本和难度以及工作时间。

借助于闲鱼贡献的很多Flutter和开源的力量，他们也使用了更多的一些Flutter能力。

效果也很简单直接，Android和iOS平台的Dart代码占比90%，大大减少了迭代需求的跨端兼容时间，节约人力成本45%。

然后是头条在海量产品中的尝试，内部工程师的高认可度带来了开发效率的提升：

比如从实现原理机制上，Flutter就比其他跨端平台实现框架少了桥的消耗，支持C++代码直接调用，所以性能上是优秀的。

选择Flutter的理由也很简单，性能体验超越其他同类框架，平台一致性带来的研发效率提升也是非常可观的收益。

当然Flutter也有一些缺点，需要社区和业界的一起改变和尝试。

而Grab则是在RN和Flutter同时使用的情况下，经过实践，最终选择了Flutter为跨端技术提供支持，目前已经上线的有GrabFood和GrabPay。

提升效率从实际的产出上说明了一切：

看的我也想去写写Dart了，最后的一部分还介绍了Flutter在社区举办的Flutter Create大赛，第一名也来到了现场。

基本上10号我的几场演讲就都听完，说完了。

要说除了这些分享之外，还有什么吸引我的，当然就是GAC部分，展区的体验馆啦。

印象最深刻的有2个demo，一个是ARCroe帮你做产品演示，比如咖啡机的使用：

扫码启动后，通过AR技术演示整个咖啡机的制作流程，非常方便还节约了真实的咖啡原料，非常有趣。

还有一个好玩的就是通过摄像头捕捉人的动作，让古瓷器进行对应的响应，有点体感游戏的意思。

玩完一圈体验区之后，就是让人激动人心的对换礼品环节了。

只要参与了Google现场的问卷调查表，然后拿着调查表问卷验证码就可以领取一个Google开发者大会的纪念书包！

更新一下11号的日程，我现在正坐在D702上往北京走，今天的分享整体来说，更偏专业一些，我听了4.个分享。

《如何快速构建Flutter混合应用》

《从非智能手机到桌面浏览器，如何快速打造流畅的web应用》

《与Web一同成长：中国案例研究》

先说第一个，《如何快速构建Flutter混合应用》

分享来自阿里巴巴团队，作者来自闲鱼，整个分享一直在说或者主题目的就是解决Flutter在和native应用混合开发时如何解决工程化和集成的问题。

闲鱼本身是就是一个基于原生和Flutter混合应用的一个实践案例，除了刚才说的集成问题，细化来说就Flutter和原生应用组合时如果采用多Flutter实例的话，性能消耗，换场切换时内存消耗过多等问题都无法绕过，闲鱼采用的是单Flutter view复用解决的，还有就是单view中如何做自己的router的问题，Flutter 实例和同原生路由集成通讯等问题。

为了解决上面这些通用问题，闲鱼开源了他们优化和集成后的Flutter Boost。

关于工程化的问题，无论是在Flutter中包含原生还是原生包含Flutter，都需要解决隔离和通讯的问题。 一开始闲鱼采用的是gitsubmodule和ci集成编译的方法解决的，我是用过git submodule的方式开发过隔离项目的，集成起来确实非常麻烦，为了解决这个问题，Flutter boost最后采用了软连的方式来实现了集成编译，无论是本地源码还是远程或者构建后的应用都能做到方便的集成编译。

然后作者在线演示了一个Android的混合Flutter如何安装和编写Flutter Boost的例子，成功在模拟器里用很少的代码实现了原生混合项目的集成。

总结一下就是这一页，Flutter Boot做到了把Flutter项目转换成Flutter Module的实现，通过软连实现源码的隔离集成和依赖，实现了混合路由功能，做到了开箱即用，也可以说是Flutter混合项目的脚手架工具。

第二个分享，《Local Home SDK》是关于物联网的主题，我们先看一下分享者下面这张Slide。

如果你家有一个Google Home音箱，而家里又集成了其他智能设备，比如一个智能灯泡，那么你一开始接入这个智能设备的流程可能是通过服务商的一个APP，然后利用服务商的私有云服务上传和下发指令来实现控制流程。而Google Local SDK的流程则是在Google的智能印象中引入了一个本地SDK的概念，通过Google Assistant的来进行发现和控制局域网的其他设备，比如你说开灯，之前可能是需要通过转发到开发商的云服务上，通过Local SDK，流程则变成了先发command到Assistant，然后Assistant如果发现本地的这个设备使用集成了Local SDK，那么这个指令则通过本地Local SDK本地直接控制设备了，目的是什么呢？

通过Google Local SDK可以降低命令延迟到300ms以下，因为无需再和代理商的云服务进行实时控制的交互了，并且提升可用性到3个9，因为本身Local SDK也是支持向前兼容的。

前端同学看到这里是不是惊呆了，有意思的还在后边。

上面这张图是整个实现流程的拆解，控制设备和发现设备是如何运转的呢。

首先，你需要在Actions on Google上配置你的智能设备Scan Config，用于扫描和发现本地局域网中开发商自己的设备。然后Google Assistant感知到了你的Scan配置，会对Google Home下发这份配置，然后开发商还需要在开发商的私有云服务商开发一个SYNC response的接口配置，用于本地的Google Home音响里的JS应用在第三步Identify识别设备时，匹配一个识别ID。来保证这个设备真的是你能控制的设备，必须完全一致。

然后开发商则需要通过编写TypeScript代码来控制自己的设备了，Google Local SDK的演示代码如下：

那么我们如何调试这个JS呢，TS编译成JS通过TSC可以很方便的做Bundle，而调试就更方便了，可以直接使用chrome inspect功能就可以了。

前端同学非常熟悉的界面出现了：

只要你在Google 的托管服务上指明了你的本地调试地址，你的调试地址和你的Google Home还有你的调试mac，都在一个局域网，那么你就直接可以在inspect页面看到对应的网页，对里面的js进行debug了。

最后到目前为止，Local SDK最后的发布还没有对外开放发布功能，需要在Q4的某个时间点才会公开发布功能的使用。

整体来说这场分享最大的收获是我了解到了物联网设备的一个整体流程还有Local SDK在其中起到的一个优化作用和实现思路，还有就是JS真的是哪哪都有它的身影啊，最后TS大法真香。

上午的分享基本就到这里了，下午的第一场web分享是《从非智能手机到桌面浏览器，如何快速打造流畅的web应用》。

这个主题非常有意思，讲的是如何在多端多设备之间让你的web应用尽可能的快和可用。

我们能发现Google的首页在pc和老式手机设备上都展示的还不错，因为比较整体搜索页面非常简单。

然后我们再看这个应用：

oooops，直接样式和功能就挂掉了。这个网站是Google那边做的一个在线对图片做压缩裁切的服务，对于网站的可用性来说，左边这种老式智能机，全球还是一直在销售的，占有率还非常的高。那么我们如何来做这种适配工作呢（表扬了一下twitter，这方面做的非常好）。

然后作者展示了一个他们做的project，是一个类似扫雷的游戏，然后给我们带来了这个web游戏应用是如何来做多设备的适配和性能优化的。

1， 所有设备都以相同的方式运行，既一套代码。

2， 实现所有输入设备的控制，比如鼠标，键盘，触摸，还有screen readers等。

Ok，任务看起来还是很艰巨的，Google的开发团队是如何实现的？

首先他们的架构分了4块，1，纯游戏逻辑。2，UI控制。3，一个统一的render。4，utils。这4部分都是使用JavaScript来实现的。那么它们是如何组织到一起工作的呢？首先为了不阻塞主线程，使用web worker在子线程中做纯的游戏逻辑控制，然后通过封装好的post message（Comlink已开源）来进行通讯控制，让主线程来进行UI的绘制。

没错，UI控制部分，他们选择了精简版的react，就是preact来实现的组件化。

然后再通过puppetter来进行的预渲染，结果出来就是一完整可运行的html结构了。

除了预渲染和腾出主线程的优化方式之外，绘制的过程也充满了坎坷。

一开始选择了Table来做扫雷的实现，但是发现在chrome上的一个bug，table一个格子颜色变化了，整个table都会跟着变化颜色，解决方案也有就是对table分层，但是分层后由于button太多，有多少button就要有多少层，这个方案不合适。

那么换成canvas就没什么问题了。

ok，requestAnimationFrame，这个大家都很熟悉了，随分辨率刷帧的api，那么背景图能不能优化呢？答案是可以的。

每次绘制背景都是1/5的面积然后再用放大功能放大就好了，因为背景本身就很模糊的一个效果感觉。

点击button后的效果需要每次绘制，那么我们把他们存在本地db吧。

避免了重复计算量，降低主线程阻塞，让动画更流畅。

Canvas上的事件怎么做呢？

UI和控制分层，在canvas上盖一个table就好啦。

保证可用性怎么实现呢？有了，我们用focus和button的tabIndex来做焦点控制，对于前端来说非常好理解了。

低端的android机上经常跑不起来，崩溃，怎么办呢？本质原因还是cpu太烂导致的，所以在做动画效果时需要对矩阵shader效果动画做向下兼容。

首先判断是否支持webgl，通过ShaderBox来进行探测。

而motionPreference这里的意思是某些系统中用户可以设置优先减少运动，避免创建运动的样式。而这个设置可以通过prefers-reduced-motion这个媒体查询标识获取。如果用户设置了这个偏好，那么就可以减少用户的动画cpu消耗。

交互形式上为了代码体积的优化，放弃了模拟滚动，全部滚动都采用原生滚动，同时放弃了tap的判断。

非触摸屏机器显示焦点环。

给用户提供快捷键指南。

提供fixed定位的关闭按钮而不是在滚动容器里提供关闭。

最后提供离线能力和缓存，以及首屏分包的功能。

当然最后作者也说，如果你有更好的办法可以让这个stuff更小，可以给他们提pr。

当然为了保证代码体积，他们也在CI里集成了体积报告。

最后项目的地址在这里：

11号，我听的最后一个web的例子，我本来没有抱太大的希望，但是听完之后收获还确实不小（还是web优化技巧），那就是最后我听的这一场《与Web一同成长：中国案例研究》。这一场其实分了2个小的主题。

第一个是，如何优化基于Nodejs的SSR页面效能，分享来自腾讯视频的前端开发工程师。

这个分享整体比较干，但是其实我个人感觉是老酒装新瓶了。首先分析了SSR服务的一个后端响应时间的瓶颈问题在哪里。

这两页ppt非常清楚的说明了，使用chunk技术的优点，以及服务端相应时间的瓶颈在于外部的IO阻塞。

那么如何解决呢，下边给出了实际的例子：

腾讯首页通过分块chunk的一个改造后的状性能情况，指标以及lighthose和线上数据。

效果很美好，但是问题也随之而来了。

因为拆分chunk，需要对页面模块来进行区分，比如手工拆分模块和数据依赖管理等，增加了开发和维护成本。

解决办法很屌，腾讯的工程师基础还是好，会编译原理就是可以为所欲为啊。

提供自动化的chunk服务在预编译阶段就通过AST解析nodejs的render模板，自动找到依赖关系和数据，做异步化的管理。

实现流程是这个样子的：

1， 解析模板，查找第一层的模块节点。

2， 分析这个模板下面和数据有关系的标记，通过AST解析出依赖关系。

3， 根据依赖关系，在生成新的code，新code用promise all包裹每一层的和数据标记有关系的promise结果。

4， 在输出chunk块的时候，迭代模板表达式，然后判断当前这个模板是否为异步模板，是否有数据依赖，如果有的话就把之前的chunkCache写到chunk里，然后当前这一次的异步模板，添加之前生成的数据链，在reslove的时候把结果合并到chunkCache中，如果不是异步模板则直接把静态结果加到chunkCache里。

通过这种渲染方式，就实现了页面的分段自动chunk输出，而不需要人工维护异步模板和拆分模块实现chunk功能了。

第二个分享还是腾讯的，做的是出海的一个项目webnovel，分享主题叫《使用web新功能优化用户交互》

说是web新功能，其实就是AMP+PWA的一个实践。

AMP很熟悉的东西了，我这里用大白话解释一下，就是Google提供的一套全球静态服务CDN加托管加AMP交互套件，通过Google的加速和优化后的AMP套件实现统一标准的可提高性能的搜索结果页面。

嗯，服务用AMP技术后，pageload时间降低了87%，这个很关键，国外的网络很烂，Google的CDN很强。

这个东西是解决，AMP页面的url是google域名而不是真实产品域名的一个体验问题的。（因为托管了）

然后又提到一个技术就是在AMP里提前安装主站的servicewoker来进行资源和接口预加载的功能，提升跳转后的性能。

添加到桌面功能很重要，从数据上看各项用户粘性指标都很高。

基本上我11号的分享听的就是这么多，因为火车是晚上7点的，所以4点多就撤了，基本上这一天都是在web场坐着。

整体今天给我的感觉就是技术细节变多了，干货变多了，很赞。

最后感谢Google开发者大会带给我们这么多新的思想碰撞，可能这就是开发者大会最迷人的一点吧。

再见，上海GDD，明年再会。