Google物联网操作系统协同框架Weave深度解析

1.       Google Weave框架

在2015年的Google I/O大会上，负责Android业务的桑达.皮查伊(SundarPichai)宣布了Google最新的物联网战略。这包括一个基于Android裁剪过的叫做Brillo的操作系统，以及一个物联网通信框架Weave。对Brillo的分析，我们放在本书的后面部分，这部分对Weave进行解析。需要说明的是，截至目前，Weave有关的正式文档很少，我们只能通过阅读其源代码进行分析。

a)       Weave背景及定位

Google把Weave定位为物联网的一个通信层，但本质上，Weave应该属于物联网系统框架的范畴。因为它不依赖于任何底层的通信协议，它可以运行在任何常见的物联网通信协议之上，包括WiFi，BLE，Zigbee等等。

在这之前，Google已经通过多种方式进入物联网领域。最著名的，是收购了Nest，一个专门聚焦智能家居解决方案的技术公司，并对其做了整合。但是Nest的解决方案，只能运行在自有的智能家庭硬件之上，不能运行在非Nest的家庭设备之上，这样就限制了其进一步的应用范围。而且这种封闭的风格，与Google开放共享的风格完全背道而驰。

大概是认识到了Nest解决方案的不足，Google重新审视了物联网的特点，并结合自身优势，推出了Brillo和Weave的组合解决方案。该解决方案的大部分代码都是免费和开源的，因此可供广大物联网设备生产商直接使用。随着应用的广泛，Google会逐渐构筑起一个物联网领域的生态链。这种基于开源代码来构筑生态链的方式，完全符合Google的风格。

因此，Brillo和Weave就担负了构筑物联网生态链的重担。

b)       Weave的主要特点

Weave具备如下特点：

首先，它是与操作系统无关的一个物联网系统框架，可以移植到任意操作系统上，只要底层操作系统能够提供Weave需要的最基本函数接口。虽然Google在其I/O发布会上，同时发布Brillo与Weave，而且Brillo缺省会内置Weave，但是Weave却不给Brillo面子，并不与Brillo紧密绑定。同时，Weave也不依赖于任何通信协议，它可以运行在Wi-Fi，BLE，Zigbee等常见的通信协议之上。

其次，针对不同的目标设备，比如资源受限的嵌入式硬件设备，资源充足的硬件设备，智能手机客户端（Android或iOS），云平台等，分别有不同的代码与之对应。这些不同的代码或组件，共同组成了Weave。显然，由于缺乏一个弹性可伸缩的操作系统内核，Weave不得不把所有的“职责”，都揽到自己身上，并通过不同的实现方式来应对。假设Brillo能够做到高度的伸缩性，可以适应几十K内存的资源受限设备，也可以适应数十M内存的复杂设备的话，那么Weave就不用这么费事了，只需要提供一套统一的框架代码即可。

再次，Weave提供了一套标准的设备操作命令（叫做Schema），以及对应的认证机制。Weave对常见的物联网设备，当前主要是智能家居设备，进行了总结和抽象，并形成了一套固定的操作命令集合，内部叫做Schema，并以JSON格式进行描述。Weave这样做的目标，是希望达到不同设备厂商的设备之间，只要使用了Weave，就可以相互操作的目的。同时Weave还引入了一套认证机制，不在标准schema框架内的设备及操作，可以经过Google的认证后，添加到标准schema中。这样就确保了整个schema框架的可扩展性，长此以往，就可以形成一个完整和丰富的生态链。

最后，Weave的大部分代码都是开放的，而且采用了相对宽松的BSD协议。Google仍然认为，以自己在IT行业内的影响力，并充分利用开源模式，来构筑一个完整的生态链，从而奠定在物联网领域的霸主地位，仍然是可行的。同时，面向设备的Weave库，尤其是uWeave，设计了一组简明扼要的接口，成为Provider。Weave的核心功能只依赖于这一组Provider接口，不依赖于任何其它的功能，使得Weave具备高度的可移植性。这从侧面也反映了Weave并没有与Brillo物联网操作系统进行紧密绑定，说明Google内部对Brillo的定位和地位，可能会存在争议。

 

c)        Weave的整体架构

Weave是一个完整的物联网协同框架，它包含了一系列的组件，分别应用于不同的目标对象。下图是Weave的主要组成：

 

大致来说，Weave包含三个大的功能组件：支撑Weave运行的云端组件WeaveCloud，运行在智能手机（或Pad等其它智能终端）上的智能手机客户端，以及运行在物联网设备上的设备端组件LibWeave和uWeave。其中设备端组件LibWeave和uWeave运行在物联网设备上，比如智能门锁，智能LED灯泡，等等。设备端组件通过Weave Local API与智能手机客户端进行通信，接受智能手机客户端的管理和控制。同时，设备端组件也通过Weave Cloud API，与运行在云端的Weave Cloud进行通信。智能手机客户端也可以通过Weave Cloud API，链接到Weave Cloud上，通过Weave Cloud来控制运行LibWeave和uWeave的物联网设备。

同时，Weave提供了两类API:WeaveCloud API和Weave Local API。Weave Local API是Weave设备端组件与智能手机客户端之间的交互接口，而Weave Cloud API则是Weave Cloud API与其它两个Weave组件之间的通信接口。

下面分别对Weave的三个主要组件，以及两个API接口进行详细介绍。

LibWeave&uWeave

设备端组件又根据不同的目标设备，分成了两个：一个叫做LibWeave，适应于具备复杂计算能力的设备，这类设备支持Linux或者其它功能丰富的操作系统内核，具有数十M以上的内存空间。另外一个叫做uWeave，指的是微小（Micro）的意思。顾名思义，uWeave则是运行在资源受限的嵌入式设备上。

LibWeave是采用C++语言开发的，其代码已正式开发在Internet上。目前来说，LibWeave的主要目标操作系统是Linux，要求目标设备的CPU必须支持MMU(内存管理单元)功能，以实现支撑Linux有效运行的虚拟内存机制。

而uWeave则是面向资源受限的嵌入式领域应用，而专门实现的Weave协议栈。与LibWeave不同，uWeave专门对代码进行了定制和优化，使得整个uWeave的代码非常紧凑和高效。比如，uWeave以标准的C语言（C99）进行开发，这可使得整个代码库尺寸非常小，适应于资源受限的硬件设备。除此之外，uWeave还采用了一些其它的技术，比如采用CBOR编码格式来替代基于纯文本的JSON编码格式，来降低对网络的要求，针对低功耗蓝牙（BLE）进行了特殊的优化，采用更加简化的加密机制等等。

智能手机客户端

Weave开发了针对Android和Apple iOS两种智能手机操作系统的客户端程序库和对应的API，这样智能手机程序员可以直接调用Weave Client的API，来开发客户体验良好的Weave应用程序，来操控基于Weave的物联网设备。比如某个智慧灯泡生产商，在其智能灯泡中嵌入Weave设备端代码（LibWeave或uWeave），然后开发针对智能手机的客户端来操控这些智能灯泡。

同时，Google也开发了缺省的智能手机APP，这个APP可以做基本的Weave设备管理和控制工作。比如，可以通过这个APP，扫描局域网或蓝牙网络上是否有Weave设备。如果有Weave设备，则启动配对程序，把Weave设备纳入APP中进行管理。这时候如果Weave设备是基于Google认证的标准Schema来操作的，那么用户就可以通过Google的APP，来管理和控制Weave设备，而不用关心Weave设备是由哪个厂商生产的。

Weave设备的初