? ? ? ? 最近剛完成有一個項目彬祖，主要是我方的Android客戶端和廠商的多臺硬件通訊茁瘦，硬件這邊有大牛和我對接。項目開始的時候為了便捷储笑，我們約定全部采用UDP的形式通訊甜熔，在大部分功能開發(fā)調試完成之后，我們發(fā)現(xiàn)完全基于UDP協(xié)議有點行不通了突倍。
UDP 遇到的問題：
1.網絡不穩(wěn)定腔稀，延遲高。
2.數(shù)據(jù)丟包
考慮到我們對于實時性羽历，可靠性的要求較高焊虏。 經決定：換用UDP+TCP的雙重保證機制。
完整的通訊流程如圖1.1：
應用啟動秕磷，以bind方式啟動MessageService服務诵闭， 在MessageService服務中啟動
TCP服務端，UDP收發(fā)端澎嚣。
如圖1.1所示：
1.此時UDP開始持續(xù)廣播報文出去涂圆。
2.硬件客戶端收到廣播，獲取發(fā)送方IP地址币叹，以事先約定好的端口創(chuàng)建TCP套接字润歉，從而和服務端建立連接。
3.發(fā)生某些異常導致不能完成通訊的情況處理：
? ? ? a.客戶端收到UDP廣播颈抚，判斷是否保持連接踩衩，如否，則重新建立TCP連接贩汉。
? ? ? b.TCP確實連接驱富，但客戶端發(fā)送數(shù)據(jù)超時，則斷開匹舞，重新連接褐鸥。
4.直到客戶端全部任務完成，自動斷開赐稽。
一切看似美好叫榕，但我們遇到了粘包的問題。(關于粘包的解釋姊舵，請自行百度晰绎。)
接下來，我們把大牛請到我們公司括丁，一起研究怎么解決這個問題荞下。
他提出了一種標準的解決辦法：
A .客戶端或者服務端每次發(fā)送的消息加一個有3個字節(jié)長度的頭部，用16進制表示。
字節(jié)位1表示消息類型尖昏，字節(jié)位2和3 合起來表示消息長度len仰税。一次讀取len長度的消息。
再次從頭讀抽诉，再讀取一個長度len2的消息肖卧，周而復始。
我們按照這種方式足足調試了半天掸鹅，總之問題太多塞帐，最終我提出了另一種解決思路，算是取巧吧：
B.我建議把消息頭去掉巍沙，加一個特殊符號的消息尾葵姥，后來我們?yōu)榱私档统鲥e概率，用了@@@句携。讀取的時候榔幸，除非讀到@@@，否則一直讀取矮嫉，讀取到的內容削咆，放在一個StringBuilder中，直到讀到@@@蠢笋，然后做一次處理拨齐，StringBuilder 清空。再以@@@ 分割成數(shù)組昨寞，這樣即使意外讀取了多條粘在一起的消息瞻惋，也可以逐條處理。
代碼改過后援岩，調試確實可行歼狼，粘包問題解決了。
關于并發(fā)以及性能的考慮：
SendMsgThread：消息發(fā)送線程（UDP,TCP）
RecvThread：UDP消息接收線程
TCPClientAcceptThread：TCP接收線程
因為這三個線程是工作線程享怀，且要長時間執(zhí)行羽峰，所以直接在MessageService 的onBind()回調方法中啟動。
當一個客戶端以TCP的方式連到手機服務端添瓷，此時必須單獨為其分配一個線程梅屉。如果是多個客戶端的話，就要分配多個客戶端仰坦÷闹玻考慮到具體的業(yè)務場景计雌，我們不知道具體是幾個硬件設備會主動連接悄晃。所以我使用了ExecutorService 的 CachedThreadPool。
CachedThreadPool 相比 FixedThreadPool更適用于我的場景，因為我不知道具體的客戶端數(shù)量妈橄，如果預先設置的線程數(shù)多了庶近，則會浪費Android內存，如果設置少了眷蚓，就會等待直到有可用線程鼻种，如此就影響了設備的連接速度。?
最關鍵的是沙热，我們的硬件設備可能會反復斷開叉钥，重連，所以CachedThreadPool是最佳選擇篙贸。
經過驗證投队，一臺3G內存的紅米手機當TCP服務端,一次創(chuàng)建20個連接，同時發(fā)送百萬次數(shù)據(jù)爵川，手機內存占用增加大約不到10MB 敷鸦，CPU占用40%-50%。粘包問題的取巧寝贡，畢竟只是為了解決一時只需扒披，恰好滿足當前場景，還是應當用RFC標準圃泡。
