http://blog.csdn.net/hellochina15/article/details/51969995
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包含三個大的功能元件：支撐Wea
ve運作的雲端元件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幾乎無法使用。
版權所有，請勿對文章内容進行部分裁剪，修改等。轉載請注明出處和作者，感謝朋友們支援。
![與專家面對面：Android開發入門問與答[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)