Android HandlerThread任务执行顺序异常及BLE通信同步问题排查

首先明确一点：你对HandlerThread的核心理解是对的——它的Looper会严格按照任务提交的顺序串行执行，不会出现乱序执行的情况。你遇到的问题，本质上不是HandlerThread的逻辑问题，而是任务提交阶段的线程安全漏洞和变量捕获方式错误导致的假象。

一、测试代码中的问题根源 #

你的定时器测试出现计数重复、缺失，和HandlerThread本身无关，问题出在这两个点：

1. 共享变量i的线程不安全操作 #

TimerTask的run()方法是在Timer的后台线程中执行的，当间隔缩小到1ms时，任务触发频率极高，i++这种非原子操作会被打断：多个run()任务可能同时读取到同一个i值，各自加1后写回，最终导致i的递增次数少于预期，出现计数缺失或重复。

2. Lambda对共享变量的引用捕获 #

你在handler.post()的lambda里直接使用了i，但lambda捕获的是i的引用而非当时的数值快照。当TimerTask的run()快速执行时，i的值已经被后续任务修改，之前post的任务打印的是修改后的i值，进一步加剧了计数混乱的现象。

修复测试代码的方法：

• 使用线程安全的计数器替代普通变量，避免并发修改问题；
• 在post之前捕获当前数值的快照，让lambda使用这个快照而非共享变量：

private fun handlerThreadTest() {
    val handlerThread = HandlerThread("MyTestThread")
    handlerThread.start()
    val handler = Handler(handlerThread.looper)
    Log.d("ThreadTest", "Thread before ${Thread.currentThread()}")
    val i = AtomicInteger(0)
    val timerObj = Timer()
    val timerTaskObj = object : TimerTask() {
        override fun run() {
            val currentI = i.incrementAndGet()
            Log.d("ThreadTest", "Counter : $currentI , ${Thread.currentThread()}")
            handler.post {
                Log.d("ThreadTest", "Counter : $currentI , inside post ${Thread.currentThread()}")
                if (currentI == 50) timerObj.cancel()
            }
        }
    }
    timerObj.schedule(timerTaskObj, 0, 1)
}

修改后即使间隔1ms，任务执行的计数也会完全与提交顺序一致。

二、BLE应用中的顺序混乱问题 #

回到你的BLE场景，既然HandlerThread的串行执行是可靠的，问题可能出在以下几个方面：

1. 验证回调与任务提交的真实顺序 #

首先要确认：onCharacteristicChanged的回调顺序是不是真的符合协议预期？有时候设备端可能因固件/硬件问题出现数据发送乱序（虽然你认为按协议不可能，但可以通过日志验证）。

你可以给每个提交的任务加唯一标识，对比提交和执行的顺序：

private int taskSeq = 0;
@Override
public void onCharacteristicChanged(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic) {
    final int currentSeq = taskSeq++;
    Log.d("BLE_Debug", "Posting task: " + currentSeq + ", data type: " + getDataType(characteristic));
    mHandler.post(() -> {
        Log.d("BLE_Debug", "Executing task: " + currentSeq + ", data type: " + getDataType(characteristic));
        mListener.onCharacteristicChanged(gatt, characteristic);
    });
}

如果日志显示Posting顺序正确（先确认指令，后数据块）但Executing顺序混乱，那大概率是mHandler被意外替换或存在多个Handler绑定到同一个Looper。

2. 确保Handler的唯一性 #

检查代码中mHandler是否只初始化了一次，有没有在其他地方重新创建或赋值？如果多个Handler绑定到同一个HandlerThread的Looper，即使任务仍是串行，其他业务的任务也可能打乱BLE数据的处理顺序。

3. 排查数据处理逻辑中的异步操作 #

如果在mListener.onCharacteristicChanged的处理逻辑中，又发起了新的异步操作（比如向其他线程post任务、调用带回调的方法），可能会导致后续业务逻辑乱序——这不是HandlerThread的问题，而是业务流程的漏洞。

4. 验证BluetoothGatt的回调线程 #

Android的BluetoothGatt回调默认在创建BluetoothGatt时的线程的Looper上执行。如果你在多个线程中操作BluetoothGatt，可能导致回调触发的顺序本身就混乱，即使post到HandlerThread也无法修正源头的乱序问题。

总结 #

HandlerThread的Looper串行执行任务的逻辑是完全可靠的，你遇到的问题都是任务提交阶段的线程安全问题，或是业务逻辑中的其他干扰。按上面的方法排查和修复，应该能解决你的同步异常问题。

内容的提问来源于stack exchange，提问作者Maksim Novikov