索尼可穿戴智能设备软件平台分析及应用

（一）可穿戴智能设备软件平台概述

可穿戴智能设备尽管主要以手机为平台，但其具有在一定程度的独立性及特殊性，这就要求它有自身的一整套规范来运行相关软件，因而仍需单独为其在手机上架构整套的软件平台。可穿戴智能设备的性质决定了其软件平台的设计必须考虑以下几个因素：界面设计、操作性、应用软件的可靠性、软件平台的可扩展性以及网络管理模块的实用性。

1.界面设计

在软件平台的设计当中，界面设计是一个很关键的部分。因为它是计算机和使用计算机的人之间的接口，它设计的好坏决定了用户是否能更有效地使用计算机提供的各种功能。

2.操作性

由于可穿戴设备的性质，在输入过程中，要尽量减少文本输入的数量，同时尽最大可能使用最好操作的键。

3.应用软件的可靠性

可穿戴设备的某些任务需要较高的可靠性，如文件传输、语音传输这些网络传输在可靠性方面都需要根据自己的特点提出自己的高可靠性传输机制。

4.软件平台的可扩展性

软件平台提供最基本的功能，且它必须易于扩展，以便为满足特殊需求而进行的二次软件开发。在软件平台的框架结构，以及模块的设计上要充分考虑可扩展性。

5.网络管理模块的实用性

由于考虑到可穿戴设备电量低，不应频繁充电等特点，应采用低能耗的网络，故优先考虑蓝牙技术。

索尼SmartWatch2作为可穿戴智能设备中最为活跃的智能手表的一个具有代表性的设备，其软件平台附属于整个Android平台体系，使用自身附属add-on SDK包来进行相关扩展应用的开发。综合上述对于可穿戴智能设备软件平台的要求以及SmartWatch2自身的特点，我们认为SmartWatch2非常适合作为笔者的研究对象。

（二）索尼SmartWatch2体系架构分析

1.扩展应用的运行机理

图8-28　智能扩展应用与SmartWatch2

索尼可穿戴智能设备与Android设备之间通过蓝牙通信，两者的连接使用由Smart Connect（智能连接）以及Host application（主应用）二者共同控制。SmartWatch2、智能扩展应用、主应用以及智能连接之间的关系为，智能连接为所有主应用的平台，扩展应用既需要与智能连接交互也需要与主应用交互（主要与主应用交互），主应用为扩展应用与SmartWatch2之间传输信息，如图8-28所示。

2.主应用

主应用掌控与可穿戴智能设备之间的所有交互功能，对于SmartWatch2，其主应用即名为SmartWatch2的这一Android应用。主应用使用智能连接内部的content providers找到哪些智能扩展应用可以在可穿戴智能设备上使用的信息。它与Smart Extension APIs中的Notification API（通知API）紧密相关。主应用从通知API的content provider中读取通知传送给并呈献在SmartWatch2上。总体来说主应用可以看作是SmartWatch2的软件平台，而各个扩展应用是基于此软件平台的应用。各应用都是使用必要的Smart Extension API，通过主应用以及智能连接与SmartWatch2交互。

3.智能连接

智能连接是提供给Android设备管理扩展应用以及可穿戴设备相关设置的一个框架。Smart Extension APIs中的两个API（Notification API）以及Registration and Capabilities API）的content provider可视作智能连接的一部分。它可以起到一个数据库的作用，主应用可以取得其中的数据（如需要发送的Notification的相关信息等）并发送给智能扩展，再由智能扩展应用按照既定方式显示在手表之上。

4.智能扩展应用

智能扩展应用可解释为对可穿戴智能设备功能进行扩充的应用。首先需要说明的是，手表端并不存在物理硬盘，只有内存。而供SmartWatch2使用的智能扩展应用，实际上还是作为（特殊的）Android应用运行于手机端。智能扩展应用与普通Android应用的不同之处体现在，其还需要基于额外的Smart Extension APIs开发，最终来显示、提醒甚至反过来控制手机，所有扩展应用都是通过蓝牙进行数据传输。通过使用Smart Extension APIs，可使得Android设备与SmartWatch2通信。值得注意的是，主应用的功能不包括在可穿戴设备的屏幕显示内容。例如，Facebook的更新提示，来自Twitter的消息提示，未接电话的提示等，这些功能通过智能扩展应用来实现，而主应用主要起到连接手表以及充当数据连接的作用。

简而言之，智能连接可视为所有扩展应用的数据库，所有扩展应用将信息注册到此数据库中，而不同穿戴设备的主应用从其中取得自身所需的扩展应用信息，扩展应用此后只与主应用通信。

（三）Smart Extension API的结构

考虑到Android手机的处理性能日趋强大，使得可穿戴智能设备，如SmartWatch2的性能在一开始便设计得尽可能“轻量”，而把大部分的处理放在手机端。因而，索尼可穿戴智能设备大部分处理功能作为主应用处于手机端。这也是为什么可穿戴设备的功能扩展可以看作是对Android设备的功能扩展。

