智能仪表厂商：自研骑行 APP，还是接入现有 APP 与 SDK？
从手机端维护、FreeRTOS 固件、车辆接口和交付范围比较两种接入方式，了解无限骑行 APP 与硬件 SDK 的分工。
先判断手机端是不是你的核心产品
如果团队需要独立掌握手机端界面、功能节奏和平台维护，可以评估自研骑行 APP。如果重点是仪表硬件、车辆接口和仪表 UI，希望复用已有的手机互联能力，可以评估接入现有 APP 与终端 SDK。两种方式都需要硬件适配和实机验收，不能只比较第一次配对是否成功。
无限骑行（Infinite Ride）提供 Android / iOS 骑行 APP 和面向 FreeRTOS 的 C99 硬件 SDK，面向摩托车、电动车智能仪表接入。厂商保留自己的开发板、显示界面和车辆接口；无限骑行不是整车供应商，也不提供适用于所有仪表的即插即用硬件。
自研与接入，工作分别落在哪里？
| 评估项目 | 自研手机端方案 | 接入无限骑行 APP 与 SDK |
|---|---|---|
| 手机端维护 | 团队负责 APP、设备连接流程、业务协议及系统适配 | 复用现有 APP 与 SDK 的接入流程，先确认所需功能是否覆盖 |
| 仪表固件 | 自行设计或选择通信协议，再连接板级驱动 | 使用匹配平台的 SDK 静态库，连接 Wi-Fi、存储、时钟及显示驱动，按需增加蓝牙通知与配对引导 |
| 仪表界面 | 团队自行设计和实现 | 仍由厂商决定界面，按 SDK 事件更新显示 |
| 车辆接口 | 实现真实状态读取、控制执行与结果反馈 | 仍由厂商完成 CAN、串口或其他车辆接口适配 |
| 交付评估 | 同时评估手机端、协议、固件和运营维护 | 重点确认功能覆盖、平台匹配、授权及硬件适配范围 |
蓝牙通知需要独立的 Core BLE 辅助实例；Managed Wi-Fi 入口不会自动创建该连接。选型时先看架构与生命周期，再按目标功能选择入口。
是否节省预算和工期取决于已有代码、团队配置与硬件成熟度。应当在同一份功能清单和验收条件下比较，不用一个固定百分比代替项目评估。
无限骑行交付什么，厂商需要做什么？
SDK 核心以闭源二进制方式交付，包含目标平台静态库、公开头文件、示例和接入文档。静态库需要匹配 CPU 架构、FreeRTOS 配置及编译器 ABI；换芯片或工具链时，应重新确认接入包。
厂商负责板级通信、持久化、屏幕、解码和车辆接口。SDK 将手机与设备之间的事件交给固件处理，不会自动实现车门解锁、视频解码或任意开发板的驱动。功能还需与后台设备型号配置一致。
可先阅读SDK 产品介绍、平台与授权和首次连接步骤，再确认自己的工程能复用哪些部分。
选型前的常见问题
可以保留自己的仪表 UI 吗？
可以。厂商使用自己的显示驱动和界面处理 SDK 事件。大屏导航同时接入投屏与 HUD；小屏无法投屏时可以只使用 HUD。具体布局由厂商设计，详见导航接入说明。
有 ESP32-P4 示例，是否代表所有开发板都能直接运行？
不代表。公开的 ESP32-P4 参考工程提供应用与板级接线参考，SDK 核心仍为二进制。其他开发板需要匹配的平台库、驱动和资源评估。
设备配对成功，是否就完成了接入？
没有。还需验证真实车况、控制结果、断连重连、导航显示和权限撤回等目标功能。可以按联调与交付检查建立验收清单。
如何确认费用、交付范围和时间？
咨询时提供芯片与工具链、FreeRTOS 版本、屏幕与解码能力、BLE / Wi-Fi 条件、车辆接口、目标功能和样机状态。由双方据此确认平台支持、设备授权、交付范围和报价；公开文档不能替代项目交付约定。
用一台样机开始评估
先完成设备发现、认证配对、能力读取和一项真实状态显示，再按目标逐项加入控车、导航和通知。已有多个仪表型号时，可继续阅读如何共用一套骑行 APP。