USB 还是无线？DiPlay 双连接模式延迟与稳定实测对比

DiPlay 是一个运行在安卓车机上的独立 CarPlay 接收端，不需要苹果认证的盒子、越狱或认证服务器，用 USB 或无线两条路线都能把 iPhone 投到车机上。社区里"完全免费"的说法（见 README 与社区装机讨论）吸引了很多车主，但真正决定日常体验的是另一件事：两种连接方式的延迟、画面帧率与断连表现到底差多少，什么时候该用哪条线。本文基于项目源码与官方实测文档（docs 目录）梳理两条链路从建立到传输的完整过程，并把所有有据可查的量化数据摆出来，帮你按自己的车机和用车场景做选择。

一、两种模式，三套无线后端：连接建立过程对比

DiPlay 的"无线"并不是一个开关，而是一个可切换的后端集合。从源码看，连接设置页同时暴露了三种无线形态和一个独立的 USB 形态（ConnectionSettingsSection.kt）：

• WIFI_P2P：Wi-Fi Direct，Android 10+ 才提供该选项；
• MANUAL：车机自带热点（默认后端）；
• EXISTING_WIFI：车机和 iPhone 共连同一个外部路由器（同局域网）；
• 有线 USB 则是与上述三者并列的另一条传输管线。

USB：先"假装成配件"，再建立隧道

USB 链路在 IphoneUsbHost.kt 中实现，整个带来流程相当"硬核"：它按 Apple 厂商 ID 0x05ac 匹配设备，先通过厂商请求 0x52 让 iPhone 重新枚举一次，再选中配置 6，随后走 USBMUX/NCM 通道承载 iAP2 与视频流。由于 Android 没有同步重枚举原语，代码会主动关闭首个连接、等待新设备再授权（ReenumerationRequested 状态）。

对用户而言，这意味着三个硬性前提：必须插 数据口 + 数据线（充电口/充电线无法建立数据链路），要放行系统 USB 授权弹窗，并且 DiPlay 会拉起一个本地 VPN 来承载这条"USB 网络链路"（见 INSTALL.md）——它不是互联网 VPN，只是传输通道。弹窗的重复授权甚至专门配了一个无障碍服务 UsbAutoConfirmService.kt，自动勾选"始终允许"并点确认，可见有线路径里授权环节本身就是体验的一部分。

无线：蓝牙给钥匙，Wi-Fi 走数据

无线路径的建立分两段。第一段是蓝牙 iAP2 握手：DiPlay 通过 0x5703 消息把 Wi-Fi 凭据塞给 iPhone，用 0x4301 告知选中的传输端点（见 EXISTING_WIFI.md），随后靠 Bonjour/mDNS 完成 CarPlay 控制服务发现。第二段才是数据面：

• Wi-Fi Direct（WifiP2pGroupManager.kt）：在车机上创建临时组 Owner，偏好 5 GHz。Android 10+ 能验证协商后的实际频段；Android 7.1–9 走固件相关的 legacy 路径，只能报告"请求的频段"而无法核验（详见 ANDROID9_WIFI_DIRECT.md）。
• 车机自带热点：用户在车机设置里开 5 GHz 热点并保存名字密码，蓝牙握手把凭据传给 iPhone 自动加入。但自动加入有一个隐藏开关：苹果要求热点广播 Apple 厂商信息元素，DiPlay 在 WIRELESS_HOTSPOT_JOIN.md 里用受控对照实验验证过——加入该元素（dd0800a0400000020021，OUI 00:a0:40）后 iPhone 自动加入并启动 CarPlay，移除后则只离开当前 Wi-Fi 而不加入热点。这解释了为什么很多人"手动连就能用、自动连就断"。
• 现有 Wi-Fi / 同局域网（ExistingWifiManager.kt）：不创建 AP、不加入新网络，复用外部路由器，车机和 iPhone 各连一个，靠局域网互通完成发现与传输。实测在一台 2022 款比亚迪汉 DM-i（DiLink 4.0 / Android 10）上干净安装后顺畅进入 CarPlay。