对于每一个索尼可穿戴智能设备，都存在一个主应用与之对应。可穿戴设备通过蓝牙与运行在手机端的主应用通信。

智能扩展应用通过Smart Extension APIs与主应用通信。需要特别说明的是，一个智能扩展应用不与某一特定的可穿戴设备绑定，任意一个扩展应用可以给不同的可穿戴设备传送数据，但需要注意可穿戴设备的支持性。例如，智能蓝牙耳机作为简单显示设备不具备如SmartWatch2一样的高级显示功能。主应用的任务之一就是为有相应功能的可穿戴设备发送数据，而对于某个可穿戴设备是否具有此功能，则从功能列表中查询得到。主应用作为Smart Extension APIs的后端，同时提供以下服务：与硬件单元的通信；为可穿戴设备上的UI提供构建模块；调度相关的Smart Extension API信号；在手机端UI显示相关内容，供用户定制特定的动作，如使用扩展应用、震动等。

（四）Smart Extension API的作用

每一个智能扩展应用在它与主应用通信之前都需要注册。这就意味着，每一个智能扩展应用都至少需要实现Registration and Capabilities API（注册和功能API），再加上另外需要的一个或多个API才能正常运行。开发需要基于所需的Smart Extension APIs开发智能扩展应用。Smart Extension APIs共包括五个API，其中Control API（控制API）、Widget API（部件API）、Sensor API（传感器API）这三个API均是基于Intent工作，而Notification API（通知API）和Registration&Capabilities API（注册和功能API）这两个API则是基于Content Provider工作。

1.Registration&CapabilitiesAPI

扩展应用程序和主应用都必须使用此API，它是所有API中最先需要被使用及实现的。通常主应用插入和维护有关的SmartWatch2功能的信息。而扩展程序为了与SmartWatch2合理地交互必须使用这些功能信息。任何一个扩展应用程序在与SmartWatch2交互之前必须提供注册所需的所有信息。该API定义和实现了一个Android Content Provider以使扩展程序能通过Android的Content Resolver API访问。该Content Provider通过数据库部分实现。

实际上Registration&Capabilities API分为两大块内容，但其功能极为紧密，且都是实现扩展应用最先需要的API，故将两者作为一个整体分析。

（1）Capabilities API

此部分实际上可看作为一个Android组件中的content provider，用来提供SmartWatch2相关功能信息。这些信息由主应用提供，扩展应用程序的开发者则为了确认是否可以通过控制、传感器、部件API与SmartWatch2交互而使用这些信息。(www.xing528.com)

每个配件都在host_application表中有一条对应记录，不同的主应用通过其包名以区别。对于每一个主应用则在device表中有一条或多条记录。而对于不同设备所支持的显示屏、传感器、LED以及输入方式则分别记录在对应的表中。整个功能表可由content provider和相应URI（Uniform Resource Identifier统一资源标识符）取得。host_application表存储在智能连接的数据库中。

（2）用户配置

扩展应用可能要求用户在使用前进行配置，如最常见的账号登录。此时可以通过设置Extension Columns.CONFIGURATION_ACTIVITY的值为相应的Activity，而此Activity则根据软件具体需求实现，关键代码已于上文给出。当用户进入配置界面时，主应用就会显示注册的Activity界面。

2.Notification API

Notification API是另一个重要的Smart Extension API。Notification引擎收集不同来源的事件数据到同一个位置，供配件主应用访问，主应用不必去访问各个不同的数据源。事件数据就是社交网络上的活动流、新的短信和彩信提醒、未接来电提醒等。

扩展应用添加事件到智能连接的数据库中，由主应用取出Notification事件传送给配件。所有事件来源都集中储存在同一个数据库中。

（1）数据源与事件

数据源是逻辑上的抽象，引入这个概念是为了区别不同来源的数据，但同时又可以将这些来源打包成一个独立的APK。一个用例就是邮件聚合扩展应用，它允许仅使用一个Android程序包就能让用户连接不同的电子邮箱；每个邮箱账号都是一个数据源或者可以说整个扩展应用本身仅是一个数据源。Notification.Source存储了Source相关的属性信息。主应用可以使用Source来过滤事件数据，或者给用户提供配置项进行Source事件数据过滤。开发者想让主应用显示来自不同Source的事件，需要添加Notification.Source信息。一个扩展应用最多可以关联8个Source，超过，上限将导致抛出异常。一个Source必须跟一个扩展应用关联。

事件代表一个需要显示给用户的重要提醒。比如，短信提醒、未接电话提醒、社交网络上朋友们的状态更新等。Notification.Event用于保存扩展应用提供的事件。主应用通常使用Event表中的信息来进行显示。Event总是来自于Source，但Source并不是总有Event。每个Source最多允许100个Event存放在Notification.Event中。到达上限后，之前的事件会被之后的事件覆盖。

