如何玩轉Android物聯網開發，這些必須知道

世界公認的物聯網裝置目前公認誕生在1982年，是一臺CMU的可樂機，可以通過電腦實時監測可樂機中的可樂存量以及溫度。不過當時還沒有物聯網這一概念，直到1999年由Kevin Ashton在寶潔公司的一次內部講座中提出。他觀點認為計算機非常善於處理資訊，但是採集資訊的方式過於依賴人類，而人類的精力有限且容易犯錯，不善於處理這類事情，如果能讓計算機自行感知世界，就能將人類解放出來做自己擅長的事情。

其實物聯網裝置廣泛存在與我們身邊，比如ATM機、監控攝像頭等，不過在消費品市場方面長久以來都處於空白。個人認為主要有兩方面原因，一是行動網路的發展限制，只有4G的高頻寬、低延時、低功耗的特性才能滿足物聯網的絕大部分需求。二是智慧手機出現之前眾多的物聯網裝置沒有統一的管理方式。2010年之後智慧手機的普及配合行動網路的升級共同促進了物聯網的發展，現階段物聯網的應用領域主要涵蓋消費、企業、基礎設施以及其他方面應用。

我所在部門的業務是物聯網平臺，圍繞該平臺我們提供了裝置端的多協議接入支援，完善的裝置端和應用端SDK，應用的定製化開發以及資料展現和資料分析服務。

接入我們平臺的客戶大概可以分為三類。第一類是有自己的研發能力，能夠實現裝置接入和整套應用層面的開發。第二類只關注裝置接入，應用程式的開發交由我們定製。第三類也是隻關注裝置接入，不同是他們不想要應用的定製化開發，而是想通過系統配置自動生成App產品介面。

中移和物這款產品就是為了解決第三類人員的需求，所面臨的問題有兩個。一是裝置如何聯網，二是App控制介面如何展示。

上圖是常見的手機連線wifi的介面，但智慧裝置通常來說沒有這樣一個互動介面。

我想到的第一個解決方案就是參考路由器讓物聯網裝置擁有無線AP功能，然後手機連線上熱點開啟網頁進行配置或者提供專用app。這種方案雖然可行不過應用場景存在侷限，不太適用於多裝置配網。

第二種配網方式是串列埠AT指令，這比前面的方案更加不便，從圖中可以看到需要電腦或手機通過串列埠線連線到裝置，同樣只能一次給一臺裝置配網，假設要配網的產品是一個智慧燈泡的話可想而知會有多麻煩。

目前業界主流的配網方式是第三種Smart Config，智慧手機通過UDP廣播的方式將wifi的引數發給裝置。無線區域網是開放的網路環境，wifi晶片有兩種工作模式，標準和混雜。標準模式下它會丟棄所有目標IP地址和自身不同的資料包，混雜模式下接受所有經過它的資料包。

上圖是wifi晶片獲取的UDP資料包的資料格式，一共有7個欄位，根據協議應用層能夠編輯的欄位只有DAT。由於大部分無線路由器都是加密的，因此DAT欄位其實是密文無法直接使用。不過Length欄位會隨著DAT欄位的長度產生變化，這樣我們就可以利用長度來攜帶資訊。比如要傳送一個length值為256的數字，只需向DAT欄位中填充256位元組長度的資料，程式碼表示如下。

由於加密的緣故實際資料長度和要傳送的長度並不一致，因此在傳送正式資料前要傳送一份先導包，先分別傳送1、2、3個位元組長度的資料，再根據wifi晶片實際接收的Length長度計算出加密導致的長度差值。

除了用長度攜帶資料之外還可以利用UDP組播。UDP組播的地址實際上是一個範圍，向該範圍中任意的IP地址傳送資料都能實現組播的效果，而IP中後面的3個位元組可以用來攜帶資料。通常的做法是用第二個位元組表示UDP包的順序，後面兩個位元組攜帶實際資料，這種方式還不用考慮路由器加密的問題。如下所示。

如何在同一個app中展示不同裝置的介面也是一個難題，如果採用原生方式開發成本相對比較高也不好維護，每次接入一個新的裝置使用者都要更新一次app顯然是不合理的。我們想到了兩個技術方案，混合開發（HTML5+WebView）、React Native/Weex。

和物這款產品在內部迭代了兩個版本，第一版的時候React Native還處於早期發展階段，於是我們採用了混合開發方案。現在釋出的版本使用的則是Weex。

上圖是開發者後臺的截圖，裝置廠商可以在這裡為產品定義資料模型，定製裝置控制介面，然後通過掃描二維碼的方式進行預覽除錯。

前面提到的這些其實和本次的主題關係並不是很大，接下來我們正式談談安卓在物聯網中的應用。個人更感興趣的是Google在2016年釋出的一款物聯網作業系統android things，在此之前他們還發布過一款叫Brillo的產品，不過反響不太好。Android things相比Brillo新增了Java API Framework、Google Service、應用層等，這意味著Android things支援的更多新的特性和功能。

Android things的官方網站上有一個構建Android things app的教程，這裡我們一起來簡單看下。

第一步是新建Android Studio工程，SDK API版本要高於27，工具版本高於25.0.3。因為標準的SDK中沒有Android things的API，所以要通過指令碼的形式整合開發套件。

接著進行配置，從圖中可以看到activity中有兩個Intent-filter，第一個是安卓開發者都比較熟悉的啟動介面配置，第二個宣告瞭當前開發的應用可以作為launch存在。

第二步開始連線硬體，這裡的GPIO（通用輸入輸出），可以簡單的理解成筆記本上的擴充套件塢

第三步編寫與裝置互動的程式碼，引入核心類PeripheraManager（外設管理器）。

上面三張圖展示的是監聽按鈕事件的全部程式碼。先通過PeripheraManager的OpenGpio方法傳入按鈕的編號的到按鈕的Gpio物件，配置該物件為輸入裝置，接著設定事件型別，註冊監聽器，然後在回撥方法中列印一條日誌表明按鈕被按下，最後就是釋放資源。

這樣的例子對於有過安卓開發經驗的人來說並沒有什麼看不懂的地方，可以說Android things的出現一定程度上降低了物聯網裝置的開發門檻。

如果說一臺手機搭載Android或iOS後就能被稱為智慧手機，那麼普通裝置搭載Android things後也就可以被稱為智慧裝置。不過現階段的物聯網裝置管理還過於依賴於人類，好訊息是Android things原生支援TensorFlow。

（需要指出的是由於個人並沒有實際的應用Android things進行過開發，所以只能通過官方案例和大家一起來展望下）