我有一個(gè)用于發(fā)送消息緩沖區(qū)的消息線程。每條消息都會(huì)排隊(duì)等待發(fā)送一次，一旦onCharacteristicWrite成功，該特征就會(huì)寫(xiě)入下一條消息。特性也設(shè)置為WRITE_TYPE_NO_RESPONSE，因此特性寫(xiě)入調(diào)用之間的消息緩沖隊(duì)列非?？欤ù蠹s 0-7 毫秒）。主要問(wèn)題：“堵塞”特征在大多數(shù)情況下，這效果很好。當(dāng)存在大量消息時(shí)，似乎會(huì)出現(xiàn)此問(wèn)題（可能會(huì)在消息較少時(shí)發(fā)生，但在發(fā)送大量消息時(shí)更明顯）。發(fā)生的情況是writeCharacteristicwill 被調(diào)用，并且該特性似乎鎖定，因?yàn)閛nCharacteristicChanged不再讀取任何新數(shù)據(jù)，并且無(wú)法訪問(wèn)onCharacteristicWrite.我注意到的其他事情：每次添加 5-10ms 的睡眠延遲characteristicWrite似乎有幫助，但我不明白為什么藍(lán)牙 GATT 對(duì)象在成功返回時(shí)需要延遲onCharacteristicWrite。onConnectionStateChange有時(shí)我會(huì)收到狀態(tài) 8、設(shè)備超出范圍的回調(diào)。但這并不總是發(fā)生。有時(shí)characteristicWrite返回 false；然而，它也可以在進(jìn)入上述“堵塞特征”狀態(tài)之前返回 true消息線程代碼：    private boolean stopMessageThread = false;    private boolean characteristicWriteSuccessful = true;    private ArrayList<byte[]> messageQueue = new ArrayList<byte[]>();    private Thread messageThread =  new Thread( new Runnable() {        private long lastTime = 0;        private int count = 0;        @Override        public void run() {            while (!Thread.currentThread().isInterrupted() && !stopMessageThread) {                if(messageQueue.size() != 0 && characteristicWriteSuccessful) {                    Log.i(TAG, ""+(System.currentTimeMillis()-lastTime));                    Log.i(TAG, "Queue count: "+messageQueue.size());                    characteristicWriteSuccessful = false;                    byte[] message = messageQueue.remove(0);                    customCharacteristic.setValue(message);                    boolean status = bluetoothGatt.writeCharacteristic(customCharacteristic);                    Log.i(TAG, "write characteristic status "+status);                    lastTime = System.currentTimeMillis();                    //sleep(10); // this kinda helps but can still throw the error                }            }        }    });