Android手表在中国这样落地

还要在口袋里撑着一个笨拙的大屏手机呢?手表的应用空间将更为广泛，而现在正是开发者提前布局的最佳时机。

Android系统的定制化实践

Android系统基本可以理解成以下结构：

应用层包含我们常见的应用，比如桌面、电话、设置等;

Framework层是Android的系统框架，包含了对底层硬件的抽象及对上层应用的管理;

再往下一层是Linux内核及硬件驱动。

下面，我们以Ticwear的实践为例，介绍定制Android手表操作系统要解决的问题。Ticwear是基于开源的Android 5.0源码开发的，在每一层都做了定制。在Linux内核和硬件驱动层适配了不同的手表，Framework层为了支持上层应用在手表上的特殊交互和功能做了支持，而定制化最多的是应用层。

系统裁剪由于手表屏幕小、电池小，没有通信及GPS模块，我们在定制手表系统时对Android Framework做了很多裁剪和优化，比如删掉了在目前手表上无关的Telephony模块。

蓝牙协议的定制目前，手表和手机的主要通信都依赖于蓝牙。为了让Android Wear开发者能无缝地切换到Ticwear系统，我们开发了一套和Google GMS兼容的蓝牙通信协议Mobvoi Mobile Service(MMS)。MMS基于蓝牙RFCOMM协议，提供了传送小数据的MessageAPI，传送大数据的DataAPI，以及传送设备信息的NodeAPI。开发这套协议的主要难点在于适配不同蓝牙设备，保证数据传输的可靠性、安全性，以及满足低功耗的要求。

桌面定制手表的交互不同于手机的交互，为此我们打造了一套全新的手表交互体验Cubic UI(如图1所示)。为了实现Cubic UI，我们对手表的桌面进行了深度的定制。

　　图1 Cubic UI界面图

首先是表盘系统，也就是用户点亮手表最先看到的界面。设计表盘系统时，我们考虑了以下几点需求：首先是可定制化，开发者可以简单地设计开发出一款表盘;其次是性能，表盘的绘制必须节能高效;最后是兼容性，开发者可以轻松地把为Android Wear定制的表盘移植到Ticwear上。

手表因为随手都戴在手腕上，成为了查看手机通知的一个重要途径。我们对手表的通知中心做了全新的定制，通知以卡片的形式展现，多个同类卡片可以合并成一张Bundle Card，避免通知过多。同时通知也成为了用户和手表应用交互的一个重要方式，通过通知卡片用户就可以对应用进行操控，无需再进入应用。

语音识别服务定制语音交互是手表上的一个重点，手表因为屏幕尺寸的限制，语音成为了用户在手表上输入的主要方式。Ticwear在手表上为用户提供了三种语音输入模式，分别是热词唤醒、离线语音识别和在线语音识别。热词唤醒在屏幕点亮的时候就会启动，屏幕熄灭就会关闭。热词唤醒启动后需要实时地监听语音和进行大量的计算。为了尽量减小对待机时间的影响，我们在热词唤醒方面做了大量的优化，使得它的CPU占用率维持在5%左右。在线语音识别和离线语音识别分别是在云端和手机端实现，手表只是作为录音设备把声音通过蓝牙传送到手机。Ticwear把以上三个语音服务都集成在系统中，开发者可以通过简单的API调用就可以使用以上服务。

语义分析服务定制语音识别的结果是非结构化的自然语言文本，需要经过语义分析才能被下一步的命令控制、移动搜索或其他应用所使用。比如当用户问"下周三北京到上海的航班"时，Ticwear在云端的语义分析引擎会在识别出用户是想"查找航班"，并且是"下周三"由"北京"飞往"上海"的航班;然后，Ticwear会查看用户在手表上已经安装的应用，是否有哪款应用申明支持"查找航班"这个垂直领域。如果有，Ticwear会把用户的这条查询，包装成Android Intent的形式，传递给该应用，交由该应用接下来进一步处理用户的需求。因此，我们称之为Semantic Intent。除了Intent的方式，Ticwear也提供了直接的语义分析调用接口，方便开发者在应用中充分利用语言服务。

移动搜索服务定制Ticwear的搜索提供是类似于Google Now的语音查询服务(如图2所示)。和Google Now不同的是，Ticwear在50多个垂直领域和国内生活信息服务提供商合作，为国内用户提供最接地气的生活信息，比如餐馆、机票、酒店、导航信息。用户对着手表问天气，系统会给出一张包含最近几天指定地点的天气信息的卡片;用户对着手表问航班，系统会把符合条件的航班信息卡片展示出来。系统默认的搜索结果，也是通过Semantic Intent的方式提交给Ticwear系统。开发者可以在此基础上进行二次开发、综合，在自己的应用中给用户更好