附近共享有时会使用蓝牙传输文件，因此速度非常慢。有时传输超过 100 MB 的文件根本不方便。最初我认为蓝牙仅用于握手目的。但后来我意识到这些文件本身是通过蓝牙传输的。我很好奇为什么文件可以通过 wifi 直接传输，为什么要通过蓝牙传输。许多第三方应用程序(包括 Google Files)都使用 wifi direct 来传输文件。那么为什么像附近共享这样的内置功能应该使用蓝牙。附近共享本身的唯一目的是在没有互联网的情况下通过 wifi direct 实现快速文件传输。因此，如果文件是通过蓝牙传输的，则使用附近共享是没有意义的。
我也很想知道附近共享中存在的各种文件传输模式。有三种模式:数据、仅 Wifi 和无互联网。我真的很想知道为什么附近共享用于在没有互联网的情况下传输文件时需要互联网连接来传输文件。它是否用于 Web RTC 中的握手目的？
最佳答案
(免责声明:我从事附近共享工作)
在发送大于 1MB 的文件之前，Nearby Share 始终会尝试升级到 WiFi。在回退机制启动之前，升级有 10 秒的宽限期，并且作为最后的手段通过蓝牙发送文件。即使在回退到蓝牙后，设备仍会在后台继续尝试升级到 WiFi，但某些故障是无法恢复的，并且文件将完全通过蓝牙发送。请注意，网址和非常小的文件将立即通过蓝牙发送。
此升级可能会因多种原因而失败。最常见的是并发问题。蓝牙、p2p WiFi 和您的正常接入点连接使用相同的 radio ，并且必须相应地进行分时。如果这三个人都想在不同的 channel 上，你就会错过消息——这是保证。如果这些消息很重要，例如通过 WiFi Direct 连接时的身份验证帧，则连接将会失败。如果这些消息不太重要，则可能会重新发送它们，直到成功接收为止，但这会降低传输吞吐量，甚至 5GHz WiFi 也会看起来像蓝牙一样慢。
Nearby Share 尝试通过多种方式避免这种情况。当法规允许时，我们将尝试在与接入点相同的 channel 上启动 WiFi Direct 组。这样，手机就不必分时(虽然确实有与接入点发来的消息冲突的副作用。但一般情况下，双方都会后退一个随机量并重传，损失小于损失)多 channel 并发)。不幸的是，许多国家/地区确实有规定仅允许在室内使用某些(或全部)5GHz 信道 - 在这些情况下，可以设置接入点来使用它，但 WiFi Direct 不能。
我们还更喜欢像 WiFi Direct 这样的媒介而不是 Hotspot，因为 WiFi Direct 通常使用 CTS2SELF 帧来通告“在此持续时间内不要传输”。不幸的是，它并不是像“我要离开 channel ，不要尝试与我通信”那样简单的消息 - CTS2SELF 具有使接入点上的所有通信安静下来的副作用，即使它没有定向到电话 -但它确实明白了要点。
我们暂停我们可以控制的任何蓝牙 Activity ，以减少与其分时共享的需要。在某些严重的情况下，OEM 实现的分时过于激进，我们将关闭蓝牙 radio 以强制中断蓝牙 Activity ，但这会造成破坏，并且通常会带来糟糕的用户体验。
我们可能会尝试通过您的接入点本身发送数据，而不是设置 WiFi Direct。这可以避免上述MCC情况，但代价是数据需要重新加密(因为我们不知道哪些其他设备通过LAN连接并且可能正在窃听)，并且它确实引入了另一个跃点，因为即使设备并排，数据也需要通过 AP。 TDLS 有助于避免最后一个问题，但它有局限性(例如，如果 AP 未设置它，它不会使用 40/80/160MHz 带宽，如果 AP 使用 2.4，它将通过 2.4GHz 发送GHz)。
其他可能的故障包括设备进入不良状态(切换飞行模式可以在此处提供帮助)、Android 版本太低(理想情况下，两台设备都应该是 R+，因为几乎不可能修复较旧 Android 操作系统版本上的错误，即使我们尝试过)，或者只是运气不好。
关于android - 为什么使用 Android 附近共享时通过蓝牙传输文件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/70922115/