记录一下日志。
虽然没有彻底解决这个报错。但至少不会闪退。也就是说,用户用起来感觉没有啥问题。只是在调试的才会发现有问题。
出现这个问题的情景:进入APP第一次,蓝牙可以正常连。数据正常交换。当退出蓝牙后,快速地再次连接蓝牙。就会大概率出现报错:“read failed, socket might closed or timeout, read ret: -1”
菜鸟一枚,不知道上述报错倒底是因为什么底层原因。网上搜了一圈:有建子线程的;有修改
socket.connect();处代码的【有说将-1改成1的——然后黄色报错,说UUID跟本不识别这个1,改成UUID就好了】;也有说,创建一个“不稳定”连接的↓
"createInsecureRfcommSocketToServiceRecord",UUID.class
——都不是100%起作用,经我测试,90%以上,都会闪退+报错。并且,有时候,短时间内再次连接会一直连不上。
我是这样思考的:既然连接时,都使用try ……catch,那么,本身就说明,这个事件就不是100%会成功的。是有概率会失败的。闪退的原因,是不是没有“接住”这个错误?然后,继续执了下一步,导致错误累积,不得不通过闪退来保护计算机?
带着这个想法,我添加了连接失败后的处理方案,让计算机发现错误后,就返回,别执行下一步了。
connectionFailed();//调用连接失败处理方法。 return;//返回。
相关代码如下:
try {
socket = serverSocket.accept();
} catch (IOException e) {
Log.e("接收->运行", e.toString());
try {
serverSocket.close();//服器端socket关闭。
connectionFailed();//调用连接失败处理方法。
return;//返回。
} catch (IOException e1) {
Log.e("接收->运行", e1.toString());
}
}
虽然断了蓝牙,立马再连接会大概率报错。但是,不会闪退。再一次连可能会失败。但经测试,第三次连能100%成功连上。