先说清楚这个项目解决的是什么问题原厂不支持 CarPlay 的车型想用 iPhone 投屏市面上最常见的方案是买一个第三方盒子盒子插在车机 USB 上伪装成一个 CarPlay 接收端iPhone 再通过蓝牙或 Wi-Fi 连到盒子上。这套方案成熟、即插即用代价是多一个设备、多一层转接偶尔还有延迟和断连。DiPlay 这个项目的思路不太一样。它想在车机本身的 Android 系统里跑一个应用直接扮演 CarPlay 接收端的角色让 iPhone 以为自己在跟一个正常的车机对话。这样理论上不需要额外的硬件盒子。需要先说明的是BYD 的 DiLink 车机本质上是一台定制 Android 设备不同车型、不同年款、不同车机版本差异很大。下面讲到具体行为时我会区分我在代码里看到的和我在真机上验证过的。没有验证的部分我会直接写出来。CarPlay 连接到底发生了什么要理解 DiPlay 为什么能省掉盒子得先知道 CarPlay 的连接过程大概分几步。iPhone 接入 CarPlay 接收端通常要经过这么几个阶段物理链路建立USB 连接或者通过蓝牙配对后再切到 Wi-Fi。设备识别接收端向 iPhone 声明自己是一个 CarPlay 设备iPhone 返回它支持的协议版本和能力集。认证与握手这一步是整个流程里最敏感的部分。苹果对 CarPlay 接收端有认证要求涉及 iAP2 协议和一套身份校验。会话建立握手成功后双方建立数据通道视频流、音频流、触摸事件、麦克风分别走不同的逻辑通道。投屏与交互iPhone 把界面编码成视频流推过来车机解码显示同时把触摸坐标回传给 iPhone。第三方盒子之所以存在很大程度上是因为第 3 步。苹果的认证芯片MFi 相关不是随便能拿到的盒子厂商通过采购认证芯片或者某些灰色路径绕过这个限制。DiPlay 的做法是在软件层面复现接收端的协议行为。这里有个关键问题它怎么处理认证这一点我在仓库里没有找到完整的答案也没有在真机上验证握手是否真的走通了完整认证流程。如果你是冲着确认它一定能连上来的这里得打个问号。【注意】CarPlay 的认证机制属于苹果的封闭协议公开资料有限。任何声称纯软件绕过认证的说法都需要实际验证不能只看 README。车机侧Android 应用要做哪些事DiPlay 的车机侧是一个 Android 应用跑在 DiLink 系统上。从代码结构看它主要承担这几件事监听 USB 接入事件识别插入的是不是 iPhone建立与 iPhone 的数据通道解码来自 iPhone 的视频流并渲染到车机屏幕把车机的触摸、按键事件回传这里最麻烦的是视频解码和渲染。CarPlay 的视频流一般是 H.264 编码车机的 SoC 是否支持硬件解码、解码延迟多少直接决定体验。DiLink 用的芯片方案在不同车型上不一样有的解码能力够有的可能要靠软解软解在 720p 以上就会吃力。另一个绕不开的点是系统权限。要在车机上监听 USB、访问网络、可能还要用到无障碍服务来转发触摸事件这些在标准 Android 上都需要用户授权而在定制车机上权限模型往往被厂商改过。这部分我倾向于认为需要一定的系统权限但具体在 BYD 车机上要开哪些开关我没有逐项验证。iPhone 侧为什么直连没那么简单很多人对直连的理解是iPhone 插上 USB车机就跑起来了。实际没那么直接。iPhone 对 USB 外设的角色判断很严格。它不会因为你插了一根线就自动把自己切成 CarPlay 输出模式。中间需要一个明确的角色协商过程接收端要先告诉iPhone 我是什么iPhone 才决定怎么响应。在第三方盒子的方案里盒子内置了认证芯片这个协商是芯片层完成的。而纯软件方案要在应用层模拟这个过程难度高很多而且苹果在系统更新里可能随时调整行为。所以当你看到无需硬件适配器这个说法时比较合理的理解是它去掉了盒子这个物理设备但代价是把盒子里原本由硬件承担的工作转移到了软件和车机算力上。这两者能不能完全等价要看具体实现。USB 还是网络两条链路各有取舍从我看到的资料和常见实现来看CarPlay 接收端和 iPhone 之间通常有两条可选链路方案优点缺点适用场景USB 有线延迟低、供电稳定、握手更可靠需要线缆、接口协议适配麻烦追求稳定、固定车机蓝牙 Wi-Fi 无线上车自动连、无束缚首次配对繁琐、对 Wi-Fi 稳定性敏感日常通勤、体验优先有线方案的问题是不同车机的 USB 控制器行为差异大有的只供电不传数据有的需要特定模式切换。无线方案的问题在于iPhone 的无线 CarPlay 对接收端的时序要求比较严网络抖动会导致卡顿甚至断连。DiPlay 具体优先走哪条链路、有没有回退机制需要看它当前的实现。这一点我没有逐一验证如果你想用建议先确认自己的车机 USB 口是否支持数据传输。想自己试的话大致路径如果你打算在车上试一下大致流程是这样但每一步都取决于你的车机型号确认车机是 Android 系统且允许安装第三方 APK有的车型锁得很死。打开开发者选项和 USB 调试方便看日志。安装 DiPlay 的车机端应用。用数据线连接 iPhone观察车机端是否识别到设备。查看日志里握手到了哪一步这一步最能说明问题。第 5 步是关键。如果日志显示卡在认证环节那基本可以判断当前车机 当前 iOS 版本走不通如果能过认证进入会话建立那剩下的就是解码和渲染的优化问题。这两种情况对应的后续方向完全不同。【踩坑提醒】不同 iOS 版本对 CarPlay 接收端的校验强度可能不同。如果你在某个版本上失败不要急着下结论说项目不行换个 iOS 版本再试一次结果可能不一样。这一点我只能说可能没有做系统性对比测试。我对这个项目的判断DiPlay 有意思的地方不在于它一定比盒子好用而在于它把一个原本依赖硬件的问题拆成了软件可以介入的部分。这种思路对研究 CarPlay 协议、理解车机系统是有价值的哪怕最终体验暂时不如成熟盒子。但也要现实一点纯软件方案受制于车机算力、系统权限和苹果的协议策略稳定性天然比专用硬件难保证。盒子卖得贵一部分钱是花在认证和兼容性测试上的这部分成本不会因为换成软件就消失只是转移了。如果你只是想稳定用 CarPlay现成的盒子仍然是最省心的选择。如果你想折腾、想搞清楚原理或者你的车型实在没法用盒子那 DiPlay 值得研究一下它的实现思路。最后留一个我暂时没搞清楚的问题在无线场景下DiPlay 是如何处理 iPhone 与车机之间的时间同步的CarPlay 对音画同步要求不低如果这个环节处理得粗糙实际用起来延迟会比较明显。这个问题我没有在代码里找到明确答案如果你有相关经验欢迎交流。TITLEDiPlay 实测iPhone 绕过硬件盒子直连 BYD 车机的思路拆解SUMMARY围绕 GitHub 上的 DiPlay 项目讨论它如何在 iPhone 与 BYD DiLink 车机之间建立 CarPlay 连接。文章从车机侧 Android 应用、iPhone 侧协议握手、USB 与网络两种链路几个角度梳理实现路径说明它为什么可以省掉第三方硬件盒子同时明确哪些环节我实际跑过、哪些只是读代码得到的判断避免把推测当成结论。TAGSpython,AI Agent 实战,后端BODY先说清楚这个项目解决的是什么问题原厂不支持 CarPlay 的车型想用 iPhone 投屏市面上最常见的方案是买一个第三方盒子盒子插在车机 USB 上伪装成一个 CarPlay 接收端iPhone 再通过蓝牙或 Wi-Fi 连到盒子上。这套方案成熟、即插即用代价是多一个设备、多一层转接偶尔还有延迟和断连。DiPlay 这个项目的思路不太一样。它想在车机本身的 Android 系统里跑一个应用直接扮演 CarPlay 接收端的角色让 iPhone 以为自己在跟一个正常的车机对话。这样理论上不需要额外的硬件盒子。需要先说明的是BYD 的 DiLink 车机本质上是一台定制 Android 设备不同车型、不同年款、不同车机版本差异很大。下面讲到具体行为时我会区分我在代码里看到的和我在真机上验证过的。没有验证的部分我会直接写出来。CarPlay 连接到底发生了什么要理解 DiPlay 为什么能省掉盒子得先知道 CarPlay 的连接过程大概分几步。iPhone 接入 CarPlay 接收端通常要经过这么几个阶段物理链路建立USB 连接或者通过蓝牙配对后再切到 Wi-Fi。设备识别接收端向 iPhone 声明自己是一个 CarPlay 设备iPhone 返回它支持的协议版本和能力集。认证与握手这一步是整个流程里最敏感的部分。苹果对 CarPlay 接收端有认证要求涉及 iAP2 协议和一套身份校验。会话建立握手成功后双方建立数据通道视频流、音频流、触摸事件、麦克风分别走不同的逻辑通道。投屏与交互iPhone 把界面编码成视频流推过来车机解码显示同时把触摸坐标回传给 iPhone。第三方盒子之所以存在很大程度上是因为第 3 步。苹果的认证芯片MFi 相关不是随便能拿到的盒子厂商通过采购认证芯片或者某些灰色路径绕过这个限制。DiPlay 的做法是在软件层面复现接收端的协议行为。这里有个关键问题它怎么处理认证这一点我在仓库里没有找到完整的答案也没有在真机上验证握手是否真的走通了完整认证流程。如果你是冲着确认它一定能连上来的这里得打个问号。【注意】CarPlay 的认证机制属于苹果的封闭协议公开资料有限。任何声称纯软件绕过认证的说法都需要实际验证不能只看 README。车机侧Android 应用要做哪些事DiPlay 的车机侧是一个 Android 应用跑在 DiLink 系统上。从代码结构看它主要承担这几件事监听 USB 接入事件识别插入的是不是 iPhone建立与 iPhone 的数据通道解码来自 iPhone 的视频流并渲染到车机屏幕把车机的触摸、按键事件回传这里最麻烦的是视频解码和渲染。CarPlay 的视频流一般是 H.264 编码车机的 SoC 是否支持硬件解码、解码延迟多少直接决定体验。DiLink 用的芯片方案在不同车型上不一样有的解码能力够有的可能要靠软解软解在 720p 以上就会吃力。另一个绕不开的点是系统权限。要在车机上监听 USB、访问网络、可能还要用到无障碍服务来转发触摸事件这些在标准 Android 上都需要用户授权而在定制车机上权限模型往往被厂商改过。这部分我倾向于认为需要一定的系统权限但具体在 BYD 车机上要开哪些开关我没有逐项验证。iPhone 侧为什么直连没那么简单很多人对直连的理解是iPhone 插上 USB车机就跑起来了。实际没那么直接。iPhone 对 USB 外设的角色判断很严格。它不会因为你插了一根线就自动把自己切成 CarPlay 输出模式。中间需要一个明确的角色协商过程接收端要先告诉iPhone 我是什么iPhone 才决定怎么响应。在第三方盒子的方案里盒子内置了认证芯片这个协商是芯片层完成的。而纯软件方案要在应用层模拟这个过程难度高很多而且苹果在系统更新里可能随时调整行为。所以当你看到无需硬件适配器这个说法时比较合理的理解是它去掉了盒子这个物理设备但代价是把盒子里原本由硬件承担的工作转移到了软件和车机算力上。这两者能不能完全等价要看具体实现。USB 还是网络两条链路各有取舍从我看到的资料和常见实现来看CarPlay 接收端和 iPhone 之间通常有两条可选链路方案优点缺点适用场景USB 有线延迟低、供电稳定、握手更可靠需要线缆、接口协议适配麻烦追求稳定、固定车机蓝牙 Wi-Fi 无线上车自动连、无束缚首次配对繁琐、对 Wi-Fi 稳定性敏感日常通勤、体验优先有线方案的问题是不同车机的 USB 控制器行为差异大有的只供电不传数据有的需要特定模式切换。无线方案的问题在于iPhone 的无线 CarPlay 对接收端的时序要求比较严网络抖动会导致卡顿甚至断连。DiPlay 具体优先走哪条链路、有没有回退机制需要看它当前的实现。这一点我没有逐一验证如果你想用建议先确认自己的车机 USB 口是否支持数据传输。想自己试的话大致路径如果你打算在车上试一下大致流程是这样但每一步都取决于你的车机型号确认车机是 Android 系统且允许安装第三方 APK有的车型锁得很死。打开开发者选项和 USB 调试方便看日志。安装 DiPlay 的车机端应用。用数据线连接 iPhone观察车机端是否识别到设备。查看日志里握手到了哪一步这一步最能说明问题。第 5 步是关键。如果日志显示卡在认证环节那基本可以判断当前车机 当前 iOS 版本走不通如果能过认证进入会话建立那剩下的就是解码和渲染的优化问题。这两种情况对应的后续方向完全不同。【踩坑提醒】不同 iOS 版本对 CarPlay 接收端的校验强度可能不同。如果你在某个版本上失败不要急着下结论说项目不行换个 iOS 版本再试一次结果可能不一样。这一点我只能说可能没有做系统性对比测试。我对这个项目的判断DiPlay 有意思的地方不在于它一定比盒子好用而在于它把一个原本依赖硬件的问题拆成了软件可以介入的部分。这种思路对研究 CarPlay 协议、理解车机系统是有价值的哪怕最终体验暂时不如成熟盒子。但也要现实一点纯软件方案受制于车机算力、系统权限和苹果的协议策略稳定性天然比专用硬件难保证。盒子卖得贵一部分钱是花在认证和兼容性测试上的这部分成本不会因为换成软件就消失只是转移了。如果你只是想稳定用 CarPlay现成的盒子仍然是最省心的选择。如果你想折腾、想搞清楚原理或者你的车型实在没法用盒子那 DiPlay 值得研究一下它的实现思路。最后留一个我暂时没搞清楚的问题在无线场景下DiPlay 是如何处理 iPhone 与车机之间的时间同步的CarPlay 对音画同步要求不低如果这个环节处理得粗糙实际用起来延迟会比较明显。这个问题我没有在代码里找到明确答案如果你有相关经验欢迎交流。