使用 createRfcommSocketToServiceRecord 而不是 createRfcommSocket

createRfcommSocketToServiceRecord 获取您传递的 UUID 并使用 SDP 来决定用于连接的无线电信道.它还检查以确保服务器正在使用相同的 UUID 侦听远程端点.这样，这是获得连接最可靠的方式:它始终使用正确的通道，如果打开连接成功，您就知道另一端可以理解您的协议.

createRfcommSocketToServiceRecord takes the UUID you pass and uses SDP to decide what radio channel to use for the connection. It also checks to make sure that a server is listening on the remote endpoint, with the same UUID. In this way, it's the most reliable way to get a connection: it'll always use the correct channel, and if opening the connection succeeds, you know something at the other end can understand your protocol.

相反，createRfcommSocket 只是连接到你告诉它的通道.无法知道远程端点上是否有任何东西正在侦听:您只知道设备在那里.此外，您选择的无线电频道可能完全不合适.这就是为什么这个函数没有发布在API中，而优先使用另一个函数.

In contrast, createRfcommSocket just connects to the channel you tell it. There's no way to know whether anything is listening on the remote endpoint: you only know the device is there. Also, your choice of radio channel may be completely inappropriate. That's why this function is not published in the API, and the other function is preferred.

createRfcommSocket 起初可能看起来更可靠，但这是因为它没有检查另一个端点上是否存在侦听器:它忽略了一些错误情况.这对于试验来说可能没问题，但它对于生产系统没有用，因为用户常常会忘记在另一个端点上启动服务器，并且您的应用程序会以令人困惑的方式失败.

createRfcommSocket may appear at first to be more reliable, but it's because it's not checking for the presence of a listener at the other endpoint: it's ignoring some error cases. This might be alright for experimenting, but it's no use for a production system, because often the user will forget to start the server on the other endpoint, and your app will fail in confusing ways.

当然，由于 createRfcommSocket 未在 API 中发布，因此您不能保证它会在未来的 Android 版本中继续工作.

Of course, as createRfcommSocket isn't published in the API, you've no guarantee it will continue to work at all in future releases of Android.