Android团队去年初开始开发4.3版本，目前已经着手针对AndroidOS及其SDK对可穿戴设备进行优化。Bluetooth4.0LE(Smart)的支持是一个毋庸置疑的信号；而NotificationListenerService从AccessibilityService的脱离，可以看作是Android为第三方设备的通知投射扫清了道路。Android4.4的瘦身和内存优化直接针对512M内存级别的低配置设备，为嵌入式可穿戴设备铺平了道路；而传感器事件的硬件级批量聚合和新的计步器传感器支持将使Android的Ambition无可挑剔。其他新特性如ImmersiveMode和TranslucentSystemUI（挤出有限的显示区域）、Enhancednotificationaccess（更全面的通知??信息和Actions交互支持）、StorageAccessFramework（集中存储和远程访问）等都能找到端倪到可穿戴设备。在上周的SXSW上，SundarPichai宣布AndroidWearableSDK将在2周内发布，想必整个项目已经进入收官阶段。所以我不妨大胆预测一下，过几天面试的WearableSDK会长什么样。OverviewSundarPichar在SXSW上也提到了他们认为的智能手机和可穿戴设备之间的协同关系：“手机是中心，可穿戴设备都是IO”。（……智能手机变成了微型电脑，可穿戴设备变成了一系列传感器的枢纽。）这表明谷歌不仅希望将搭载安卓系统的可穿戴设备纳入生态，而且还希望“制造”。这也迎合了到整个可穿戴生态系统的两条主要发展线：提供丰富交互的完整设备和只收集数据（并提供简单反馈）的哑设备。即使是Pebble或Gear2没有搭载Android系统，只要作为手机的IO，自然逃不过安卓生态。谷歌在可穿戴设备领域的首次亮相可谓惊艳，但谷歌眼镜长期以来只提供了非常有限的云访问接口，这让本就稀缺的开发者疯狂，甚至直接转向root社区。幸运的是，谷歌终于在去年11月发布了GlassDevKit的早期预览版，打开了Glass原生应用的大门。虽然Glass的交互与目前常见的手腕穿戴设备有很大不同，但其SDK的设计思路非常清晰一致，即基于当前AndroidSDK的更高层级的AddonSDK。考虑到距离下一个Android大版本（GoogleI/O）的发布至少还有3个月的时间，相信这也将是第一版WearableSDK的基本形态。SDK中可能包含哪些有趣的设计？让我们跟随SundarPichar的脚步。“我们想开发一套通用协议，通过它们可以协同工作……它们需要一个网状层，它们需要一个数据层，通过它们可以将它们聚集在一起。”这里传达了两个重要信息：互操作性协议和数据交换标准。前者让彼此之间的IO更顺畅互通，后者可以帮助任何数据被任何App使用。所以可以窥见整个SDK的面貌。InteroperabilityInteroperability协议解决的典型场景是Pebble等设备如何更方便的与AndroidApp通信。PebbleSDK提供了一个私有的解决方案——Pebble端手表App（C语言开发）和SDK提供的通信包。这就引出了谷歌最不想面对的一个问题——生态碎片化（Fragmentation）。因此，WearableSDK需要以一种非常类似于Android的方式来解决这个问题。除了广泛使用的“NotificationListenerService”，我猜新的答案可能是“Widget”和“RemoteSensor”。“Widget”是唯一一种天生适合可穿戴设备的前瞻性设计，从安卓早期就开始支持。它基于预定义的有限区域的循环或事件驱动渲染，然后将渲染后的位图传递给另一个负责显示。widget的画布主体，可以接收简单的点击和手势交互，反馈给提供widget的应用程序，触发新一轮的重绘。原本App和Launcher的互操作性，从Android4.2开始扩展到锁屏界面（LockScreenWidget），现在可以无缝过渡到App和可穿戴设备之间的桥梁。更重要的是，无数带有Widgets的应用程序可以转变为“可穿戴设备友好型”应用程序。WearableSDK只需要构建这样一个可扩展的透传协议即可。至于Android4.2支持的“SecondaryDisplay”多屏联动机制，可能不会出现在早期的WearableSDK中，但有望成为面向未来的大尺寸显示界面、高速的可穿戴设备无线连接功能（如蓝牙3.0HS）。更灵活的媒体展示解决方案。“RemoteSensor”，顾名思义，就是不在当前设备上的传感器。由于大量可穿戴传感单元的出现，弥补了智能手机自身传感器的可达边界。毕竟，只有佩戴在身上的设备，才能更准确地采集心跳、血压等生理指标。探测器可以满足人们对周围环境日益多样化的感知需求。然而，连续传输的能量消耗是遥感器发展的主要障碍。毕竟Android4.4提供的SensorBatch机制是在降低功耗的同时牺牲了实时响应。真正的救星是近年来方兴未艾的SensorHub技术。通过低功耗设计的可编程嵌入式芯片，先采集并缓存传感器数据，进行相对有限的实时分析。只有满足预设条件时，主CPU才会被激活。处理。比如MotoX引以为豪的X8系统。从可穿戴领域的传感器单元设计来看，只需将SensorHub向前移动到传感器单元中，并保持单元与手机之间的低功耗蓝牙连接即可。SensorHub只会在必要的时候通知手机并通过这个连接传输数据，手机可以在需要的时候主动向传感器单元请求回数据。得益于Android良好的sensor框架设计，上述RemoteSensor机制只需要在现有的Android框架下通过SensorAgentoverBluetoothLE以虚拟传感器的形式提供，与手机端的sensor没有区别从上层app的角度看手机本身。数据交换互操作碎片化问题的解决并不意味着开发者可以轻松开发支持可穿戴传感器单元的应用程序。目前的情况是，Kickstarter和Indiegogo上大量针对智能传感器的众筹项目都是孤立的，这些团队不得不投入大量精力为其产品开发智能手机应用程序，但结果往往不尽如人意；一方面，传统App开发者似乎只能遥遥观火。这种维度划分是由于移动操作系统平台上传感器数据缺乏规范化，领域技术和应用水平存在差距造成的。幸运的是，桥接开发者正是谷歌在Android中一直擅长的。WearableSDK应该承担这个负担。一方面，它定义了更广泛和通用的原始传感器数据协议。另一方面，它提供了一个高层次的抽象虚拟传感器框架，并将这种基于数据集成和领域算法的抽象向社区开放。而学术界，让更多有实地经验的专家和开发者进来，打通“专业数据”和“高端应用”两个层面，培育出很多优质的虚拟传感器。只有这样，生态的两端才能更加和谐地连接起来，让更多的生活和生产力类APP也能促进可穿戴设备的蓬勃发展。结语YY这么多，其实是作为一个资深的Android开发者和可穿戴设备控制器的一些美好愿望。但相信在了解了Android发展的酸甜苦辣后，谷歌在这个新领域不会让我们失望。让整个社区都欢迎即将到来的WearableSDK。题外话，我作为Geek加入了一个不切实际的想象。AndroidAccessibility框架所蕴含的抽象呈现和交互代理能力，其实很有潜力成为弥合传统应用与可穿戴设备交互异化的玄铁重剑。但急需提升Android整体体验的谷歌，想必也不会牺牲WearableSDK中这把高难度武器。幸运的是，Android生态系统的开放性并没有阻碍Geek社区在这条道路上前进。或许在不久的将来，我们就会在智能手表上看到一款可以控制手机上任意AndroidApp的利器。
