1. android 低功耗藍牙(Ble) 開發總結
Android 從 4.3(API Level 18) 開始支持低功耗藍牙，但是只支持作為中心設備（Central）模式，這就意味著 Android 設備只能主動掃描和鏈接其他外圍設備（Peripheral）。從 Android 5.0(API Level 21) 開始兩種模式都支持。
低功耗藍牙開發算是較偏技術,實際開發中坑是比較多的,網上有很多文章介紹使用和經驗總結,但是有些問題答案不好找,甚至有些誤導人,比如 :獲取已經連接的藍牙,有的是通過反射,一大堆判斷,然而並不是對所有手機有用,關於Ble傳輸速率問題的解決,都是默認Android每次只能發送20個位元組,然而也並不是,,,下面進入正文。
這里用的是 Android5.0 新增的掃描API，
這里說一下，如果做藍牙設備管理頁面，可能區分是否是已連接的設備,網上又通過反射或其他挺麻煩的操作,也不見得獲取到,官方Api 就有提供
與外圍設備交互經常每次發的數據大於 mtu的，需要做分包處理，接收數據也要判斷數據的完整性最後才返回原數據做處理，所以一般交互最少包含包長度，和包校驗碼和原數據。當然也可以加包頭，指令還有其他完整性校驗。下面分享幾個公用方法:
我自己封裝的一個BleUtil ，因為涉及跟公司業務關聯性太強（主要是傳輸包的協議不同）就先不開源出來了，如果這邊文章對大家有幫助反饋不錯，我會考慮上傳個demo到github供大家使用，
在這先給大家推薦一個不錯 Demo ，裡面除了沒有分包，協議，和傳輸速率。基本的功能都有，而且調試數據到列印到界面上了。最主要是它可以用兩個個手機一個當中心設備一個當外圍設備調試。
首先傳輸速率優化有兩個方向，1 外圍設備傳輸到Android 。2 Android傳輸到外圍設備。
我在開發中首先先使用上面那位仁兄的demo調試，兩個Android 設備調試不延時，上一個成功馬上下一個，最多一秒發11個20位元組的包。
後來和我們的藍牙設備調試時發現發送特別快，但是數據不完整，他藍牙模塊接收成功了，但是透傳數據到晶元處理時發現不完整，我們的硬體小夥伴說因為 波特率 限制（差不多每10位元組透傳要耗時1ms）和藍牙模塊的buff （列印時是最多100byte，100列印的）限制，就算藍牙模塊每包都告訴你接收成功，也是沒透傳完就又接收了。後來通過調試每次發20K數據，最後是 Android 發是 20位元組/130ms 穩定。給Android 發是 20位元組/ 8ms 。 （天殺的20位元組，網上都是說20位元組最多了）
後來看了國外一家物聯網公司總結的 Ble 吞吐量的文章（上面有連接），知道Android 每個延時是可以連續接收6個包的。就改為 120位元組/ 16ms (為啥是16ms，不是每次間隔要6個包嗎，怎麼像間隔兩次，這時因為波特率影響，多了5個包100位元組，差不多 我們的單片機透傳到藍牙模塊要多耗時不到10ms )
而Android 發數據可以申請 我們設備的mtu 來得到最多每次能發多少位元組。延時還是130ms，即：241位元組/ 130ms 提高12倍，這個速度還可以。
根據藍牙BLE協議， 物理層physical layer的傳輸速率是1Mbps，相當於每秒125K位元組。事實上，其只是基準傳輸速率，協議規定BLE不能連續不斷地傳輸數據包，否則就不能稱為低功耗藍牙了。連續傳輸自然會帶來高功耗。所以，藍牙的最高傳輸速率並不由物理層的工作頻率決定的。
在實際的操作過程中，如果主機連線不斷地發送數據包，要麼丟包嚴重要麼連接出現異常而斷開。
在BLE裡面，傳輸速度受其連接參數所影響。連接參數定義如下：
1）連接間隔。藍牙基帶是跳頻工作的，主機和從機會商定多長時間進行跳頻連接，連接上才能進行數據傳輸。這個連接和廣播狀態和連接狀態的連接不是一樣的意思。主機在從機廣播時進行連接是應用層的主動軟體行為。而跳頻過程中的連接是藍牙基帶協議的規定，完全由硬體控制，對應用層透明。明顯，如果這個連接間隔時間越短，那麼傳輸的速度就增大。連接上傳完數據後，藍牙基帶即進入休眠狀態，保證低功耗。其是1.25毫秒一個單位。
2）連接延遲。其是為了低功耗考慮，允許從機在跳頻過程中不理會主機的跳頻指令，繼續睡眠一段時間。而主機不能因為從機睡眠而認為其斷開連接了。其是1.25毫秒一個單位。明顯，這個數值越小，傳輸速度也高。
藍牙BLE協議規定連接參數最小是5，即7.25毫秒；而Android手機規定連接參數最小是8，即10毫秒。iOS規定是16，即20毫秒。
連接參數完全由主機決定，但從機可以發出更新參數申請，主機可以接受也可以拒絕。android手機一部接受，而ios比較嚴格，拒絕的概率比較高。
參考:
在iOS和Android上最大化BLE吞吐量
最大化BLE吞吐量第2部分：使用更大的ATT MTU
2. android手機的BLE的傳輸速率最大是多少
BLE的最大傳輸速率是5.9k位元組每秒。
藍牙低能耗(BLE)技術是低成本、短距離、可互操作的魯棒性無線技術，工作在免許可的2.4GHz ISM射頻頻段。它從一開始就設計為超低功耗(ULP)無線技術。它利用許多智能手段最大限度地降低功耗。藍牙低能耗技術採用可變連接時間間隔，這個間隔根據具體應用可以設置為幾毫秒到幾秒不等。另外，因為BLE技術採用非常快速的連接方式，因此平時可以處於「非連接」狀態（節省能源），此時鏈路兩端相互間只是知曉對方，只有在必要時才開啟鏈路，然後在盡可能短的時間內關閉鏈路。
BLE技術的工作模式非常適合用於從微型無線感測器（每半秒交換一次數據）或使用完全非同步通信的遙控器等其它外設傳送數據。這些設備發送的數據量非常少（通常幾個位元組），而且發送次數也很少（例如每秒幾次到每分鍾一次，甚至更少）。
3. 安卓BLE知識及EasyBle的使用
BLE（Bluetooth low energy）藍牙低功耗是藍牙4.0新增的子規范，其具有低能耗、低成本、低延遲、傳輸距離長等特點，自安卓4.3（api level 18）起，安卓開始支持BLE。BLE與經典藍牙對比如下圖（）：
在講鏈接參數之前，需要先了解連接事件Connection Events
1）Conection Events（連接事件）
藍牙設備建立連接後，所有信息的交換都是通過Connetion Events進行的，主設備在Connection Events開始起發送數據包，從屬設備在Connection Events期間回復。Connection Events是周期性出現的且時間間隔很短，在一個Connection Events中，器件最大電流為十幾mA，平均電流1uA，這便是BLE功耗較低的原因。Connection Events如下圖（）
2）鏈接參數
在兩個藍牙設備建立連接進入連接狀態前，藍牙設備需要設置一系列的鏈接參數，鏈接參數是在中心設備向外圍設備發起連接請求時傳遞的：
當外圍設備認為中心設備請求的鏈接參數不合適時，外圍設備可在連接期間發送一個 Connetion Parameter UpdateRequest 請求中心設備更改鏈接參數。當中心設備收到請求時可接受或拒絕外圍設備的鏈接參數更新請求
GATT層級圖如下(圖片來自 藍牙官網 )
MTU（Maximum Transmission Unit）： 即數據的最大傳輸單元。具體是指一個Chracteristic一次性可傳輸的數據大小。
藍牙核心規范（core spec）中定義了ATT的默認MTU為23byte，除去ATT的opcode一個位元組以及ATT的handle2個位元組之後，剩下的20個位元組便是留給GATT的了。由於ATT的最大長度為512byte，故一般認為MTU的最大長度為512個byte。
註：core spec規定每一個設備都必須支持MTU為23。
用系統api開發參見 安卓BLE開發官方文檔
這里介紹使用第三方庫 EasyBle 快速開發BLE
在項目根gradle中添加
在具體mole的gradle中添加
1)判斷設備是否支持BLE並打開藍牙
安卓版本不小於6.0的，掃描必須要有定位許可權，若版本為Android10及以上，則需精確定位許可權(即 Manifest.permission.ACCESS_FINE_LOCATION )
當需要結束掃描時用以下方法結束掃描，建議在掃描到目標設備後停止掃描
當需要斷開與設備的連接時可使用以下任一方法斷開設備連接
notify和indicate都使用以下方法
當需要取消notify或indicate時調用以下方法
如果一次性寫入的數據長度大於MTU即最大傳輸單元（默認是20位元組），則可以使用下列方法進行分批寫入
當結束BLE通信時不要忘了調用destroy
4. Android-藍牙傳輸
通過藍牙傳輸數據與Socket類似。在網路中使用Socket和ServerSocket控制客戶端和服務端的數據讀寫。而藍牙通訊也由客戶端和服務端Socket來完成。藍牙客戶端Socket是BluetoothSocket，藍牙服務端Socket是BluetoothServerSocket。這兩個類都在android.bluetooth包中。
如果打算建議兩個藍牙設備之間的連接，則必須實現伺服器端與客戶端的機制。當兩個設備在同一個RFCOMM channel下分別擁有一個連接的BluetoothSocket，這兩個設備才可以說是建立了連接。
伺服器設備與客戶端設備獲取BluetoothSocket的途徑是不同的。伺服器設備是通過accepted一個incoming connection來獲取的，而客戶端設備則是通過打開一個到伺服器的RFCOMMchannel來獲取的。
通過調用BluetoothAdapter的(String, UUID) 方法來獲取
BluetoothServerSocket(UUID用於客戶端與伺服器端之間的配對)調用BluetoothServerSocket的 accept() 方法監聽連接請求，如果收到請求，則返回一個BluetoothSocket實例。
如果不想在accept其他的連接，則調用BluetoothServerSocket的 close() 方法釋放資源(調用該方法後，之前獲得的BluetoothSocket實例並沒有close。但由於RFCOMM一個時刻只允許在一條channel中有一個連接，則一般在accept一個連接後，便close掉BluetoothServerSocket)
通過搜索得到伺服器端的BluetoothService，調用BluetoothService的(String, UUID)方法獲取BluetoothSocket(該UUID應該同於伺服器端的UUID)。
調用BluetoothSocket的 connect() 方法(該方法為block方法)，如果UUID同伺服器端的UUID匹配，並且連接被伺服器端accept，則 connect() 方法返回。
5. Android-Ble藍牙開發Demo示例–掃描,連接,發送和接收數據,分包解包(附源碼)
萬物互聯的物聯網時代的已經來臨，ble藍牙開發在其中扮演著舉重若輕的角色。最近剛好閑一點，抽時間梳理下這塊的知識點。
涉及ble藍牙通訊的客戶端(開啟、掃描、連接、發送和接收數據、分包解包)和服務端(初始化廣播數據、開始廣播、配置Services、Server回調操作)整個環節以及一些常見的問題即踩過的一些坑。
比如
1、在Android不同版本或不同手機的適配問題，掃描不到藍牙設備
2、如何避免ble藍牙連接出現133錯誤？
3、單次寫的數據大小有20位元組限制，如何發送長數據
藍牙有傳統(經典)藍牙和低功耗藍牙BLE(Bluetooth Low Energy)之分，兩者的開發的API不一樣，本文主講Ble藍牙開發，傳統藍牙不展開，有需要的可以自行了解。
相對傳統藍牙，BLE低功耗藍牙，主要特點是快速搜索，快速連接，超低功耗保持連接和數據傳輸。
客戶端
服務端
Android4.3(API Level 18)開始引入BLE的核心功能並提供了相應的 API。應用程序通過這些 API 掃描藍牙設備、查詢 services、讀寫設備的 characteristics（屬性特徵）等操作。
BLE藍牙協議是GATT協議, BLE相關類不多, 全都位於android.bluetooth包和android.bluetooth.le包的幾個類:
android.bluetooth.
.BluetoothGattService 包含多個Characteristic(屬性特徵值), 含有唯一的UUID作為標識
.BluetoothGattCharacteristic 包含單個值和多個Descriptor, 含有唯一的UUID作為標識
.BluetoothGattDescriptor 對Characteristic進行描述, 含有唯一的UUID作為標識
.BluetoothGatt 客戶端相關
.BluetoothGattCallback 客戶端連接回調
.BluetoothGattServer 服務端相關
.BluetoothGattServerCallback 服務端連接回調
android.bluetooth.le.
.AdvertiseCallback 服務端的廣播回調
.AdvertiseData 服務端的廣播數據
.AdvertiseSettings 服務端的廣播設置
.BluetoothLeAdvertiser 服務端的廣播
.BluetoothLeScanner 客戶端掃描相關(Android5.0新增)
.ScanCallback 客戶端掃描回調
.ScanFilter 客戶端掃描過濾
.ScanRecord 客戶端掃描結果的廣播數據
.ScanResult 客戶端掃描結果
.ScanSettings 客戶端掃描設置
BLE設備分為兩種設備: 客戶端(也叫主機/中心設備/Central), 服務端(也叫從機/外圍設備/peripheral)
客戶端的核心類是 BluetoothGatt
服務端的核心類是 BluetoothGattServer 和 BluetoothLeAdvertiser
BLE數據的核心類是 BluetoothGattCharacteristic 和 BluetoothGattDescriptor
下面詳細講解下客戶端和服務端的開發步驟流程
安卓手機涉及藍牙許可權問題，藍牙開發需要在AndroidManifest.xml文件中添加許可權聲明：
在搜索設備之前需要詢問打開手機藍牙：
注意: BLE設備地址是動態變化(每隔一段時間都會變化),而經典藍牙設備是出廠就固定不變了！
通過掃描BLE設備，根據設備名稱區分出目標設備targetDevice，下一步實現與目標設備的連接，在連接設備之前要停止搜索藍牙；停止搜索一般需要一定的時間來完成，最好調用停止搜索函數之後加以100ms的延時，保證系統能夠完全停止搜索藍牙設備。停止搜索之後啟動連接過程；
BLE藍牙的連接方法相對簡單只需調用connectGatt方法；
參數說明
與設備建立連接之後與設備通信，整個通信過程都是在BluetoothGattCallback的非同步回調函數中完成；
BluetoothGattCallback中主要回調函數如下：
上述幾個回調函數是BLE開發中不可缺少的；
當調用targetdDevice.connectGatt(context, false, gattCallback)後系統會主動發起與BLE藍牙設備的連接，若成功連接到設備將回調onConnectionStateChange方法，其處理過程如下：
判斷newState == BluetoothGatt.STATE_CONNECTED表明此時已經成功連接到設備；
mBluetoothGatt.discoverServices();
掃描BLE設備服務是安卓系統中關於BLE藍牙開發的重要一步，一般在設備連接成功後調用，掃描到設備服務後回調onServicesDiscovered()函數，函數原型如下：
BLE藍牙開發主要有負責通信的BluetoothGattService完成的。當且稱為通信服務。通信服務通過硬體工程師提供的UUID獲取。獲取方式如下：
具體操作方式如下：
開啟監聽，即建立與設備的通信的首發數據通道，BLE開發中只有當客戶端成功開啟監聽後才能與服務端收發數據。開啟監聽的方式如下：
BLE單次寫的數據量大小是有限制的， 通常是20位元組 ，可以嘗試通過requestMTU增大，但不保證能成功。分包寫是一種解決方案，需要定義分包協議，假設每個包大小20位元組，分兩種包，數據包和非數據包。對於數據包，頭兩個位元組表示包的序號，剩下的都填充數據。對於非數據包，主要是發送一些控制信息。
監聽成功後通過向 writeCharacteristic寫入數據實現與服務端的通信。寫入方式如下：
其中：value一般為Hex格式指令，其內容由設備通信的藍牙通信協議規定；
若寫入指令成功則回調BluetoothGattCallback中的onCharacteristicWrite()方法，說明將數據已經發送給下位機；
若發送的數據符合通信協議，則服務端會向客戶端回復相應的數據。發送的數據通過回調onCharacteristicChanged()方法獲取，其處理方式如下：
通過向服務端發送指令獲取服務端的回復數據，即可完成與設備的通信過程；
當與設備完成通信之後之後一定要斷開與設備的連接。調用以下方法斷開與設備的連接：
源碼上傳在CSDN上了，有需要的可以借鑒。
=====> Android藍牙Ble通訊Demo示例源碼–掃描,連接,發送和接收數據,分包解包
BLE單次寫的數據量大小是有限制的，通常是20位元組，可以嘗試通過requestMTU增大，但不保證能成功。分包寫是一種解決方案，需要定義分包協議，假設每個包大小20位元組，分兩種包，數據包和非數據包。對於數據包，頭兩個位元組表示包的序號，剩下的都填充數據。對於非數據包，主要是發送一些控制信息。
總體流程如下：
1、定義通訊協議，如下(這里只是個舉例，可以根據項目需求擴展)
2、封裝通用發送數據介面(拆包)
該介面根據會發送數據內容按最大位元組數拆分(一般20位元組)放入隊列，拆分完後，依次從隊列里取出發送
3、封裝通用接收數據介面(組包)
該介面根據從接收的數據按協議里的定義解析數據長度判讀是否完整包，不是的話把每條消息累加起來
4、解析完整的數據包，進行業務邏輯處理
5、協議還可以引入加密解密，需要注意的選演算法參數的時候，加密後的長度最好跟原數據長度一致，這樣不會影響拆包組包
一般都是Android版本適配以及不同ROM機型（小米/紅米、華為/榮耀等）（EMUI、MIUI、ColorOS等）的許可權問題
藍牙開發中有很多問題，要靜下心分析問題，肯定可以解決的，一起加油；