后台线程使用Handler发送多条消息失效问题排查

从你的代码和描述来看，有几个关键地方可能导致后续消息无法生效，咱们逐个分析：

1. Socket连接的同步阻塞卡住了Looper线程 #

这是最有可能的核心原因！你在msg.what == 1的分支里建立Socket连接，如果这个操作是同步阻塞的（比如调用socket.connect()后又执行了inputStream.read()这类会一直等待数据的逻辑），那整个foo线程会被彻底卡住——因为handleMessage是在Looper线程中串行执行的，前面的消息处理没完成，后面的what=2等消息根本没法被取出处理。

解决办法：

• 把Socket的IO操作放到独立的子线程中执行，不要占用Looper所在的线程，确保Looper能持续处理消息队列里的后续消息。
• 或者改用非阻塞式Socket（比如NIO），避免长时间阻塞Looper的循环。

2. 确保foo对象是同一个实例 #

如果每次接收Intent时，你都重新创建了foo线程的实例（比如每次都执行new foo().start()），那后续消息发送的foo.handler要么是未初始化的空对象（新线程还没执行到handler = new Handler()这一步），要么是和处理what=1的Handler完全无关的新实例，消息自然发不到正确的消息队列里。

验证方法：

• 在发送消息的代码处和foo的run()方法里，分别打印foo对象的hashCode()，检查是否为同一个值。
• 确保整个流程中只创建并启动一次foo线程，后续一直复用同一个实例的handler。

3. 方法调用的参数不匹配（代码笔误） #

看你贴的代码，handleMessage里调用的是foo.outputMessage();，但方法定义却是private void outputMessage(byte[] message)——参数完全不匹配，正常编译都会报错。如果这是你粘贴代码时的笔误还好，但如果实际代码就是这样，运行时会抛出NoSuchMethodError。后台线程的异常如果没被捕获，可能只会在Logcat中打印而不会直接崩溃，同时会导致该分支的代码无法执行。

解决办法：

• 修正outputMessage的调用，传入正确的byte[]参数，或者调整方法定义使其匹配调用逻辑。

额外验证小技巧 #

• 发送消息后，调用handler.hasMessages(2)检查消息是否成功加入队列：如果返回false，说明消息根本没发出去，大概率是handler实例不对；如果返回true，说明消息在队列里但没被处理，那基本就是Looper线程被阻塞了。
• 在Logcat里过滤Handler相关日志，看有没有类似Failed to send message的警告信息。

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