我準備了一個專題Android與物聯網設備通訊,分爲十來個小節完成。泛指Android鏈接其它硬件設備創建通訊。以前的博客比較零零散散,這算是一次小小的挑戰。儘可能在工做回家後和週末來完成。html
面對陌生的事物,舉步維艱只是表象。時間會教你的。 --大雞排android
透過現象去看本質,Android終端與物聯網設備開發就是:程序員
在某種可到通訊的媒介下,使用一種可控的協議,使Android終端與硬件設備端交換數據。安全
關鍵字:通訊媒介、傳輸協議、交換數據。bash
物理層(真實媒介):藍牙、紅外、聲波、WiFi、網口、串口等服務器
傳輸層協議:TCP UDP網絡
應用層協議:ModBus、MQTT、私有協議等spa
交換數據(透傳):業務類數據交互(在協議體內)設計
有點蒙圈不?先別管那些協議是什麼通訊媒介如何傳輸的,咱們先放一邊。慢慢來。如今你只須要記住有這麼個東西。調試
如今假設咱們有一臺android設備和一塊獨立的硬件。咱們傾向於把作某件事、任務、命令當作一個包來從一端(Server)發送給另外一端(Client)。
好比手機控制某個設備關閉屏幕:
Android設備發送命令:{關閉屏幕}
客戶端收到命令:{關閉屏幕}
複製代碼
指令有些像是這樣的:
功能碼:
0x01 //關閉屏幕
0x02 //重啓設備
0x03 //打開熱感應紅外
0x04 //關閉熱感應紅外
複製代碼
上面這段0x1則表示關閉屏幕,若是服務端發送一條功能碼爲0x01的指令給設備,設備就會執行關閉屏幕動做。從接受指令到動做執行。
咱們須要弄明白的是,爲何要這樣設計,由於更多的時候是咱們須要本身定義。
上面此次通訊設備會完成如下幾個步驟:
這裏只提到了功能碼,真實的業務場景會比這個複雜一些。會帶上更多的數據體。咱們會再後面的章節展開講,這裏只作初步的認識。
通常來講咱們和硬件進行交互要儘可能保持通訊的內容簡短,包的內容越小越好。這樣的話就能夠減小和避免產生切割包、丟包重發的狀況。由於媒介的環境是不可控的,好比聲波、紅外會收到干擾,形成數據丟失或外界干擾紊亂。
這樣一來,咱們對於硬件設備這種特殊的通訊採用字節流的方式就會使包變得很小,好比ModBus的協議,簡單來講就是發送的包命令,按照事先肯定好的。切割成不一樣的段來做爲識別。咱們把這種東西叫作報文。一般會包含報文頭、內容長度、內容、報文尾(校驗)。
好了,今天先講這麼多消化一下。我也是由於近兩年的工做須要才真正接觸到Android和物聯網設備通訊的。把本身學到的一些經驗分享出來,網上少有看到較好的介紹。一路摸索的過程當中踩了很多坑。我儘可能保持採用通俗易懂又按部就班的方式來完成後續的文章。
扯一個跟主題有關的東西,大多數Java或Android程序員由於沒有接觸過過低層的通訊。有些概念只知其一;不知其二,據說過但也沒能實際用過。若是有讀者恰巧看到我這篇文章,又正好是淺嘗或者工做須要。建議買書從基礎的網絡通訊原理看起。而後再投入到工做中使用。網上的資料零零散散成體系的很少,通訊層面上的錯誤和坑若是沒有必定的經驗,通常難以排查到問題。切記