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設備的初始化配置，也是由智能手機APP進行的，下面以uWeave爲例來說明這個過程。
物聯網設備的安全性是必須要充分保證的，誰也不希望自己家的智能門鎖，能夠被別人輕易打開。這樣就必須設計一套完整的初始化和配置管理流程，來確保設備的安全性。尤其是物聯網設備剛剛拿到，還沒有啓用的時候，必須對齊進行初始化，設置賬號信息，加密信息等等重要配置數據，然後才能運行。
一般情況下，uWeave設備通過低功耗藍牙（BLE）與手機客戶端進行通信。在用戶剛剛拿到uWeave設備的時候，設備製造商會隨設備一起，提供一個設備唯一的配對密碼。這個密碼可能是打印在設備上，也可能是打印在一張紙上，然後與設備一起密封起來。不論何種形式，只有設備的所有者（Owner）才能夠看到這個配對密碼。同時，這個配對密碼會寫到設備程的軟件程序中。
用戶必須在手機上安裝一個智能手機客戶端APP(WeaveClient APP)，然後創建一個Google賬號。這個過程需要連接到Weave Cloud上。智能手機客戶端APP初始化好之後，就可以管理和配置基於uWeave的設備了。一般情況下，uWeave設備作爲藍牙通信的服務器端，手機客戶端主動連接uWeave設備，然後啓動配對過程。這個過程需要用戶在手機客戶端上輸入隨uWeave設備一起拿到的配對密碼。只有密碼正確，纔會配對成功，從而進行下一步的通信，否則配對失敗。因此，只要uWeave設備的初始配對密碼不被泄漏，設備的初始化就是安全的。
一旦配對成功，uWeave設備和智能手機客戶端就會協商一個一致的共享密碼，用於後續通信數據的加密操作。這個共享密鑰，當前是通過一種叫做SPAKE2的密鑰交換技術實現的。詳細的技術細節，可以參考參考文件【X】。這個共享密鑰會同時存儲在智能手機客戶端和uWeave設備內。後續的所有通信，就可以直接使用這個密鑰進行，而不用重新協商密鑰。如果用戶（uWeave設備Owner）希望授權其他用戶來控制這個uWeave設備，則只需要通過智能手機客戶端，把這個共享密鑰分發給其它用戶即可。
WeaveCloud
如果Weave設備和智能手機客戶端在直接通信的範圍之內，比如在同一個WiFi或藍牙網絡內，則可以通過智能手機客戶端APP直接管理和操作Weave設備。但很多情況下，智能手機客戶端與Weave設備並不在同一個局域網內，這時候就需要通過一個集中的後臺來進行相互通信，這個集中的後臺，就是Google的Weave雲平臺（Weave Cloud）。
首先，基於LibWeave的設備，在成功配置之後，會主動通過網絡連接到Weave Cloud。同時，智能手機客戶端APP也會主動連接到Weave Cloud。這兩者都在同一個賬號的約束範圍之內，這個賬號，就是客戶的Google賬號。
當進行遠端控制的時候，智能手機客戶端會首先把命令發給Weave Cloud，Weave Cloud再把命令轉發給Weave設備。對於狀態信息，則是由Weave設備先發送給Weave Cloud，然後中轉到用戶的智能手機客戶端上。當然，這個過程中的所有通信數據，都是經過加密的。
除此之外，Weave Cloud還提供很多其它的輔助功能，比如可以爲設備提供雲端存儲功能，設備的運行信息和中間產生的數據，可以同步到Weave Cloud中進行存儲。根據Google的規劃，將來還可能提供各種各樣的大數據或人工智能功能，總之，Weave Cloud是整個Weave體系的核心。
目前來說，Google尚沒有開源WeaveCloud的源代碼的計劃，所有的Weave客戶端和Weave設備端，都需要連接到Google提供的Weave Cloud服務器上，因此這就要求，如果您希望基於Weave框架來開發物聯網設備或解決方案，必須保證能夠訪問Google的服務器系統。
WeaveAPI
Weave組件之間是通過WeaveAPI進行通信和交互的，Weave定義了兩類API:Weave Cloud API和Weave Local API。智能手機客戶端和LibWeave與Weave Cloud通信，必須使用Weave Cloud API。而智能手機客戶端與LibWeave之間的通信，則基於Weave Local API。這兩類API分別基於不同的傳輸層協議，完成通信功能。下圖示意了整個協議棧：
之所以設計兩類API，是因爲這三個組件之間的不同通信需求決定的。首先看Weave Loacl API，它主要解決Weave設備端（LibWeave）與智能手機客戶端之間的交互問題。這兩個組件之間要正常通信，需要解決兩個問題（或者兩個需求）:
1. 智能手機客戶端如何定位到Weave設備。一般情況下，智能手機客戶端通過局域網（WiFi，Ethernet等）與Weave設備通信，大部分的家庭局域網上，終端設備的IP地址是不固定的，通過DHCP動態分配。一般終端設備加電之後，會通過DHCP協議來向家庭網關申請一個動態的IP地址作爲通信之用。一旦設備關閉，則會釋放這個IP地址。家庭網關前後兩次分配給終端的IP地址，一般是不同的，因此智能手機客戶端無法通過固定的IP地址，直接與Weave設備進行通信；
2. 在定位到Weave設備，並建立通信連接之後，智能手機客戶端與Weave設備之間的通信，必須是安全的。即使通信報文被截獲，攻擊者也無法查看具體內容。
Weave Local API採用mDNS協議解決第一個問題。我們知道，DNS協議用於完成計算機名字與IP地址之間的解析。在訪問互聯網的時候，用戶一般在瀏覽器內輸入待訪問的網站的域名，本質上是一臺服務器的名字。瀏覽器會查詢DNS服務器，把服務器的名字轉換成對應的IP地址，然後才通過TCP/IP協議與該服務器建立連接，並下載網頁。這個過程需要一個重要角色-DNS服務器的支持。DNS服務器一般存在於具有成百上千臺計算機的大型網絡中，同時需要網絡管理員進行復雜的管理和配置。在家庭網絡等這類小型網絡中，一般沒有DNS服務器，因此無法採用傳統的DNS協議來解析Weave設備的IP地址。而mDNS協議是專門爲家庭網絡等小型網絡設計的。在mDNS架構中，無需集中的DNS服務器，只要終端設備都在一個局域網內（嚴格來說，應該是一個廣播域內），且支持mDNS協議，就可以相互解析IP地址，並完成點對點通信。
因爲沒有集中的DNS服務器，運行mDNS協議的終端之間是通過組播（可以理解爲廣播）來相互交流的。智能手機客戶端知道Weave設備的名字（通過註冊機制完成，並記錄在智能手機客戶端中），它會發送一個mDNS請求廣播，請求中包含了目標設備的名字。這個廣播請求被所有在同一個局域網內的設備收到，但是隻有請求的名字與自己的名字匹配的設備，纔會向智能手機客戶端迴應一個應答。這個應答中包含了自己的IP地址。於是智能手機客戶端就知道了Weave設備的IP地址，後續就可以基於普通的TCP/IP協議進行通信了。
而在Weave Cloud API中，則使用普通的DNS協議解析IP地址，無需用到mDNS。
Weave Local API採用HTTPS（HTTP Secure，安全的HTTP協議）協議解決安全問題。在解析到Weave設備的IP地址之後，智能手機客戶端會與Weave設備之間建立一個HTTPS連接，所有的通信消息，都會被加密。這樣即使是在WiFi這樣可以很容易被竊聽的網絡上，網絡通信也是安全的，用戶無需擔心信息泄露。
在通信安全的問題上，Weave CloudAPI與Weave Local API的需求是一樣的，因此HTTPS協議也被Weave Cloud API所採用。但是Weave Cloud API的另外一個特徵，是Weave Local API所不具備的，就是Weave Cloud API的星形通信模式。
所謂星形通信，指的是所有的智能手機客戶端，以及所有的Weave設備，都需要連接到Weave Cloud上，然後所有的通信，都必須經Weave Cloud轉接，必須經過Weave Cloud這個“中心”。這樣做的核心目的，是確保Weave Cloud能夠掌控所有的通信內容，可以做到非常細粒度的權限管理。同時也可以確保Weave Cloud在整個Weave協同框架中的核心地位。而XMPP協議是天生支持星形通信的，該協議基於XML來描述通信的內容，然後通過加密的TCP連接，把通信內容傳遞給中心服務器（Weave Cloud）。中心服務器根據安全規則等做一番檢查之後，再把相關內容轉發給目標設備。因此，Weave Cloud API採用XMPP協議。
因爲XMPP/HTTPS/mDNS等協議是傳送層或應用層協議，其底層依賴於TCP/IP協議。而IP協議是一種開放獨立的網絡層協議，與底層具體的傳輸技術保持足夠的獨立，因此從理論上說，Weave可以運行在任何底層的網絡之上。Wi-Fi和Ethernet是最常見的家庭網絡通信技術。
需要說明的是，uWeave與智能手機客戶端之間的通信，也是Weave Local API的範疇。但是由於uWeave是針對資源受限的嵌入式應用場景所定製，很多情況下並不支持TCP/IP協議，因此無法採用mDNS和HTTPS等技術，而是直接採用了低功耗藍牙（BLE）技術。從目前的實現來看，運行uWeave的物聯網設備只會接受智能手機客戶端的管理和控制，不會與Weave Cloud建立連接，因此不會用到Weave Cloud API。
d) Weave的主要技術實現
當前的Weave框架雖然還不是非常成熟（並沒有基於Weave的商用物聯網設備上市），但是其設計理念和設計技術，卻非常先進和有代表意義。下面對Weave框架中的幾個典型技術進行介紹和分析，以便讀者更好的理解Weave框架，更好的理解物聯網操作系統中的協同框架的概念。
i. 標準的命令和狀態Schema
當前阻礙物聯網發展的最大障礙，就是缺乏標準，這樣不同廠商之間的物聯網設備或軟件，就無法互通，從而把整個物聯網市場分割成以廠商爲單位的小的“解決方案碎片”。舉例來說，物聯網設備廠商A生產的智能燈泡，只能通過廠商A與之配套的智能手機APP來進行管理和控制。因爲標準缺失，所以智能手機APP與智能燈泡之間的交互協議，只能是A廠商自己定義。同樣的道理，廠商B生產的智能門鎖，也只能由廠商B配套的智能手機APP來管理和控制。這樣的一個結果就是，一個用戶購買了多少個廠商的設備，那麼其手機上就需要安裝多少個客戶端APP。如果有一兩個廠商還好說，一旦設備類型和生產商多了，那麼用戶的手機就被這些不同廠商的APP佔滿了，變成“應用市場”了。
Google試圖通過定義一種標準的操作模式，來打破這種“廠商隔離”的狀態。其設想的目標就是，用戶只需要安裝一個智能手機客戶端，就可以控制所有廠商的物聯網設備，只要物聯網設備的軟件符合Google的標準。這套標準的操作模式，叫做Schema。
Google分析後認爲，智能手機APP與物聯網設備之間，以及物聯網設備與物聯網設備之間，傳遞的數據無非分爲兩類：命令（command）和狀態（state）。其中命令是由智能手機APP發送給物聯網設備的，要求物聯網設備做某個或某些指定的動作。而狀態，則是物聯網設備返回給智能手機APP的，也可以是智能手機APP主動向物聯網設備索取後，物聯網設備返回給手機APP的。比如智能門鎖的例子，智能手機APP可以給門鎖發一個“關閉（lock）”的命令。智能門鎖收到這個命令後，執行關閉操作。完成後，向智能手機APP返回一個當前的狀態，比如“已關閉（closed）”。這樣通過命令和狀態的交互，這個控制過程就完成了。
於是，Google把當前常見的物聯網設備，尤其是針對智慧家庭解決方案的物聯網設備，進行了分類，並定義了每種類別的設備的標準命令和狀態。比如，Weave把智慧家庭物聯網設備分爲智能門鎖，LED燈泡，攝像頭，溫度傳感器，等等類別。每類設備賦予一個標準的類別編碼，通過類別編碼類識別設備的類別。比如，針對智能門鎖，Weave的類別編碼是“AO”。這是一個兩個字符的字符串，在智能門鎖運行期間，會定期的通過低功耗藍牙（BLE）廣播自己的相關信息，其中之一就是設備類別編碼。智能手機APP會根據設備的類別編碼，選擇對應的標準操作schema，對設備進行操作。
設備類別編碼定義好之後，針對每類設備，Weave定義了標準的命令和狀態操作代碼，並用JSON格式進行表示。比如，下面是一個針對LED燈泡的標準命令和狀態schema：
const char kTraits[] = R"({
"onOff" : {
"commands" : {
"setConfig" : {
"minimalRole" : "user",
"parameters" : {
"state" : {
"type" : "string",
"enum" :["on","off"]
}
}
}
},
"state" : {
"state" : {
"isRequired" : true,
"type" : "string",
"enum" : ["on","off"]
}
}
}
})";
JSON是一種採用鍵值對（key-valuepair）來表示對象的方法。中間用冒號（:）隔開，左邊的字符串是鍵，右面的字符串是對應的值。如果一個對象包含了多個鍵值對，則通過大括號把這個對象的所有鍵值對組合起來，形成一個對象。需要注意的是，鍵值對是可以嵌套的，即鍵值對的“值”，也可以是包含多個鍵值對的對象。
在上面的例子中，“onOff”是一個對LED燈泡的抽象描述，可以理解爲LED燈泡。其右面大括號圈起來的整個部分，就是這個LED燈泡對象的操作屬性。操作屬性又分了兩類，一類是命令（對應commands），一類是狀態（對應state）。可以理解爲command和state是兩個二級鍵值對，這兩個二級鍵值對組合到一起，就描述了對LED燈泡的標準操作。
可以把命令（commands）鍵值對進一步展開，爲便於分析，單獨摘錄出來，如下：
"commands" : {
"setConfig" : {
"minimalRole" : "user",
"parameters" : {
"state" : {
"type" : "string",
"enum" : ["on","off"]
}
}
}
},
左邊的“commands”是命令鍵值對的“鍵”，冒號右面大括號內括起來的，是對應的值。可見，這個“值”本身也是由一個叫做“setConfig”的三級鍵值對組成的。也就是說，對LED燈泡的操作命令，可以是“setConfig”（修改配置），而setConfig對應的值，則是該命令的參數，以及其它信息。從上面的描述可以看出，要執行setConfig操作，用戶的最低角色（role）必須是user。這個操作對應的參數，也是一個鍵值對，鍵是“state”，對應的值可以是“on”或“off”。
需要注意的是，標準schema描述了Weave設備可以接受的所有命令的總和，以及每個命令所對應的參數描述。只要是在schema的描述範圍之內的命令或狀態操作，Weave設備就可以支持。否則Weave設備不支持。針對上述LED燈泡的schema，如果希望點燃LED燈泡，則需要向其發送下列命令：
{
“deviceId”: “52c867ca-17d5-f422-a2c8-b31c4e02743e”,
“name”: “onOff.setConfig”,
“parameters”: {
“state” : “on”
}
}
把上述JSON描述的命令及參數封裝在網絡報文中，發送給基於Weave的LED燈泡即可。上面的設備ID(DeviceId)標識了目標LED設備，因爲在同一個用戶賬號下，可能存在很多Weave設備，Weave採用全球唯一ID(GUID)來標識每個設備。
在這個LED燈泡的schema中，只有setConfig這一個操作。如果需要添加其它操作，比如setColor，則可以直接在commands鍵值對中的值域部分追加，如下：
"commands" : {
"setConfig" : {
"minimalRole" : "user",
"parameters" : {
"state" : {
"type" : "string",
"enum" : ["on","off"]
}
}
}
"setColor" : {
"minimalRole" : "user",
"parameters" : {
"color" : {
"type" : "string",
"enum" : ["red","green","blue"]
}
}
}
},
按照這個schema，對LED燈泡的命令，就可以有兩個了：一個是setConfig，用於設置燈泡的開關狀態，另外一個是setColor，用於設置燈泡的顏色。
Schema中state鍵值對的含義，與commands類似，就不做進一步解釋了。需要注意的是，在這個例子中，setConfig操作描述中也包含一個“state”，這個是setConfig的參數，不一定非要用state，也可以用其它諸如“onoff”等表示參數含義的字符串。而Schema中描述設備向客戶端返回的狀態（“state”），則是一個與commands一樣的內置關鍵字，不能任意修改。
Weave針對常見的物聯網設備，都定義了標準的schema。如果物聯網設備是基於Weave開發的，且遵循Google的這一套標準Schema，那麼從理論上說，這種物聯網設備就可以被運行在智能手機上的Weave Client和運行在後臺的Weave Cloud控制和管理。對於Weave沒有定義的設備類型和對應的schema，設備廠商可以自己定義，然後向Google申請認證。一旦認證通過，那麼就會被納入標準的schema庫內。可以看出，通過定義這套標準的shcema，並配以認證程序，Google實際上是在構築一套物聯網設備的“標準語言”，希望藉此標準語言，來統一物聯網世界。可見，Schema在Google的整個物聯網戰略中，是最核心的一環。
用戶權限管理
爲了對物聯網設備進行分權分層的管理，Weave定義了不同的角色，每類角色具備不同的設備操作權限。主要有：
1. Owner：是設備的所有者，擁有最高權限。Owner可以設定其它的用戶角色；
2. Manager，具備對其它（除Owner和Manager之外）用戶角色的管理職責，可以給用戶分配角色；
3. User：設備的使用者，具備對設備執行命令（commands）的權限；
4. Viewer：設備的查看者，可以對設備的狀態（state）進行查詢，但是不能對設備進行命令操作；
5. Unspecified/anonymous：沒有被授予任何權限的角色。
任何試圖鏈接到Weave設備上進行操作的用戶，都會被分配一個固定的角色。在操作的時候，Weave會檢查用戶的角色，看看用戶是否有特定的操作權限。如果具備權限，則運行執行指定的操作，否則則拒絕操作。
基於這樣一種分級的訪問機制，可以實現靈活的管理功能。比如，一個智能門鎖設備的Owner可以給所有的家人，都設置User權限。這樣所有的家人就都具備開鎖和關鎖的能力。Owner也可以給鄰居或親戚設置Viewer權限，這樣這些用戶就可以查看門鎖的狀態，萬一門鎖沒有鎖好，可及時通知Owner或User。
需要注意的是，用戶（user）與角色（role）是不同的概念。用戶是一個一個的實體，而角色則是某一類用戶的集合，這一類用戶具備相同的操作權限。用戶和角色的概念，被廣泛應用於權限管理系統中。
針對低功耗藍牙的深度優化
這裏主要是針對uWeave而言的。低功耗藍牙（BLE）是一種廣泛應用的局域內無線通信技術，它提供了一種低功耗的數據傳輸技術，被廣泛應用在低成本的芯片上。同時也被智能手機等設備廣泛支持。Weave架構的最主要應用場景，就是通過智能手機發現和控制物聯網設備，因此既然BLE技術是這種通信場景的主流支撐技術，uWeave專門針對這種場景做了深度優化。
在BLE場景中，運行了uWeave的物聯網設備，充當一個藍牙服務器(專業名稱叫做GATT Server)的角色，而運行Weave Client的智能手機，則充當了一個藍牙客戶端的角色。在uWeave設備還沒有被任何客戶端連接的時候，它通過BLE不斷的廣播自己的存在，以便客戶端能夠發現自己。
一旦被運行Weave Client的智能手機（Android或iOS等）發現並連接上，uWeave設備就接受客戶端的控制。需要注意的是，不論是uWeave，還是LibWeave，都受相同的Weave Client控制。雖然這兩者的底層通信協議稍有不同，但Weave Client屏蔽了這種不同，客戶端應用程序開發者(開發智能手機APP的開發人員)只需要調用一套API，就可以同時控制這兩類設備。
第一個針對BLE優化的特性，就是命令和狀態的編碼格式。在傳統的Weave中，採用JSON格式描述Weave Client和Weave設備之間的交互命令和狀態信息。雖然JSON是一種高度簡化的對象表示方式，但是其本質上仍然是文本字符串的標識形式，佔用的存儲空間和網絡帶寬，比純粹的數字形式大很多。這在WiFi或以太網情況下沒有問題，因爲這些通信技術的最大數據報文單元可以達到1K到2K字節，幾乎可以容納任何JSON格式的命令和狀態字符串。但是在BLE環境下，其最大數據傳輸單元只有幾十個字節。這樣如果仍然採用JSON格式來表示命令和狀態，則會出現一個數據單元無法傳輸的情況，必須對傳輸的數據進行分片處理。同時，過多的數據傳輸，會造成功耗的浪費。
因此，在BLE環境下，uWeave採用了CBOR（ConciseBinary Object Representation，一種用二進制表示對象的表示方法）的編碼格式，這樣就大大降低了網絡傳輸的數據量。與JSON採用文本表示對象不同，CBOR採用二進制的數字來表示對象。下面是一個實例：
uint8_t request_buffer[] = {
0xA3, // {
0x01, 0x08, // api : EXECUTE
0x02, 0x07, // request_id : 7
0x10, 0xA2, // api_params : {
0x00, kExpectedTrait,// trait : 1
0x02, 0xA1, // execute_params : {
kConfigId, 0x09, // configId : 9
}; // }}
這是一個典型的命令塊，它定義了三個頂層的鍵值對，即API對應EXECUTE，request_id對應7，api_params對應一個下一層的鍵值對。下一層的鍵值對描述了trait和執行命令的參數。在上面的表示中，左邊部分是CBOR表示方式，右邊則是傳統的JSON表示格式。顯然，CBOR表示格式只佔用了13個字節，而JSON標識格式則需要80個字節。CBOR表示的命令塊，可以通過一個BLE數據單元傳送，但是JSON表示的結果就無法壓縮到一個BLE數據單元中。之所以有這種效率的提升，是因爲在CBOR表示方法中，對JSON的某些關鍵字做了映射關係，把JSON字符串映射爲一個數字。比如，把“api”映射爲0x01，把“EXECUTE”映射爲0x08，等等。
另外一個針對BLE做的深度優化，就是短週期連接。所謂短週期連接，指的是Weave Client一旦發現一個uWeave設備，並不會主動去建立連接，而是等待用戶的驅動。uWeave設備會週期性的通過BLE廣播自己的存在，這種廣播信息，由於經過特殊設計，消耗的資源很少。運行在智能手機上的Weave Client發現uWeave設備後，只會把這個設備呈現給用戶，比如一個門鎖，一個智能燈泡，或者一個智能小車。用戶發起操作指令，比如用戶點擊“開鎖”之後，Weave Client才試圖與uWeave設備建立連接，發送操作命令，等待操作結果。待得到uWeave回覆的操作結果之後，Weave Client就會主動斷開連接，以節約電源。這種短週期連接機制，可以大大降低uWeave設備的功耗。
顯然，這與傳統的LibWeave客戶端不同。LibWeave端會一直嘗試與WeaveCloud或Weave Client建立連接，一旦建立連接，則永久保持，除非用戶主動斷開，或網絡質量問題導致中斷。
針對資源受限系統的專門優化
出針對BLE場景的專門優化外，uWeave還針對資源受限的嵌入式系統，做了專門的優化。主要表現在下列幾個方面：
首先，是內存分配模式上的優化。一般情況下的嵌入式代碼，都會依賴malloc和free等標準的C函數來申請和分配內存。但是這樣做會導致一個問題，就是讓開發者無法確定準確的內存數量，除非開發者對整個模塊的實現瞭如指掌。因爲有些內存是開發者所寫的應用程序代碼分配的，而有些內存又是諸如uWeave等既有模塊分配的。這樣開發者就無法跟蹤所有的內存使用情況，這在內存資源非常受限的嵌入式領域，是十分嚴重的問題，開發者無法判斷物理內存數量是否能滿足所有的需求。
在uWeave的實現中，uWeave代碼設計得儘量少的使用堆內存（即通過malloc和free動態分配的內存），儘量使用局部變量或靜態全局變量來存儲數據。在必須使用堆內存的情況下，uWeave也不自己分配內存，而是讓開發者分配內存，然後傳遞給uWeave。比如下面這個代碼片段：
UwDevice* device =(UwDevice*)malloc(uw_device_sizeof());
uw_device_init(device,settings,NULL);
...
這段代碼的作用是創建一個uWeave設備對象，然後初始化。可以看出，這個過程沒有涉及到任何需要用戶輸入的數據。在這種情況下，通常的做法是，uWeave直接調用malloc函數，創建一個UwDevice對象，然後初始化即可。但是uWeave卻沒有這樣做，而是提供了uw_device_sizeof和uw_device_init等函數，把整個初始化過程分解爲兩個步驟，分別由開發者進行調用，完成uWeave設備的創建和初始化。
這樣uWeave設備的創建，就由開發者控制，從而可以掌握已經分配的內存數量。這樣就不會出現內存耗盡而開發者不知的情況。
另外一個專門針對資源受限的嵌入式系統的設計，就是uWeave完全以靜態庫(static library)的形式存在。這個靜態庫會與應用程序代碼一同連接在一起，形成一個唯一的二進制模塊，加載到嵌入式設備中。uWeave這個靜態庫不依賴於任何外部的模塊。這樣就要求uWeave儘可能的實現所有自己所需要的功能代碼，同時以標準可移植的C語言（C99）進行實現。這與面向普通設備的LibWeave不同，LibWeave是採用C++語言實現的，而且廣泛使用了C++語言的一些高級特性，比如模板(template)，弱指針等等。這樣就對外部的模塊產生了廣泛的依賴。一旦加載一個LibWeave模塊，該模塊依賴的外部模塊，也必須被操作系統同時加載。顯然，這種廣泛依賴外部模塊的模式，不適合在嵌入式領域中應用。
uWeave的最後一個針對嵌入式系統的設計優化，是代碼的執行時間。我們知道，嵌入式系統往往對程序的執行時間有嚴格要求，程序不能在規定的時間內完成執行，與執行失敗的效果是一樣的，甚至更嚴重。嵌入式領域的每一個函數，都需要有相對固定的執行週期，這樣就便於開發者對整個系統的響應時間做出計算和評估。uWeave對每個函數的大致執行時間進行了統計，給出了大致的執行時間上限。這樣就方便開發者計算整體的系統響應時間。
上述這些針對資源受限的嵌入式系統的優化和專門設計，並沒有爲uWeave帶來額外的功能，但是卻使得uWeave非常適合嵌入式領域應用，符合uWeave的定位。同時，這些設計原則，也可以作爲其它嵌入式軟件開發的參考，非常具有典型意義。
e) Weave開發舉例
f) Weave優點和不足分析
Weave是一個相對完整的物聯網協同框架，包括了運行在物聯網設備上的LibWeave和uWeave，運行在智能手機上的客戶端Weave Client，以提供後臺服務的Weave Cloud。爲了對設備進行一致化的管理和操作，Weave定義了一套基於JSON的Schema，用於描述設備控制命令和狀態。Google引入了認證制度，希望把這套Schema做成一個標準，這樣只要基於Weave實現的物聯網設備，不管是不是Google開發的，就都可以納入Weave的整個體系，可以通過Weave Cloud和Weave Client進行控制和管理。對用戶來說，只要在自己的智能手機上安裝一個Weave Client APP，就可以控制所有的物聯網設備。
與此同時，Weave在實現上，也有諸多的兩點。比如專門針對資源受限的嵌入式系統，開發了uWeave，並專門針對低功耗藍牙BLE和嵌入式系統做了優化和定製。同時爲了充分提高程序開發的便捷性，又採用C++實現了LibWeave，用於計算資源豐富的硬件系統。
但是Weave也有其明顯的不足，主要有以下幾點：
1. 當前Weave框架實現的功能，還只是人對設備的控制和交互功能。即人可以通過Weave Client或Weave Cloud，來對Weave Device進行控制和管理。並沒有實現物聯網設備與設備之間的協同。舉例來說，如果家裏的煤氣報警系統被觸發，那麼煤氣報警系統可以立即通知通風系統，加強通風。同時立即通知智能門鎖，儘快打開大門，以便家人快速逃生。顯然這種物聯網系統之間的直接通信，Weave並沒有實現。因此嚴格意義上說，Weave並不能算作一個真正的物聯網協同框架；
2. Weave雖然試圖通過標準的Schema建立設備的通信標準，但是並沒有引入一套完整的層次化的設備命名體系。一個基於Weave的物聯網設備，只能在用戶的Google賬號範圍內可以唯一識別，一旦超出了Google賬號的範圍，則無法識別；
3. Weave的底層通信機制，也並沒有基於一個統一的標準。在WiFi和Ethernet等局域網環境內，Weave是基於TCP協議進行通信的。但是在低功耗藍牙領域，則直接基於藍牙API通信。針對Zigbee以及LoRa等無線通信技術，Weave還沒有對應的解決方案。這種相對割裂的通信方式，會大大限制Weave的可移植性；
4. 最後，作爲Weave核心組件的Weave Cloud，並沒有開源。這樣用戶就只能使用Gogole的Weave Cloud作爲後臺服務系統。對一些希望建設自己的後臺系統的物聯網設備商來說，這是一個嚴重的阻礙。同時，由於Google的服務器並不是每個地方都能訪問到，對於一些無法訪問Google服務的地方，則Weave幾乎無法使用。
版權所有，請勿對文章內容進行部分裁剪，修改等。轉載請註明出處和作者，感謝朋友們支持。