Android 的 Nearby Share 升级，跨设备文件传输体验
Android 的 Nearby Share 升级，跨设备文件传输体验？先别急着夸
CES 2023 上，Google 和 Samsung 突然宣布了一件事：以后 Nearby Share 改名叫 Quick Share，而且要和 Samsung 自家那套同名服务合并。新闻稿里全是"统一体验""跨设备无缝"这种漂亮话。当时我就觉得不对劲——两个原本各自为政的传输协议，名字还撞车了，这合并怎么看都像是 Samsung 把商标借给 Google 应急，Google 则顺手把 Nearby Share 那堆陈年代码塞进了 One UI 的包装纸。一年多的时间过去，现在回头看这个所谓的"升级"，体验上确实有变化，但底层那堆老毛病不仅没根治，反而因为品牌统一而变得更加隐蔽了。
Samsung 与 Google 的"联姻"：两个 Quick Share 怎么就成了一个
要搞清楚这次升级的来龙去脉，得先回溯一下历史。Samsung 在 Galaxy 设备上早就有一套自己的 Quick Share，核心技术路线很直接：基于 Wi-Fi Direct 建立设备间直连，辅以 BLE 做广播发现。这套东西只服务于 Galaxy 生态，好处是 Galaxy 手机之间传文件确实快，坏处是出了这个圈子就没人认。另一边，Google 的 Nearby Share 从 2020 年开始推，底层依赖的是 Nearby Connections API，设备发现走 BLE，数据传输则在 Wi-Fi Direct、Wi-Fi Hotspot（自建热点）和 WebRTC 之间来回 fallback。Nearby Share 的优势是理论上有 Google Play 服务就能跑，覆盖范围广；劣势是 Wi-Fi Direct 在 Android 生态里的实现烂得一塌糊涂，不同厂商的驱动兼容性堪称灾难。
2023 年的合并逻辑，表面看是"统一 Android 阵营的分享体验"，实际上更像是一场各取所需的商业交易。Samsung 需要让自己的服务看起来不那么封闭，Google 则需要借 Samsung 的品牌影响力把 Nearby Share 推到更多非 Pixel 设备上。合并后的 Quick Share 保留了 Samsung 的图标设计和 UI 风格，底层却换成了 Google 的 Nearby Connections 框架。这就导致了一个非常荒诞的现象：如果你手头有一台旧款 Galaxy，系统还没升级到 One UI 6 之前，你的 Quick Share 和别人的 Quick Share 可能压根不是同一个协议。两台都号称支持 Quick Share 的设备，面对面站着，却因为版本差异要么发现不了对方，要么传输到一半报错断开。这种"统一"简直是品牌层面的黑色幽默。
更离谱的是权限模型的混乱。Samsung 原本的 Quick Share 在 Galaxy 设备上拥有相当高的系统权限，可以常驻后台、绕过部分省电策略。换成 Google 的底层后，这些特权被收回了，因为 Nearby Share 作为 Google Play 服务的一个组件，必须遵循 Android 越来越严格的后台执行限制。结果就是，很多老 Galaxy 用户升级系统后发现 Quick Share 反而不如以前好用了——以前至少 Galaxy 传 Galaxy 是稳的，现在连这个基本盘都开始出现设备发现失败的问题。
底层那些事儿：BLE 广播 + Wi-Fi Direct 的老配方
合并之后，Quick Share 的技术栈并没有发生什么革命性的重构。设备发现依然靠 BLE（Bluetooth Low Energy）广播，实际数据传输则优先尝试 Wi-Fi Direct，失败了就fallback 到自建热点，再不行才走 WebRTC 打洞。这个三段式 fallback 听起来很周全，实际用起来却处处是坑。
BLE 广播本身就有物理层限制。Android 的 BLE 扫描在 2.4GHz 频段上要和 Wi-Fi、微波炉、无线鼠标抢信道，干扰严重的时候两台手机面对面都搜不到对方。Nearby Connections API 做设备发现时，默认的广播间隔和扫描窗口设置得比较保守，这是为了省电，但也意味着如果周围设备稍多或者环境电磁干扰复杂，发现时间会被拉长到十几秒甚至半分钟。对比 Apple 的 AirDrop，人家用的是 AWDL（Apple Wireless Direct Link），这是一个跑在 5GHz 和 2.4GHz 上的私有链路层协议，和基础 Wi-Fi 解耦，专门用于设备发现和点对点传输。Android 这边没有硬件级的统一链路层，只能依赖各厂商的 Wi-Fi 芯片驱动和 BLE 模组，体验怎么可能一致？
Wi-Fi Direct 的问题更大。这个协议在 Android 上从 KitKat 时代就开始用，十年过去了，各家的实现依然各行其是。Qualcomm 平台和 MediaTek 平台的 Wi-Fi Direct 握手时序不一样，某些国产 ROM 为了省电还会主动杀掉 Wi-Fi Direct 的 group owner 协商进程。Nearby Connections API 在建立连接时使用的策略通常是 P2P_STAR，也就是一台设备作为中心节点（Star），其他设备连接上来。但如果中心节点的 Wi-Fi Direct 驱动在 group formation 阶段卡住，整个传输就直接泡汤。GitHub 上 Google 的 nearby 仓库里，关于 Wi-Fi Direct 连接失败的 issue 常年堆积，维护人员的回复永远是"请检查设备兼容性"，因为这种问题根本没法在应用层修复。
WebRTC 作为最后的 fallback 更是鸡肋。一旦走到这一步，说明两台设备之间无法建立直连，数据要过中继服务器。Quick Share 虽然号称端到端加密，但走中继时的延迟和带宽都让人难以忍受，传个大一点的视频，速度可能直接跌落到比 4G 还慢。而且 WebRTC fallback 的触发条件在 Nearby Connections API 里并不透明，用户界面只会显示"正在连接"，背后其实已经在默默尝试打洞失败转 TURN 服务器了。
Windows 上的 Quick Share：能用，但前提是你得先搞定 Google 服务框架
2023 年，Google 给 Windows 10 和 Windows 11 做了一款 Quick Share 应用，理论上让 Android 手机和 PC 之间能像 AirDrop 一样传文件。这个想法不错，执行得却相当 Google 风格——能用，但处处是前提条件。
首先，你的 Windows 机器得有蓝牙 4.0 和 Wi-Fi 适配器，系统版本至少 Windows 10 1803。这还不算完，应用底层依赖 Google Play 服务的部分组件，虽然 Windows 版是一个独立安装包，但它的账号体系、设备认证、加密密钥交换全都要和 Google 服务器握手。对于国内用户来说，这意味着即便你千辛万苦下载到了安装包，大概率也会在登录环节卡死，因为它根本连不上 Google 的认证服务。相比之下，小米的跨屏协作、OPPO 的跨屏互联虽然也需要装 PC 端软件，但至少不依赖一个在国内半残的 Google 服务框架。
其次，传输体验本身也谈不上稳定。Windows 版 Quick Share 使用的是和 Android 端一样的 Nearby Connections 协议栈，BLE 发现、Wi-Fi Direct 传输这一套在 Windows 的 Wi-Fi 驱动环境下兼容性更差。很多用户反馈，传小文件（比如几张照片）成功率还行，一旦涉及视频或者大体积文档，Windows 端的后台进程很容易被系统挂起，传输直接中断。Windows 不像 Android 那样允许 Quick Share 在系统层面保持高优先级后台服务，一旦用户切到别的窗口，传输任务就可能被资源管理器"优化"掉。
讽刺的是，Intel Unison 和微软的 Phone Link 在 Windows 上的文件传输虽然也有各自的问题，但至少在设备发现和连接稳定性上比 Quick Share 更可靠。Quick Share 在 Windows 上的定位非常尴尬：对于 Pixel 用户来说，这是一个官方出品的"原生"方案；对于其他 Android 用户来说，厂商自己的 PC 互联套件往往更好用；而对于国内用户，这玩意儿几乎处于不可用状态。Google 做跨平台传输的野心很大，但落到 Windows 这个开放却混乱的桌面上，Quick Share 的短板暴露无遗。
设备发现：为什么我的手机总是找不到你的手机？
用过 Quick Share 的人应该都经历过这种场景：两台手机都打开了功能，面对面亮着屏，等了十几秒，设备列表里空空如也。这种情况不是偶然，而是 Android 系统架构和权限模型演变带来的必然结果。
Android 12 引入了 BLUETOOTH_SCAN 和 BLUETOOTH_ADVERTISE 两个运行时权限，应用需要在清单文件里声明，并在运行时动态申请。Quick Share 作为 Google Play 服务的组件，理论上应该能处理好这些权限，但问题在于，设备发现是一个双向过程——不仅你的手机要扫描，对方的手机也要广播。很多情况下，接收方手机虽然打开了 Quick Share，但因为屏幕熄灭进入了 Doze 模式，BLE 广播被系统大幅降频，甚至暂停。发送方在这边疯狂扫描，接收方在那边装死，怎么可能发现得了？
Android 的后台限制从 8.0 开始逐年收紧，到了 Android 14，即便是 Google 自家的服务也很难肆无忌惮地后台保活。Nearby Share 需要持续进行 BLE 广播和监听，这本身就是一个高功耗行为，各家国产 ROM 的省电策略根本不惯着它。MIUI 的省电限制、ColorOS 的后台冻结、HarmonyOS 的资源管控，都会在不同程度上切断 Quick Share 的后台进程。这就导致了一个很诡异的局面：Pixel 找 Pixel，有时候都不一定能秒发现；Pixel 找 Samsung，可能需要两边反复开关功能才能刷出设备；而国内厂商手机之间，大家更倾向于用自己的互传联盟，Quick Share 形同虚设。
还有一种更隐蔽的情况：Wi-Fi 和蓝牙的地址随机化。Android 10 开始支持蓝牙 MAC 地址随机化，Android 12 之后 Wi-Fi 的 MAC 随机化也成了默认行为。Nearby Connections API 在建立连接时需要处理地址