在扩展应用注册后，添加事件操作之前一个事件必须关联到一个来源，添加数据源关键代码。

（2）应用间交互

扩展应用使用Android Content Resolver API跟Notification引嘴的Content Provider通信。为响应用户输入，扩展应用需要实现至少一个Broadcast Receiver来监听主应用发出的广播。

（3）获取事件

扩展应用可以周期性地从数据源获取事件数据，或者依赖主应用发出的名为REFRESH—REQUESTJNTENT的Intent来触发获取数据的过程。

如果依赖这个Intent来触发获取事件数据的操作，需要定义Broadcast Receiver。然而扩展应用不应依赖此Intent，因为其发送间隔不固定且取决于发送者如何实现此Intent。当然，主应用启动时一定会发出一个Intent，扩展应用可以利用这一特点。

当扩展应用有事件数据需要插入到Notification引擎的Content Provider中时，可以用insert（Uri，Content Values）或bulkInsert（Uri，Content Values[]）。当有大量事件数据需要插入时，考虑到性能问题建议使用后一种方法。

3.Control API

控制API能让扩展应用完全控制SmartWatch2，包括控制屏幕、震动以及输入。值得注意的是，由于是完全控制SmartWatch2，所以同一时间只能有一个使用控制API的扩展应用运行。

（1）注册

Control Extension在使用配件之前，需要使用注册API中的Content Provider插入一条记录到Extension表中。此外还应在注册表中添加信息。每个可与扩展应用交互的主应用均应完成上述过程。同时，扩展应用需要使用Capability API来找出哪些主应用可用以及主应用支持哪些功能。

（2）Control Extension的生命周期

Control Extension并不能任意执行，它应先确认没有其他Control Extension在运行，这种情况下当前扩展应用才能使用CONTROL_START_REQUEST_INTENT来请求运行自己。当主应用准备将控制权交给扩展应用后，它将发出一个CONTROL_START_INTENT响应。

当扩展应用在配件上可见时主应用将发出CONTROL_RESUME_INTENT。可以认为此刻起扩展应用已经控制一切了，而主应用不过是在配件和扩展应用之间传递信息。

当一个高优先级的扩展应用需要运行或者负责管理屏幕状态的主应用关闭屏幕时，也可以暂停扩展应用。这种情况下主应用给扩展应用发送CONTROL_PAUSE_INTENT。这时，因为当前扩展应用可能已关闭或者其他扩展应用开始控制配件，当前扩展应用已经没必要更新屏幕了。如果当前扩展应用强行更新屏幕时，主应用会忽略这些违反规定的调用。

当扩展应用处于暂停状态时，它不能再控制屏幕、LED、振动器、按键事件。通话扩展应用就是一个具有高优先级的扩展应用。比如，当某个扩展应用正在运行，这时使用者接到一个电话。我们希望能够暂停正在运行的扩展应用，让通话扩展应用在屏幕上显示来电号码。当通话结束后，通话扩展应用结束，原来运行的扩展应用便可以恢复运行。原来的扩展应用会接收到从主应用发出的CONTROL_RESUME_INTENT，之后将重新控制一切。

用户退出扩展应用时主应用会发送一个CONTROL_PAUSE_INTENT给扩展应用，之后紧跟着发送一个CONTROL_STOP_INTENT。此后主应用重新获得控制权。

（3）Control API的内容

Control API仅包含两个接口，Control.Intents和Control.KeyCodes。Control.Intents定义和控制相关的在主应用和扩展应用之间发送的Intent。Control.KeyCodes声明按键的常量，如前进、后退、声音调大调小等。

Control Extension通过调用其实现的Control Extension抽象基类中的不同方法实现对SmartWatch2的控制，每一个方法内定义了所需的Intent，最后通过protected void send To HostApp（final Intent intent）方法向主应用发送广播以实现其功能。

常用方法有控制SmartWatch2屏幕状态的protected void set Screen State（final int state），屏幕状态包括开、关、暗、自动四种，默认为由主应用进行控制的自动状态。而protected void start Vibrator（int onDuration，int offDuration，int repeats）方法控制SmartWatch2的识动。

Control API最重要的功能是可以控制屏幕上显示的内容。如果想在SmartWatch2上显不指定的内容，首先需要创建一个继承Control Extension的子类。通常利用布局类实现背景的显示功能。

4.SensorAPI

SmartWatch2支持重力加速度传感器和光感传感器。传感器的数据通过Local Socket传送，为了建立通信，扩展程序需要建立一个在监听模式的Local Server Socke，同时需要发送SENSOR_REGISTER_LISTENER_INTENT这一Intent进行注册。对于SmartWatch2就是建立—个Accessory Sensor Event Listener成员并注册，它用来监听来自传感器的数据。在注册时，可以指定传感器数据的数据传输速度以及是否使用中断模式。中断模式下，只有传感器数据出现变化才发送数据，而非中断模式则是持续不断发送数据。当不使用传感器时，必须取消对传感器的注册。