Nearby Connections API问题：两台特定设备通过Wi-Fi LAN传输时频繁断开连接

结合你遇到的三星设备共享WiFi下传输20-30MB文件频繁断开的情况，以及日志里的写操作超时、Keep-Alive帧失败信息，我整理了几个针对性的解决方案：

• 调整Keep-Alive与超时参数
  日志里的Write operation timeout和Failed to send KEEP_ALIVE frame是核心问题。你可以通过NearbyConnectionsOptions来调整相关参数，给设备更多的交互缓冲时间：

  NearbyConnectionsOptions options = new NearbyConnectionsOptions.Builder()
      .setKeepAliveIntervalMillis(5000) // 增大Keep-Alive发送间隔，避免频繁触发检测
      .setKeepAliveTimeoutMillis(20000) // 延长超时阈值，降低误判断开的概率
      .build();
  Nearby.getConnectionsClient(context, options);
  

  同时在PayloadCallback.onPayloadTransferUpdate中监听传输失败状态，针对失败的分块（而非整个文件）发起重试，减少重复传输的开销。

• 锁定传输介质，避免自动切换
  从日志的ENCRYPTED_WIFI_LAN来看，设备当前依赖共享WiFi路由传输，这种方式容易受网络拥堵干扰。你可以强制Nearby Connections优先使用更稳定的WiFi Direct，或者锁定仅用WiFi LAN：

  AdvertisingOptions advertisingOptions = new AdvertisingOptions.Builder()
      .setStrategy(Strategy.P2P_STAR)
      .setAllowedMediums(Medium.WIFI_DIRECT | Medium.WIFI_LAN)
      .build();
  DiscoveryOptions discoveryOptions = new DiscoveryOptions.Builder()
      .setStrategy(Strategy.P2P_STAR)
      .setAllowedMediums(Medium.WIFI_DIRECT | Medium.WIFI_LAN)
      .build();
  

  这样设备会优先建立直接的P2P连接，而非通过路由转发数据，能有效降低超时概率。

• 手动拆分大文件为小Payload
  虽然Nearby会自动拆分大文件，但手动将20-30MB的文件拆分为多个2-5MB的小Payload，能降低单次传输的超时风险。每发送一个小Payload后，等待PayloadTransferUpdate.Status.SUCCESS回调再发送下一个，避免大传输占用带宽导致Keep-Alive帧无法及时交互。

• 关闭设备的WiFi节能与后台限制
  三星设备默认的WiFi节能策略和后台限制可能会中断后台的网络连接：

  • 在代码中申请REQUEST_IGNORE_BATTERY_OPTIMIZATIONS权限，让应用不受电池优化影响；
  • 引导用户关闭设备设置中的「WiFi节能」选项；
  • 将应用添加到设备的后台运行白名单，避免系统杀死进程；
  • 尝试将两台设备的WiFi都切换到固定频段（仅2.4GHz或仅5GHz），避免频段自动切换带来的连接波动。

• 完善断开后的错误处理与重连逻辑
  在ConnectionLifecycleCallback.onDisconnected中立即清理当前传输的任务，避免后续出现EndpointManager failed to find EndpointChannel的错误。同时实现自动重连机制：记录已传输的字节数，重连后从断点处继续传输，不用重新发送整个文件。

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