写在前面

上一篇博客写了挺多开发者大会期间的花絮(虽然花絮本身就是开发者大会重要的组成部分)，而在这篇博客里将更专注于session本身，对场外的花絮和花边新闻尽量少的提及。话不多说，我们开始吧。

Android things

安卓things是一种支持世界各地计算需求的新平台，其出现的初衷是简化IoT设备的开发和生成。安卓things运行的仍然是安卓系统，因此对安卓开发比较熟悉的朋友可以很快的上手来完成一些应用。

在现场，演讲者详细演示了如何在大会赠送的Android things设备上进行程序开发。他利用温度传感器和气压传感器开发了一个温度计和气压计的应用。开发共分为三个步骤：

1. 拼装器件Assemble，组装说明
2. 烧构件版本 Flash Android things
3. 开发应用 Develop Apps, 用Android studio 3.0+

例子部分最重要的是学习如何对外围设备进行输入、输出，怎么让程序知道某个按钮被按下了，怎么样将传感器测得的值显示出来，以及如何整合应用外围设备输入输出库的驱动器。感兴趣的朋友，推荐去codelab学习一下。codelab也是谷歌极力推荐的一个学习网站，在展区有一个专门的展台，而且越来越多的教程被翻译为了中文，还是挺不错的。

PWA的框架和工具

渐进式网页应用(PWA)上篇已经简单的介绍过了，第二天依然有两个session围绕着它展开。首先是PWA的工具，讲者首先介绍了为什么要工具。所谓工具，就是让用户更方便的完成某项工作的东西，节省用户的时间。

PWA一大特点是节省用户带宽，让浏览器和网页了解你的应用，在默认生成的基础上，如果能帮助用户指定决策就更好了。Chrome在开发者panel中可以看到安装时和安装后的网络请求情况，将运行时的网络请求可视化，从而对用户制定缓存策略产生一定建议。

在构建PWA时，他介绍的通用工具是Workbox这个JavaScript库作为创建、测试、体验Service Worker的工具集合。接下来他介绍了PWA和Vue、react、Angular等流行框架的CLI如何结合使用，主要是如何基于json进行配置。

TensorFlow

TensorFlow真是火，如果说去年的GDD主角是Angular，那么今年的主角无疑是TF。从分会场排的长龙以及增加的场次，不难反映谷歌的策略已经从Mobile First 转为了 AI First。这个session依然是金安娜全程用中文来介绍的，虽然有时候结结巴巴的，但还是坚持了下来。这个session主要是广告，说TF怎么受欢迎、TF在医学领域取得了成功(超过了很多年经验的医生)、AlphaGo战胜了世界顶级围棋选手。TF支持了更多的硬件平台，包括CPU、GPU、Cloud TPU甚至安卓、ios、Android things。最后简短的带过了TF的架构。

TensorFLow架构图 

ARCore

作为有望与人工智能抢风头的AR，自然也是本次大会的一个亮点，ARCore这个session由负责技术与用户体验的两个人来共同完成。

首先是技术人员上台演讲，他介绍了沉浸式计算的发展历史，随后介绍了ARCore的发布量:100,000,000. 介绍了ARCore的新特性,即环境识别和光线估测。

随后是负责用户体验的工程师上台演讲，她介绍了在展区看到用户还是很习惯性地去用两个手指Zoom in 和 Zoom out，而不是尝试去移动摄像头和模型进行交互，当用户葛优躺在沙发上的时候会比较懒惰，更不会去移动身体离开舒适区。她建议，在程序内给予用户明确的提示或合理的理由，让用户进行移动。

随后舞台交还给技术工程师，他宣布了chrome将支持ARKit和ARCore的大新闻。我觉得这个才是对于AR的重大利好，因为很多年轻人都不会愿意购买头显，买了的也很可能不会随身携带，更别提父母辈的中老年人了。而如果Chrome支持了AR，那么无疑将大大降低AR的使用门槛。教程链接

关于ARCore框架本身，分成了四个部分来介绍。

1. 跟踪状态
2. 平面
3. 特征点
4. 光估测

跟踪状态指的是无论你摄像头怎么动，模型也会跟着进行一定的角度和位置变换来欺骗人眼，以为模型真的就更场景融合到了一起，这一过程也叫偏移校正。这里需要提到的是锚点的概念，即AR的对象添加的实际的对象时指定的位置。

