這段時間挺忙的，微信企業號等微信系列的教程全部停滯了，原因是我手頭上抓著幾個專案，加班就不說了，今天剛剛把新接手的專案整到大概%80的樣

子吧，準備明天整整，星期一過來直接對接測試，很多朋友跑過來問問題，我是真沒時間，請見諒！

今天就分享下這個專案的總結，原始碼就不貼上了，因為是商業專案，只是傳達下編碼思想，希望其他朋友在遇到類似專案的時候有個參考，不至於找不到

一點點思路

使用UDP進行通訊，每條指令不超過1024位元組，所有多位元組整形資料採用網路位元組順序傳輸。終端每上報一條指令，平臺都將回復一條通用確認。終端如

果未收到通用確認，建議重發三次

Ø 位置上報： 根據引數設定的定時間隔，上報當前的GPS定位資訊和狀態資訊

Ø 心跳：根據引數設定的心跳間隔，上報心跳資訊

Ø 拍照：接收平臺拍照指令，進行拍照；或者出現異常狀態自動拍照；

Ø 圖片上傳：將照片逐包上傳到平臺，並支援平臺的補包請求

Ø 接人請求：接收平臺的接人請求命令，呼叫導航介面，傳輸目的地經緯度給導航系統，實現自動導航

Ø 廣告顯示：接收中心下發的廣告顯示指令，進行廣告顯示和TTS播報（呼叫TTS介面）

Ø   

一．介面顯示

APP基本上不需要介面顯示，唯一顯示的是廣告顯示功能。

要求廣告顯示使用浮動視窗，規定視窗的位置和大小，規定字型，根據協議裡面規定的停留時間進行顯示，超過停留時間後自動消失。

 在使用者(個體微信使用者)對微信伺服器(微信公眾平臺)進行一系列的操作之後，第三方伺服器會將一系列的資訊通過通訊，找到對應的終端號裝置，而在這個唯一的 裝置 ID 下，我們需要進行包的驗證和採集，解析並且分發協議，給出相對應的操作，聽著說起來是不是很簡單？事實卻不是你想的那樣，呵呵，相信每個程式設計師都理解這句話的深意！

微信個體使用者進行遠端控制操作：

比如紅框，使用者點選車輛定位，指令先是通過公眾號到達第三方伺服器，這時候第三方需要做的就是接收並且根據key進行相對應的資料報傳送，前提需要終端很微訊號繫結，才能繼續下面的流程，第三方伺服器通過埠和唯一ID外加一個雙方規定的資料報長度，異域值等相關驗證使用者有效性的條件

這個就是終端再接收到來自第三方的UDP包，經過匹配和驗證之後很具協議分發做出需要做的操作，這是byte[] context 部分，其他的位元組沒有貼上來

，忘了說，就是在收發包的時候還要判斷IP，PORT等

移動報警跟微信接人，因為涉及一些私密資訊，所以我口頭說說大致的流程

移動報警(震動警告)：

大家都玩過微信的搖一搖吧？就是一個重力感測器，在硬體通過串列埠跟軟體接在一起，通過一個重力感應，加速度，震動之類的，根據程式碼設定的閥值作出相應的警報，實現這個功能需要我們呼叫 hardware.SensorEventListener 這個介面

通過實現這個介面的2個函式，判斷x,y,z座標變化情況

double speed = Math.sqrt(deltaX*deltaX + deltaY*deltaY + deltaZ*deltaZ)/timeInterval * 10000;  
 //達到速度閥值，發出提示  
 if(speed >= SPEED_SHRESHOLD){  
 // 震動報警
 handler.sendEmptyMessage(SENSOREVENT_STATE);
}  

onSensorChanged(SensorEvent event) 在這個函式裡做操作，我測試的時候，一旦受到重力影響或者搖晃終端裝置，就會播報相關TTS，同時也會出發一條UDP向第三方伺服器推送到使用者的手機上

微信接人：

就是微信微信個別用戶點選Menu之後，第三方伺服器就會將這個使用者的當前經緯度傳送到終端，而終端需要做的還是驗證包，解析，分發處理，解析出來之後通過轉換引數得到可以導航的經緯引數，呼叫介面，這個相對容易，最麻煩的還是協議的封裝，解析，驗證，封包等

另外還需要對ACC的狀態進行偵聽，因為專案需要用到這個狀態，而這個狀態需要訪問GPIO口，並且需要主動呼叫，考慮到這個狀態的需要性，也為了不必要的記憶體浪費和OOM，我在後臺新起子執行緒每隔5s獲取一次ACC狀態，並且標記，在上報位置的時候取標誌位就OK了，還有就是當定位失敗的時候需要填充的位元組需要自己算好，跟封包也要算好，否則程式絕對崩潰！

還有個廣告推送的，

因為應用沒有Activity沒有啟動圖示，是後臺服務型別，自監聽，自啟動，推送這個廣告肯定需要用到WindowManager否則會出現莫名其妙的錯誤，即使你CustomDialog有時候出問題，會讓你頭疼！我在我的程式碼裡給這個廣告彈窗設定了非視窗模式，也就是說，我的廣告窗口出來後，點返回鍵和它所佔區域之外的區域是無效的

視窗不會消失，點HOME視窗也不會消失，只是到了主介面而已，TTS也展示在了上面

而多久消失有很多做法，我這裡採用TimerTask

異域值計算：從指令長度到內容的異域值，就是從指令長度到內容的所有byte按位取異或，在取一個16進位制的整數作為每個收發資料包的校驗碼

補包請求就不說了，很麻煩的，如果真是遇到類似的專案，可以私信我

最難得關鍵就是協議的封裝，協議解析，封包，資料解析，協議分發，估計沒接觸的朋友是看不懂的，封裝協議估計都封不了，尤其是資料的轉換，絕對會讓你頭痛！

其實很多智慧家居方案和一些耗流量小，使用者量大的應用都用到了這個，就比如QQ就用到了HTTP跟UDP相結合的通訊方式

遠端拍照：

使用者點選遠端拍照，指令到第三方伺服器再到終端，解析獲得之後，通過調取相機，拍照，獲取本地時間，以時間戳為ID，將此ID轉換為int轉byte再集體封包傳送給第三方，之後上報照片的Byte包，因為協議每次最多1kb，所以需要把資料分包傳送

因為UDP丟包的情況比較頻繁，所以需要補包的協議指令，一同時提供了2種方式

補包指令

另給站在一線的工程師，說一句，辛苦了！當然，也包括我啦！ 哈哈！！！謝謝觀看！