可以看到，无线模式把"建连"拆成了蓝牙授信 + Wi-Fi 组网两步，任何一个环节掉链子（自动加入失败、频段不被固件接受、Bonjour 发现不到端点）都会卡在启动阶段——这正是 WIRELESS_DIAGNOSTICS.md 里用 authenticated / bonjourResolved / airplay TCP accepted / sessionActive 等里程碑逐段定位故障的原因。而 USB 模式没有组网环节，物理插上即进入枚举-鉴权流程，链路建立路径明显更短。

二、实测数据：帧率、卡顿与可靠性

项目没有给出"USB 对比无线"的单一延迟数字——这一点必须先说清楚，仓库里也没有虚构这种对比。但官方文档给出了两台车上的分场景量化数据，足够画出可信的画像。

帧率与画面尺寸（2024 款比亚迪唐，DiLink 5.0 / iOS 27，无线）

SMOOTH_WIRELESS.md 记录了滚动 Apple Music 列表时，不同画面设置下的接收/渲染帧率：

设置	画面	每帧像素	滚动时帧率
旋转关闭	2560×1440（屏幕原生）	370 万	45–57 fps
旋转开 + 更流畅(1920)	1920×1920 方形	370 万	49–57 fps
旋转开 + 更清晰(屏幕尺寸)	2560×2560 方形	660 万	32–44 fps

结论很直接：像素量翻倍，帧率从 ~50 掉到 ~35。无线链路的瓶颈不在单点，而是"iPhone 编码 → 空口传输 → 车机解码"整条管线，画面越大，每一步的负载都越高。

信道争用是最典型的无线杀手

同样在这台唐上，当 Wi-Fi Direct 跑在与车机所连 Wi-Fi 不同的 5 GHz 信道时，出现"画面每 0.6–2 秒停一下、音乐断断续续"；把 Wi-Fi Direct 换到 2.4 GHz 与 5 GHz 网络并存时反而流畅。这被归因为无线电同频争用。配套的缓冲音乐实验（BUFFERED_AUDIO.md）给出了传输侧证据：5 GHz Wi-Fi Direct（5745 MHz）+ 车机同时连 5 GHz 家庭网络（5200 MHz）时，缓冲流只到 49–281 kbit/s，队列永远填不满、音乐照卡；切 2.4 GHz 后两个问题同时消失。

也就是说，无线模式下的"卡顿"常常不是 DiPlay 的软件缺陷，而是车机单射频下空口自相残杀——这也是为什么连接设置里把"优选信道"做成了显式选项（Auto / 手动 2.4 或 5 GHz 信道，见 INSTALL.md）。

USB 上的平滑视频 A/B 实验

"Smooth video（实验性）"的两次 A/B 捕获是在 USB 上做的（固定 90 ms 延迟版，2560×1440 / 60 fps，dumpsys SurfaceFlinger --latency 统计）：

轮次	Smooth video	统计秒数	下一帧延迟 1 个刷新周期	呈现帧率
A1	关	9	63.6%	42.4
B1	开	29	86.0%	51.2
A2	关	31	63.8%	42.1
B2	开	37	83.4%	50.0

关键洞察是：iPhone 的 SPS 声明 max_num_reorder_frames=0、帧内无 B 片，但高通解码器 c2.qti.avc.decoder 仍会积压约两帧才吐出一帧。Smooth video 的作用是把解码器"成簇输出"重新铺回 iPhone 的时间格，使 83–86% 的帧在下一个刷新周期准时上屏。它的代价是引入 30–200 ms 的自适应显示延迟，触摸响应变慢。这个实验选在 USB 上做，正是因为 USB 链路受空口抖动影响最小，能隔离出解码器本身的时序问题——反过来也说明：要排查"无线到底卡在哪一环"，先回 USB 是项目推荐的方法论。

