Android團隊早在去年初啟動開發的4.3版本，就已經開始為可穿戴設備優化Android OS及其SDK了。Bluetooth 4.0 LE (Smart)的支持是一個毋容置疑的信號；而NotificationListenerService從AccessibilityService中的脫離，可以看作是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的利器了。