自從共享單車火了以後物聯網應用開發就比較熱門了， 甚至一些非物聯網的公司也開始切入物聯網專案中去，結果用傳統的網際網路技術和團隊開發出來的專案問題多多。核心原因是物聯網應用開發本身有一些特殊性需要關注，正好本人從事了多年的物聯網軟體設計和管理工作，說一說物聯網應用開發時應該特別注意的地方。要知道物聯網應用開發的特殊性首先要了解物聯網應用與傳統網際網路專案的使用場景有什麼不同。從技術上講物聯網應用與傳統專案最大的不同是點是資料產生來源的不同。傳統軟體或者普通網際網路軟體的資料都是由人輸入的，服務端都要對接收到的資料進行預處理，凡是資料不符合要求時都會返回讓使用者重新輸入資料。舉個例子：以使用者使用銀行APP線上轉賬為例，如果使用者輸錯了不存在的收款賬戶或者在轉賬金額中輸入了字母（一般客戶端都會對金額輸入做控制防止金額欄輸入字母這種事發生）那麼服務端就會捕捉到這個入參錯誤並且發回客戶端要求重新輸入，甚至為了提高開發效率好多開發框架已經把入參合規性檢測整合到開發框架中了。但是物聯網的資料基本上都不是靠人工輸入產生的，而且好多物聯網應用裝置長期在高溫高溼的環境下使用，只能使用比較低端的作業系統和程式語言，更容易因終端程式錯誤及網路問題產生資料錯亂問題。我把常見問題歸類以下下三類並給出解決辦法：1.網路不穩定導致資料包錯亂，原因是目前大多數物聯網裝置採用的是低階作業系統，使用的較底層的通訊協議（主要是TCP和UDP）導致。這裡又分兩個問題資料包粘包和資料錯亂。(1)資料包粘包指的是終端程式發起的多個數據包被網路層合併起來一起送到服務端，導致服務端無法正確解析資料。
解決辦法是約定資料包的包頭和包尾，例如以“OX”作為每一個數據包的頭和尾
服務端即使收到"OX12345OXOX67890OX"這樣的資料也很容易就能把資料還原成"OX12345OX" 和 "OX67890OX"並進行後續處理。(2)資料錯亂指資料在傳輸過程中被改變了，導致服務端收到的資料是錯誤的。
解決辦法是在傳送每一包的資料都增加一個校驗位X服務端每次收到資料先計算校驗位X是否正確，如果校驗位不正確說明傳輸過程中資料已不可信，告訴裝置重新發送資料即可。2.通訊超時問題：這裡主要指的時終端的資料已經送到服務端，服務端接收資料後通知終端時網路阻塞導致的，這裡的主要問題是終端與伺服器狀態不一致（終端以為資料沒有傳送成功，而伺服器已經執行了該資料）。解決辦法是服務端要有重複資料處理機制，這裡也分兩種情況。(1)不改變業務狀態的過程資料：比如共享單車要定時向服務端傳送自己所在的位置座標，當伺服器接收到的座標發現跟之前已經接收過的資料是重複資料時只要丟棄這包資料並告訴終端“接收成功，繼續傳送下一包資料“即可。(2)需要改變業務狀態的資料：比如學員在學車時先要在教練車的終端裝置上做簽到，如果9:00分終端向伺服器發起簽到請求，服務端處理了簽到請求併發還給終端裝置告知允許簽到，這時網路阻塞終端裝置沒有收到允許簽到的回覆。這一時刻裝置終端學員是非簽到狀態而在服務端學員已經是簽到狀態（終端裝置的學員狀態與伺服器端的學員狀態產生了不一致）。等到9:01分學員再次嘗試簽到，這個時候服務端又接收到了簽到請求，服務端就需要把學員的簽到時間改成9：01分並返回給裝置簽到成功（這裡的處理邏輯與傳統程式的處理邏輯不一樣了），如果第二次沒有產生網路阻塞，終端裝置接收到服務端傳送過來的允許簽到結果後把自己的狀態改為學員9：01分簽到。最終終端裝置和伺服器的狀態是一致的。3.終端產生的異常資料：主要原因是大部分物聯網終端的應用場景（要求終端體積要小，在室外高溫高熱環境長期工作）採用的是低階作業系統及開發語言做應用開發，這就需要開發人員人工管理記憶體（目前的高階開發語言比如JAVA就是系統自動管理記憶體，不需要開發人員干預），很容易因為記憶體越界等問題導致資料錯亂(例如轉賬金額變成字母)。這種問題是最麻煩的，因為發回裝置重新互動也不會產生正確的結果，只能在服務端把異常資料另外儲存起來並記錄下終端編號及發生時間，供後續人員排查問題並手工處理異常記錄。