Google I/O：针对情景设计App的经验建议

本报道对Google I/O 2015上“Making apps context aware”议程的内容进行概述。在本次议程中，来自Android地理位置和情景团队的工程师Waleed Kadous与Marc Stogaitis介绍了现在的Google应用（如Google Now）中是如何收集情景数据、识别用户情景并以此提供对用户有用的服务，并列出了一些面向其他开发者的建议。

围绕情景进行设计，从底到上分别涉及传感器（硬件）、算法、以及用户交互这三个层面。传感器是情景发现的起点，算法将传感器收集的数据进行分析和理解（如用户在什么位置？用户是在走路吗？用户是在开车吗？），而交互则是最终将“抽象的”情景转化为功能的所在。

下面以几个已经实现的案例介绍基于场景的设计当前的进展情况。这些案例目前已经可以通过情景API（context APIs）来直接使用，包括activity recognition（动作识别）、places（地点）、geofencing（位置范围）、fused location provider等。

动作识别

用户是在走路还是在跑步，在坐着还是在躺着，是上楼还是下楼，是骑车还是坐车，手机是在用户的屁股口袋里还是在车里座位上还是在家里的桌面上？要实现这样的动作识别有三个步骤：

1. 从已知动作中收集数据，将数据标记为该动作。比如让志愿者带着手机手表走路，记录期间的加速度传感器、气压传感器数据，将该原始数据标记为“走路”。
2. 拿大量的原始数据交给机器学习集群做训练，直到它们能够相对准确的从一套原始数据中判断它很可能是“走路”的数据。
3. 将这套判断加入API当中，给应用开发者用起来。

目前可以识别的动作可以在DetectedActivity中看到，包括：

int    IN_VEHICLE
int    ON_BICYCLE
int    ON_FOOT
int    RUNNING
int    STILL
int    TILTING
int    UNKNOWN
int    WALKING

相当直观的返回参数，无需多说。事实上除了这些动作之外，现场还演示了另外两种已经可以被识别的动作，分别是深蹲起和仰卧起坐。这个动作识别库肯定还会继续增加壮大。

接下来，识别了动作之后，有什么应用呢？本讲座提供了一个示范：贴身携带免解锁。假设一个场景，用户用完手机后一直把手机揣口袋里走来走去，走了几分钟又拿出手机来，这两次使用手机之间是手机不离身的，因此理论上无需要求用户再次输入解锁密码。有了动作识别，就可以实现这个功能啦。当然，健身数据记录、运动相关的游戏，有了这种动作识别的能力也很有用。

动作识别+地理位置识别

动作识别配合地理位置识别，还可以实现更多其他的效果。Google Now上展示的“我的车停在哪儿了”的功能，就是由“动作识别”和“fused location provider”这两个API的组合实现的。Fused Location也就是地理位置识别，只不过是综合使用了手机的GPS、WiFi、加速度传感器、陀螺仪、以及磁力感应器的数据来判断地理位置，从而实现了降低能耗又尽可能提升位置识别准确度的效果。

“车停在哪儿了”的功能大致通过三个步骤完成：

1. 通过动作识别，判断用户在车里。
2. 根据倾斜传感器的数据，判断用户从“坐着”转变到“站立”状态的时间点，即用户“下车”的时间点。
3. 自动记录下这个时间点的Fused Location数据。

据说现在Fused Location数据已经可以精确到2-3米，这样的精确度下找到一辆车是基本没问题的。

以上就是针对情景设计App的一些经验分享。两位分享者也提供了其他的一些思路作为参考，比如在用户驾车的时候自动将短信内容用语音阅读出来，或者是基于地理位置的挖宝游戏设计等。这个就要靠大家发挥自己的想象力了。

前方危险警告

接下来，两位分享者提出了三条建议——可以算是针对情景设计的一些“敏感地带”：

1. 用户信任的问题。Google方面的建议是只收集你真正需要的数据，并且对用户解释清楚这样对用户有何好处，以此赢得用户的信任。
2. 算法不靠谱的替代方案。比如用户这一天开车开了好几十里地，算法却说他只开了几里地，你有没有设计让用户能够手动更改数据的入口？比如用户一直把手机放在口袋里，算法却认为手机曾经离身，又让用户输入解锁密码，又应当如何修正？
3. 电量消耗问题。正常应用不会长期开启，在短期开启的期间主要耗电来自屏幕。而这种情景收集类应用则是长期开启，会长时间让设备处于耗电状态。

关于这种持续收集数据的电量消耗，现在已经有了比较重大的技术突破，原理如下：

传感器本身的耗电很低，大约0.3mW。App进程的耗电量很高，大约100mW。单纯是传感器收集数据，并不会耗很多电；但问题是每次传感器收集数据，都会把数据update给进程，于是进程只能一直醒着，造成电量消耗。那么，就不要如此频繁的吵醒进程就可以了！我们在传感器和进程之间加入一个低功耗的硬件——称之为Hub。这个Hub以高频率从传感器收集数据，然后以低频率向App进程发送batch update（这个跟桌面/服务器OS的节能原理是一样的）。

这样就有一个很happy的结果：80%的能耗降低。

另一方面，能耗方面的控制也仍然需要开发者的人工介入，这主要与该应用所需的数据更新频率和准确度要求有关。这个应用是天气预报类，还是导航类，因此它对位置数据的更新频率与准确度有何要求？这只能由开发者来告知系统。

未来的可能性

最后，两位分享者对未来五年的情景设计进行了展望。持续的小改进仍然会源源不断，同时我们也有望看到一些飞越性的改良。这其中可能有三个关键因素：

1. 2-3米精确度的地理位置信息，包括在室内如果也能达到这个准确度的话，很多事情将有很大的不同。
2. 多设备，物联网。这会带来怎样的变化，现在甚至还难以预知。
3. 低功耗带来的always-on app，又会带来更多的可能性。

回顾过去，会感到很多事情是如此的不可思议。10年前的奔腾芯片，100MIPS的能力，15W的功耗，尺寸达到60mm。而上文所提到的Hub硬件，使用的STM32F411芯片，该芯片的能力为125MIPS，功耗最低在0.005W，正常在0.018W，按照目前的电池能力可以连续运转3-10周不等，而尺寸只有3mm。在机器中加入这样一个Hub，就好像人的大脑有了脑干一样，具备了自我维持生命的能力。

继续这样发展下去，会不会有一天，我们能够像幻想世界中的魔法师一样，手中凌空画几道符咒，就能释放了不起的“魔法”呢？还真是一切皆有可能啊。