因為工作需要，做了一個有關(guān)藍牙設(shè)備的項目，時間不長，層次也不深，相信你只需要一個對BLE稍稍有些了解，再加上一款方便的框架，就能完成簡單的開發(fā)（想做不簡單的，那是框架能滿足的嗎？？）。這里推薦一個，讓你不至于去滿世界找
Android BLE基礎(chǔ)操作框架，基于回調(diào)，操作簡單。包含掃描、多連接、廣播包解析、服務(wù)讀寫及通知等功能。
本篇文章主要想記錄一下開發(fā)過程中遇到的唯一一個浪費了時間的問題，為什么說是浪費時間，待會就能知道了。如題所說——DeadObjectException異常
大多數(shù)的BLE相關(guān)項目，都會需要讀取信號強度、設(shè)備電量、連接及重新連接等等一些功能，我遇到DeadObjectException，出現(xiàn)在重連之后讀取信號強度上。也許你遇到這個異常的情況和我不一樣，也許依然會有所幫助。
public synchronized void readRssi(String address) {
if (address != null) {
mAddress = address;
}
if (mRssiRunable == null) {
mRssiRunable = new Runnable() {
@Override
public void run() {
Log.i("readRssi:" + mAddress);
BleDevice device = Engine.getInstance().getDeviceFromConnection(
mAddress);
if (device != null && device.isConnected()) {
BluetoothGatt gatt = device.getGatt();
if (gatt != null) {
Log.i("readRssi gatt:" + gatt + gatt.readRemoteRssi());
gatt.readRemoteRssi();
mHandler.postDelayed(this,300);
}
}
}
};
}
mHandler.postDelayed(mRssiRunable, 300);
}
上面是我readRssi的代碼，而我的問題出現(xiàn)在 gatt.readRemoteRssi()上。
DeadObjectException看到這個異常，就是字面意思嘛，某個對象掛了。
于是我打log、debug調(diào)試，發(fā)現(xiàn)Gatt相關(guān)并沒有報空。在這之前并沒有遇到過這個異常，我試圖try住這個小麻煩，結(jié)果居然發(fā)現(xiàn)這個異常沒辦法被捕捉。oh我一定是見了鬼了。
糾纏了一段時間，發(fā)現(xiàn)網(wǎng)上最多的解決方案是
在application標(biāo)簽里面添加一句android:hardwareAccelerated="false"(禁用硬件加速)
我不知道對多少人有用，我是真的沒有= =！
放下這個問題，喝杯熱茶發(fā)了會呆，仔細一想，發(fā)現(xiàn)DeadObjectException出現(xiàn)后程序并沒有crash掉，只是關(guān)于ble service的功能統(tǒng)統(tǒng)失去了響應(yīng)，那么問題應(yīng)該出現(xiàn)在service里，某個錯誤讓ble service 停止了，再結(jié)合錯誤發(fā)生在重新連接上，猜想是不是重新連接上的設(shè)備并非是之前斷開的設(shè)備（可別看不懂，我說的當(dāng)然是指對象），也就是說，我在操作兩個不同的對象。
那么我怎么確保我斷開的和重連的一定是一個對象呢。
方法當(dāng)然一大堆，不過我采用了比較省事的方式，單獨管理
新增了一個ListDataSave類，用來將斷開連接的設(shè)備保存下來，重新連接時只對這個類中存在的對象進行操作。問題終于解決了！！
解決方案很簡單明了了——新增管理類對不同狀態(tài)的設(shè)備單獨管理。
前前后后花了不少時間，可能從來沒遇到過類似問題，慌了神了- -。
問題可能不一樣，但解題思想總是大同小異的，bug是無窮無盡，路還長啊