另一个概念是平面，这需要一定的时间来进行检测，跟ARKit一样，也是采取的用若干特征点确定一个平面的方式，我们都是知道三个点可以确定一个面，这里采用多个点可能是从计算的效率方面出发的，快速确定平面以及平面的边界。当然，平面的多个平面也是可以同时检测到的。

光线检测的例子让我印象比较深刻，它采用的是一头狮子，当灯关闭后，似乎被惊吓到了，然后跳了起来，对检测光线从亮到暗这一过程的诠释简直完美。视频地址。

Android Oreo

Android 8.0版本名是奥利奥(流口水),不可避免的也在本次大会上开了几个session，由于我不是安卓开发者，所以在选择分会场的时候，基本都避开了这个主题，但由于某些分会场人多到进不去了，又不想浪费时间，也零零散散的听了一些。

首先是Android Studio的更新，可以帮助用户分析并提升应用的性能，也是采用的可视化的方式，将网络请求、CPU使用率、内存管理等控制用户体验核心的一些指标按时间序列进行了可视化，从而用户可以方便的看到，在哪些时间点资源的消耗比较明显，从而进入到相关函数内部进行优化。现场举了一个内存管理失误并修正的例子。

后面听了半场用架构组件来写安卓应用的session，在Angular里，组件的好处就挺多的，例如：

• 让应用更加健壮
• 易于测试团队进行测试
• 可维护性提升了不少
• 耦合程度低，适合团队开发等等

这里她重点介绍了安卓组件里的两大特点：可被观察、可感知生命周期。可被观察类似观察者模式，可以带来的好处是关联了生命周期、避免内存泄漏。以持久化数据Room组件为例，它带来的好处包括：

• 减少了样板代码
• 查询结果转化为JAVA对象
• 编译时验证SQL语句
• 查询结果可被观察

由于没有听全，加上对安卓开发没有基础，这里只能丢出一些链接供感兴趣的读者参考：

开发者频道
GitHub例子
简书

一句话总结安卓这个我不了解的领域：谷歌在帮助程序员来优化他们的应用：自动检测将资源用量进行可视化，甚至是帮助用户分析即将离开应用的用户，增加用户粘性；组件化开发降低开发安卓应用的难度和速度。

未来网络的潮流

这个session的标题很宽泛，是对未来趋势的一个预测，这个话题还蛮有意思的。

新API

演讲者是个德国人，他认为以后的web应用应该以全屏PWA为主，现在已经可以将display属性设为”fullscreen”从而将手机顶部的时间、蓝牙、wifi信息掩盖掉，配合现在的全面屏手机，营造出一种沉浸感。

第二点他谈到了网络推送通知已经可以和原生的应用一样，举了一个macOS里通知中心的例子。它遵循macOS系统勿扰模式的设置规则，更好地与平台集成。

接下来是PWA的一大优势：service worker导航预加载，利用这个功能，在用户发出GET导航请求的同时，系统在Service Worker启动的同时启动网络请求。虽然这无法避免启动延迟，但却可以消除网络请求受阻的限制，让用户能更快获取到想要的内容。

接下来是一键注册的API，使用Google电子邮件地址创建账号。支持使用之前选择的信息实现回访用户自动登录。介绍链接

存储空间估测方面，开发者经常遇到这个问题：存储空间是否还够支持下一个操作？选择这个问题得到了解决.API链接

Image Capture API，利用这个API，可以捕捉静止图像，以及配置相机的硬件设置。API链接

Shape Detection API，用来检测面孔、读取条形码甚至进行光学字符识别(也就是常说的OCR)功能。API链接

Media Capabilities API，这个API让媒体在流畅播放的同时实现高能效。通过获取与设备解码功能相关的更多信息，帮助开发者在为用户选择媒体流时候做出最佳决策。比如为好一些的手机设置1080p甚至4k的媒体流，为千元机设置480p的媒体流。API链接

NetInfo是为了完善上面的API设置的。主要是检查手机的网络，如果支持retina显示的屏幕，但是目前只有2G，也选择非高清的媒体流。API链接

WebVR，一种开放标准，将虚拟现实的体验带到浏览器中。参考链接

Navigation Timing API,获取设备总体性能的API，比如网页的render耗时、网页加载耗时、网页连接耗时等。同样是为了针对不同用户给出不同媒体流的一个判断。API链接

JavaScript新用法

动态模块导入，延迟加载JavaScript代码，在需要的时候动态加载代码，提升用户体验，提升应用性能，类似于Swift里的懒加载。

