Android NearBy API 非常慢（发现和连接大约需要 10 多秒）
Android NearBy API terribly slow (~10+ seconds for discovery and connection)
我正在尝试在两部 Android 手机之间设置通信通道。
不幸的是，Google 决定阻止开发人员访问蓝牙适配器 MAC 地址，有效地禁用整个 NFC 到蓝牙的切换过程（简单安全配对）。
Side note: why? privacy/security gain is minimal to none, especially
if you randomize it! you could simply randomize it when an app requests the MAC and that's it!
这个 SSP 过程过去最多需要大约 1-3 秒，产生了很好的用户体验。
目前，我受困于 NearBy，它会产生 糟糕的用户体验（谁会为了初始连接等待 10 秒?)
我们剩下的唯一选择：
- 以某种方式改进 NearBy API（发现和连接的平均时间约为 10 秒！为什么 Google，为什么？）
- WiFi 热点 - 将商定的 ID 设置为名称，发现并连接（平均约 8 秒）
- 蓝牙 - 每次都需要批准弹出窗口，速度稍快但会导致用户体验不佳。
- 互联网 - 只需使用互联网并回退到本地无线方法（当 4G 互联网连接速度比本地无线快得多时 Android NearBy，你知道 Google 实施肯定失败了）。
是否有一些秘密调味料我可以倒在 NearBy 上以改进它，至少与 Apple AirDrop 一样快（平均约 4 秒）？
我还有其他遗漏的选择吗？
谢谢！
荒谬的定义：
两部手机相距 1 米，有多个直接无线选项 (Bluetooth/BLE/WiFi) 平均需要 10 整秒 只是为了连接（在发送数据之前）。
两部手机相距 20 公里，通过蜂窝数据 (3G/4G/5G) 通信，平均 1.7 秒后完全连接！即使经过 GSM BTS、代理、缓存、防火墙、BGP 路由和其他过滤器。
Google 必须做些事情来解决这个问题（在他们禁用唯一使它更快的方法后，使用 BT SSP，将 NFC 移交给 BT - 因为他们禁用了 BT MAC 地址暴露).
我现在的解决方案是在默认情况下使用互联网，同时尝试通过 NearBy 连接，因为我需要一个后备方案来为我的一些没有良好蜂窝信号的客户工作。
我正在尝试在两部 Android 手机之间设置通信通道。
不幸的是，Google 决定阻止开发人员访问蓝牙适配器 MAC 地址，有效地禁用整个 NFC 到蓝牙的切换过程（简单安全配对）。
Side note: why? privacy/security gain is minimal to none, especially if you randomize it! you could simply randomize it when an app requests the MAC and that's it!
这个 SSP 过程过去最多需要大约 1-3 秒，产生了很好的用户体验。
目前，我受困于 NearBy，它会产生 糟糕的用户体验（谁会为了初始连接等待 10 秒?)
我们剩下的唯一选择：
- 以某种方式改进 NearBy API（发现和连接的平均时间约为 10 秒！为什么 Google，为什么？）
- WiFi 热点 - 将商定的 ID 设置为名称，发现并连接（平均约 8 秒）
- 蓝牙 - 每次都需要批准弹出窗口，速度稍快但会导致用户体验不佳。
- 互联网 - 只需使用互联网并回退到本地无线方法（当 4G 互联网连接速度比本地无线快得多时 Android NearBy，你知道 Google 实施肯定失败了）。
是否有一些秘密调味料我可以倒在 NearBy 上以改进它，至少与 Apple AirDrop 一样快（平均约 4 秒）？
我还有其他遗漏的选择吗？
谢谢！
荒谬的定义：
两部手机相距 1 米，有多个直接无线选项 (Bluetooth/BLE/WiFi) 平均需要 10 整秒 只是为了连接（在发送数据之前）。
两部手机相距 20 公里，通过蜂窝数据 (3G/4G/5G) 通信，平均 1.7 秒后完全连接！即使经过 GSM BTS、代理、缓存、防火墙、BGP 路由和其他过滤器。
Google 必须做些事情来解决这个问题（在他们禁用唯一使它更快的方法后，使用 BT SSP，将 NFC 移交给 BT - 因为他们禁用了 BT MAC 地址暴露).
我现在的解决方案是在默认情况下使用互联网，同时尝试通过 NearBy 连接，因为我需要一个后备方案来为我的一些没有良好蜂窝信号的客户工作。