Google Nearby Connections多次重连后发送Payload失效问题求助

我之前做安卓离线多人游戏时也碰到过Nearby Connections这个诡异的问题——多次断开重连后，一方能正常接收数据，但发送的Payload对方完全收不到，明明sendPayload()的成功回调触发了，数据却像石沉大海。分享几个我实测有效的排查和解决思路：

• 彻底清理断开后的连接资源
  大部分时候问题出在旧连接的资源没释放干净。每次断开连接（不管是主动调用断开，还是收到onDisconnected回调），一定要做这几件事：

  1. 调用disconnectEndpoint(endpointId)针对当前断开的端点做针对性清理；
  2. 清空本地缓存的所有端点ID和连接相关对象，绝对不要复用之前保存的端点信息；
  3. 如果是主动断开场景，可以额外调用stopAllEndpoints()确保所有残留连接都被终止。

• 重连后先验证双向通信有效性
  每次重连成功后（也就是onConnectionResult返回ConnectionResult.SUCCESS时），别着急发业务数据。建议先发送一个小型握手Payload（比如包含当前端点ID的字节数据），确认对方能收到并回复，双向通信完全正常后，再发送正式的业务数据。这样能避免不小心把数据发到旧的失效端点上。

• 别误解sendPayload成功回调的含义
  划重点！sendPayload()的onSuccess回调只是表示Nearby框架已经接收了Payload并准备发送，不代表对方已经成功收到。所以你需要在业务层加一个确认机制：比如每发送一个业务Payload就带上唯一的UUID，对方收到后回复一个包含该UUID的确认包，发送方如果在超时时间内没收到确认，就重新发送该Payload。

• 必要时重置Nearby客户端
  如果多次重连后问题依然顽固，可能是Nearby Connections内部的会话资源泄漏了。这种情况下，可以在断开连接后调用stop()关闭客户端，然后重新调用start()初始化客户端，彻底重置内部状态。不过这个操作要注意时机，最好在用户明确退出游戏或者需要完全重置连接环境时再用，避免影响正常的连接流程。

• 加详细日志定位问题
  在两端都配上详细日志：

  • 发送端记录：发送的Payload ID、目标端点ID、sendPayload的回调状态；
  • 接收端记录：收到的端点ID、Payload ID、内容；
    对比两端的日志，就能快速发现是不是发送的端点ID和接收端实际连接的端点ID不匹配——这是很多时候单向失效的核心原因。

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