异步生成器函数，简化流式传输数据的消耗。可用于for-of循环以及通过异步迭代器工厂创建自定义异步迭代器。

Promise中的Finally方法，确保系统无论在啥情况下都执行需要的操作，无论Promise最终是被接受还是拒绝。

数据传输

web蓝牙 与附近的蓝牙设备进行通信，目前只在chrome中得到了部分实现，后续还需等待。API链接

web USB 专为网络设备设计的访问控制，仅限于HTTPS，且必须由用户启动。同样，目前只在chrome中得到了部分实现，后续还需等待。API链接

为十亿用户打造产品

最后一个session，是讲用户体验的，题目也起的非常之大，为十亿用户打造产品。演讲者是一个印度工程师，体重跟十亿这个数字很配(逃~)。

当用户的量级达到1，000，000，000人时，通常意味着用户来自世界各地，有着完全迥异的背景和文化，甚至各个国家之间的基础建设差异也很大。在现场，印度小哥列举的例子是各个国家之间的网速差异，发达国家网速比发展中国家网速快了50倍，而网速达到4Mbps以上的用户所占比例差异也很大，在越南。委内瑞拉这些国家，占比可能不到1%;上网的费用方面，越南人收入的8%需要花在流量上。可能那些国家的大部分人还在我们十几年前1M流量10元的GPRS时代吧。在这种情况下，需要根据用户设备的移动网速和连接质量的差异量身定制App。

讲者从五个方面提供了优化应用产品的建议：

1. 连接
2. 设备能力
3. 流量费用
4. 电池消耗
5. 内容

关于优化网络连接，他给出的建议是规定流量的有限顺序，即文本优先法则。图片还没加载完，有了文字，应用看起来至少是可用的。第二点是网络请求去重，网络请求不应该重复和频繁；第三点是根据网络连接性能调整行为，就是上文提到的2G网络环境下和wifi环境下所请求到的流媒体质量应该是不同的。

关于图像，他建议适宜时提供SVG，否则提供webP图像。SVG是矢量图，在任何分辨率小可以不失真，而且体量很小。动态图一般比较大，最好告知用户动态图大小。当然他也提到了PWA的离线缓存体验，不至于在网速慢或没网的时候，让用户感觉到应用不可用(虽然确实不可用)。

在构建应用的时候，也需要专门为中小屏幕构建，针对中低密度屏幕进行优化，并通过模拟器配置进行测试。

内存作为一种重要的资源，他鼓励应用应该按可用的RAM调整占用的空间，避免长时间运行的进程。而上文提到的Android Studio内存监视器可以帮助开发者做到这一点。

APK安装包的大小跟流量很相关，而其中图像消耗的流量最多。压缩APK文件，他推荐使用ProGuard降低代码大小，并在build.gradle中将多APK作为一个选项。同时，数据流量的使用也是可以在Android Studio中看到的。而且应该赋予用户选择的权力，比如网易云音乐就允许用户选择仅在wifi可用时下载歌曲。

电池消耗方面，应用避免不必要的唤醒，比如GPS定位，这个服务就挺耗电的，不要在后台一直使用。网络请求最好使用批处理的方式，有利于节能。当然也非常推荐使用他们家的Firebase JobDispatcher。

快速自适应式界面方面，他鼓励处处提供触摸反馈，按了按钮之后，即使需要等一会儿，由于有反馈告诉用户确实按下去了，他们通常愿意等一会儿。第二点是界面需要始终处于可交互的状态，也就是安卓主线程中，不应该处理其他事务，因为有可能会造成UI的卡顿。UI刷新率，始终要达到60fps，才会给人流畅的感觉。关于界面的最佳做法，当然是符合谷歌的Material Design咯。

本地化方面，他谈到大部分开发者考虑到了提供给用户多语言环境的支持，但是往往忽略的一点是字体的选择，某些字体在某些国家的文字下很不适合阅读。

结束语

知乎曾经有个问题是百度曾经做过哪些恶，他有个镜像问题是：谷歌都做了哪些恶。一个高赞的回答是：退出中国大陆市场。转眼间，搜索服务离开大陆已经快8年了，希望谷歌搜索和其他一些Service能和AI一样早点回来吧。

今年的谷歌开发者大会算是结束了，每个session都只有30分钟，仅仅是一个开始，后面的研究和使用还得靠台下的开发者，希望本文中的参考链接对大家有所帮助！