坑爹的Android Ble 問題記錄日誌

標籤：

開發Ble（公司項目，防丟器）已經有一段時間，由於是第一次接觸Ble而網上資料又不多，且android平台自身的差異性，遇到了很多問題。為了將來方便查閱，在此做下記錄。
1.中興手機，藍芽手動斷開後，無法再次連結問題。（可能別的手機也存在類似問題）
解決辦法： 在串連gatt之前，對bluetoothadapter進行一次scan 順利解決此問題。

2.Gatt連結不穩定（在部分手機上出現過，此問題先排除硬體問題。此處只針對自己遇到的情況，或許有別的方案，待補充）
解決辦法： 由於用到了gattserver，在啟動gattserver和串連gatt之間由於未做順序的限制，導致了此問題。經過反覆調試後，發現只需要先建立gattserver，在serviceadded之後，在去進行gatt連結，此時的gatt串連會比較穩定。

3.小米手機遇到的，在gatt串連之後，手動調用gatt.disconnect  和 close。第二次連結後 自動斷開，再次串連會重新綁定。
解決辦法：也是無意中，看到一篇文章，寫的是小米手機在gatt操作的時候 ，最好要做一下sleep操作，可能是因為小米底層對藍芽的某些東西沒有來得及釋放(自己猜測)。 於是在gatt 串連上時，在gatt.discoverServices 之前，加上 sleep(500) ，發現斷開後在串連 成功率大大提高。

2014-11-14
4.藍芽關閉和開啟變得異常緩慢，甚至崩潰
此問題可能與當藍芽關閉時，尚有為關閉的 gatt串連/gattserver。我的解決辦法是，註冊藍芽狀態的監聽，當發現藍芽狀態變為BluetoothAdapter.STATE_TURNING_OFF 時，立刻釋放所有的gatt串連，關閉gattserver。經不完全測試發現，藍芽的關閉速度變得快多了。

5.當批量串連藍芽時，不進行onConnectionStateChange 回調。
這個問題是自己 閑的蛋疼，在測試的時候，用了很多假的mac 地址。於是造成的後果可想而知，肯定的是連不上的。但是同時也發現了問題，當ble去串連一個不存在的mac，或者不在範圍內的mac地址時，發現有時候 不會進行onConnectionStateChange的回調，覺得很蛋疼。個人覺得會不會是因為 ，同時發送的connectGatt 請求太多，導致了系統的藍芽阻塞或者別的什麼問題。沒辦法，既然發現了這個問題，就只好動手解決了。  首先，我在批量串連connectGatt的時候，新增了一個掃描，只有當 要串連的 裝置掃描到了，才進行串連。然後，我還對gatt的串連，做了一個同步(每次只能進行一個串連，上一個串連不結束的話，無法開始上一個串連，同時針對串連無回調的情況做了逾時處理，逾時的話立馬釋放當前串連)。 這麼說可能感受不是很直觀。但個人覺得，在操作手機藍芽的時候，還是做個同步的好。 避免同時發生多個gatt的操作，倒是手機藍芽奔潰等情況的發生。


2014-11-266.Gatt連結不穩定 二
最近因為在儲存gatt串連狀態的serveice中，增加了一個背景lescan，突然發現gatt串連又變的不穩定了，不知道什麼原因。走投無路的情況下，把背景lescan放到另一個service中進行，發現好像gatt又變得穩定多了，目前測試下來 已經連了40分鐘沒有斷開了。 不知道接下去會咋樣。  也不知道是不是因為在同一個線程中在gatt串連成功後，開啟lescan會導致串連不穩定，或亦是手機本身的原因，希望高人指教。

2014-11-27
還是上面的問題，今天早上來，又重試了後台掃描和gatt串連，發現又有兩次斷開，誒。。。。 鬱悶，求高人指教了。


以上發現的問題，均為個人開發經驗所得，如有不妥或者欠缺錯誤的地方，請大家指正批評。

坑爹的Android Ble 問題記錄日誌