Android 团队早在去年初启动开发的 4.3 版本，就已经开始为可穿戴设备优化 Android OS 及其 SDK 了。那么我们就来猜想一下它的未来。
本文转载自：Oasis Feng的博客 对Android Wearable SDK的猜想
背景
Android 团队早在去年初启动开发的 4.3 版本，就已经开始为可穿戴设备优化 Android OS 及其 SDK 了。Bluetooth 4.0 LE (Smart) 的支持是一个毋容置疑的信号；而 Notification Listener Service 从 Accessibility Service 中的脱离，可以看作是 Android 为在第三方设备的通知投射扫清了障碍。Android 4.4 的瘦身和内存优化更是直指 512M 内存级别的低配置设备，已经为嵌入可穿戴设备铺平了道路；而传感器事件的硬件级批量聚合及新的计步传感器支持更是将 Android 的野心袒露无疑。其它诸如 Immersive Mode 和 Translucent System UI（榨干受限的显示面积）、Enhanced notification access（更全面的通知信息及 Actions 交互的支持）、Storage Access Framework（集中存储和远程访问）等等新特性中都能找到可穿戴设备的端倪。
在上周的 SXSW 上，Sundar Pichai 宣称将会在 2 周内发布 Android Wearable SDK，想必整个工程已经进入了最后的收官阶段。那么我不妨斗胆来预测一下几天后即将面试的 Wearable SDK 到底会长什么样。
概貌
Sundar Pichar 在 SXSW 上也提到了他们认为的智能手机与可穿戴设备间的协同关系：『手机为中枢，穿戴皆 IO』。（……smartphones became tiny computers, wearables are becoming nexuses of an array of sensors.）这说明 Google 不单单是希望把搭载了 Android 系统的可穿戴设备纳入生态，而要让『率土之滨，莫非王臣』。这也迎合了整个可穿戴生态的两条发展主线：提供富交互的完备设备 和 仅采集数据（及提供简单反馈）的哑设备。即便是未搭载 Android 系统的 Pebble 也好，Gear 2 也罢，只要看作是手机的 IO，就逃不出 Android 生态。
Google 在可穿戴设备领域的处女作可谓是倾城的惊艳，但 Google Glass 很长时间以来只提供了非常受限的云端接入接口，让本就已经稀缺的开发人员抓狂不已，甚至于直接转向了 root 社区。好在 Google 最终在去年 11 月发布了 Glass DevKit 的早期预览版，开启了 Glass 本地 App 的大门。虽然 Glass 的交互迥异于目前常见的手腕类穿戴设备，但其 SDK 的设计思想则是非常明确而一致的，即基于目前 Android SDK 的更上层 Addon SDK。考虑到离下一个 Android 大版本发布（Google I/O）至少还有 3 个月的这一时间点，相信这也将会是 Wearable SDK 第一版的基础形态。
SDK 中可能会包含哪些有意思的设计呢？还是循着 Sundar Pichar 的线索顺藤摸瓜吧。『We want to develop a set of common protocols by which they can work together…… they need a mesh layer and they need a data layer by which they can all come together.』这里面传达了两个重要的信息：互操作性协议、数据交换标准。前者让彼此间的 IO 更加顺畅互通，后者可助任何数据为任何 App 所用。于是整个 SDK 的面目便可窥见一斑了。
互操作性
互操作性协议解决的典型场景便是 Pebble 这样的设备如何与 Android App 更方便的互通。Pebble SDK 提供了一个私有的解决方案——Pebble 端的 Watch App（C 语言开发）及其 SDK 提供的通信封装。这带来了一个 Google 最不希望面对的问题——生态的分裂（Fragmentation）。因此，Wearable SDK 需要以一个非常 Android 化的方式解决这个问题。除了已被广泛使用的『Notification Listener Service』外，我猜想中新的答案可能会是『Widget』和『Remote Sensor』。
『Widget』是从 Android 诞生早期就支持的唯一一个天然适合于可穿戴设备的前瞻设计，基于预定义受限面积的周期或事件驱动的渲染，然后将渲染好的位图传递给另一个负责展现 widget 的画布主体，后者可以接收简单的点击和手势交互，并将其反馈给提供 widget 的应用，触发新一轮的重绘。原先 App 与 Launcher 间的互操作性，在 Android 4.2 开始已经拓展到了锁屏界面（Lock Screen Widget），如今又可以无缝的过渡为 App 与穿戴设备间的桥梁。更重要的是，目前数不尽的带有 Widget 的 App 就可以摇身一变成为『可穿戴设备友好』的 App 了。Wearable SDK 需要做的只是搭建起这样一个延伸性的透传协议。至于 Android 4.2 开始支持的『Secondary Display』多屏联动机制，也许不会出现在早期的 Wearable SDK 中，但有望成为未来面向具有大尺寸显示界面和高速无线连接能力（如 Bluetooth 3.0 HS）的穿戴设备更灵活的媒体显示解决方案。
『Remote Sensor』，顾名思义，就是不在当前设备上的传感器。由于大量可穿戴传感单元的涌现，弥补了智能手机本身传感器的可触达边界，毕竟穿戴在身上的设备才能更准确的采集心跳、血压等生理指标，而各类借助现代传感技术的奇特探头才能满足人们日益多元化的对身周环境的感知需求。但持续传输的能耗问题是拦在 Remote Sensor 发展道路上的主要障碍，毕竟 Android 4.4 提供的 Sensor Batch 机制在降低耗电的同时是以牺牲实时响应能力为代价的。真正的救星是近几年方兴未艾的 SensorHub 技术，通过一个低功耗设计的可编程嵌入式芯片，先行采集和缓存传感器数据，并进行相对有限的实时分析，当预置条件满足时才激活主 CPU 进行处理。例如 Moto X 引以为傲的 X8 体系。再看可穿戴领域的传感器单元设计，只需将 SensorHub 前移至传感器单元内，单元与手机之间维持 Bluetooth LE 连接，SensorHub 只在必要的时候通过这个连接通知手机和传输数据，而手机则可以在有需求时向传感器单元主动请求数据回传。得益于 Android 良好的传感器框架设计，以上 Remote Sensor 机制只需在现有 Android 框架下通过 Sensor Agent over Bluetooth LE 以虚拟传感器的形式提供，在上层 App 看来和手机本身的传感器并无二致。
数据交换
互操作性的分裂问题得到解决，并不意味着广大开发者就可以轻松的开发支持可穿戴传感器单元的 App 了。眼下的局面是，Kickstarter 和 Indiegogo 上大量涌现的智能传感器众筹项目都是各自为阵，这些团队都不得不投入大量精力自己为其产品开发智能手机 App，结果还往往不尽如人意；另一方面，传统 App 开发者似乎都只能隔山观火，既下不了场，也捞不到汤。这种维度的分裂正是由于移动 OS 平台上传感器数据规范化缺失和领域技术与应用层面间的断层所造成的。幸运的是，衔接开发者，正是 Google 在 Android 中所一贯擅长的。
Wearable SDK 正应担起这付扁担，一方面定义更广泛和通用的原始传感器数据协议，另一方面提供高阶抽象的虚拟传感器框架，将这种基于数据整合和领域算法的抽象能力开放给社区和学术界，让更多拥有领域经验的专家和开发者进来衔接『专业数据』与『高阶应用』两个位面，培育出众多高质量的虚拟传感器。如此一来，才能让生态的两端更融洽的衔接，让更多的生活类和生产力 App 也能与可穿戴设备的蓬勃发展相互促进。
结语
YY 了这么多，其实都是作为一个 Android 资深开发者兼可穿戴设备控的一些美好愿望。不过相信在汲取了 Android 发展历程中的坎坷之后，Google 不会在这个新的领域让我们失望。就让整个社区一起迎接即将到来的 Wearable SDK 吧。
题外话：补充一个身为 Geek 的不切实际的畅想，Android Accessibility 框架所蕴含的抽象展现和交互代理能力其实有非常大的潜力成为衔接传统 App 与可穿戴设备异化交互的玄铁重剑。但亟需提升 Android 整体体验的 Google，想必是不会在 Wearable SDK 中祭出这件难以驾驭的武器了。好在 Android 生态的开放性并不阻碍 Geek 社区朝着这条道路挺进，也许在不久之后，我们就能看到一个可以在智能手表上操控手机端任意 Android App 的利器了。