可靠性：以"重连"为验收标尺

CONNECTION_RELIABILITY.md 记录了两种模式各自的已知失败族：USB 侧有 USBMUX 头尾帧越界、大请求入队被拒（回退 16 KiB）、接口 claim 失败；无线侧有 RFCOMM 能开但换不了字节、读队列停摆。每个修复都配了合成回归测试——当前主干通过 1,534 个单元用例（1,533 通过、1 个跳过）。

验收协议本身也说明了可靠性的定义：每台车上做 3 次冷启动 + 每种连接模式 10 次断连/重连循环，且要在"挂起的 USB 读取中拔线""蓝牙引导中拆连接"这类边界下验证下一条会话不继承旧状态。无线会话还有一个 45 秒看门狗：隧道 iAP2 就绪前必须有渲染出的视频帧，否则不保留会话（STEP handoff/fallback 与 STEP handoff/complete 严格区分，见 WIRELESS_DIAGNOSTICS.md）。

运行中如何自查？DiPlay 每 5 秒输出一行 DiPlay-VideoStats（VideoStats.kt）：

video stats rx=56.2fps shown=56.4fps maxGap=73ms kbps=28899

rx 是收到的帧率，shown 是真正交给渲染的帧率，maxGap 是帧间隔上限，另有 decode p50/p90、late、delay 等字段。如果 shown 跟不上 rx，问题偏解码/渲染；如果 rx 本身偏低，就要查 Wi-Fi 链路与画面设置——这是区分"卡在车机"还是"卡在空口"的最直接工具。

三、按场景选择连接方式

综合以上源码与实测，给出可执行的选型建议：

USB：追求稳定与长会话的首选。 链路建立路径最短、无信道争用、无自动加入依赖，官方用 USB 隔离解码问题时也印证了它的基线地位。代价是必须占一个数据口、插线，且依赖弹窗授权（有自动确认服务兜底）。适合停车充电、长时间导航、以及排查"到底是不是无线问题"的场景。

车机自带热点：默认且最省心，但依赖固件。 5 GHz 优先，蓝牙自动传凭据，无需手动组网；自动加入依赖热点的 Apple 信息元素，若"手动连可、自动连不可"，先按 WIRELESS_HOTSPOT_JOIN.md 的对照方法区分关联失败与建链失败。适合大多数日常通勤，且是唯一能实现"上车即连"的默认形态。

Wi-Fi Direct：低延迟潜力高，但要管信道。 Android 10+ 能验证实际频段、有"自动恢复已保存的成功配置"机制（P2pConfigurationMemory），0.2.15 也明确标注了 Wi-Fi Direct 性能大幅改进。但如果车机同时连着 5 GHz 网络，请优先尝试 2.4 GHz 信道或回到 Auto——同频争用造成的 0.6–2 秒停顿就是它最大的坑。

现有 Wi-Fi / 同局域网：家里/固定场地的最佳形态。 不创建 AP、不动默认路由，靠外部路由器供网，实测已在汉 DM-i 上验证；要求路由器关闭客户端隔离并允许 mDNS。适合车机长期停在一个稳定 Wi-Fi 环境下的场景。

最后必须提醒：项目自身在 CONNECTION_RELIABILITY.md 中明确写着"Wi-Fi Direct 性能（#131）仍需要受控的 P2P/热点对比实验，现有报告不足以证明扫描抑制或单信道变更能根治问题"。这意味着目前没有任何一份公开证据能给出"无线全面优于 USB"的结论——所有无线链路的高帧率数据都伴随信道、画面尺寸等前提条件。如果你是排查者，请遵循项目流程：先在 0.2.15 上复现，导出诊断报告，附上车辆/固件/iPhone 型号与连接模式，再下结论。这套"证据驱动"的工程态度，本身就是这个开源项目最有价值的资产。