从 Demo 到商用一个照片直播系统的 Android 相机连接实践#Android USB Host、PTP、MTP、照片直播、相机连接、商业项目、实时传图很多开发者第一次接触 Android 相机连接时都会认为这是一个比较简单的功能USB OTG PTP/MTP 读取照片。网上也能找到不少 Demo几百行代码就能实现相机连接。但是当真正把它应用到商业项目时你会发现Demo 能跑并不代表产品能用。过去一年我们参与开发了一套照片直播系统在多个真实活动中持续运行。本文分享一些从 Demo 到商用过程中踩过的坑以及最终的技术架构希望能给正在做相机连接、摄影工具或照片直播产品的开发者一些参考。一、Demo 为什么能成功大部分开源 Demo 的目标只有一个证明 Android 能连接相机。通常流程如下USB OTG ↓ 发现 USB Device ↓ 申请权限 ↓ PTP/MTP 通信 ↓ 读取图片 ↓ 完成对于学习协议来说这没有问题。但商业产品关注的是连接成功以后能不能连续工作几个小时。二、商业项目真正面对的问题照片直播和普通工具 App 最大的区别就是它是一个持续运行的系统。例如一场婚礼、体育赛事或者企业活动摄影师连续拍摄几百张照片相机始终保持连接手机实时获取新照片图片自动上传服务器AI 修图同步执行。整个过程可能持续数小时。如果底层没有做好状态管理很容易出现USB 异常断开相机进入休眠高速连拍漏图上传任务阻塞内存持续增长。这些问题在 Demo 中几乎不会暴露。三、我们重新设计了整个连接架构项目初期我们也采用了常见的 Demo 写法。后来随着业务增长逐渐拆分成多个独立模块。整体架构如下Application业务层 ↓ Upload Manager上传管理 ↓ Photo Queue照片队列 ↓ PTP / MTP Engine协议层 ↓ USB Host Manager设备管理每一层职责单一。例如USB Host Manager负责USB 设备发现权限申请生命周期管理自动重连。PTP / MTP Engine负责协议通信Session 管理Event 获取文件下载。业务层无需关心协议细节。Photo Queue这一层其实是整个项目最重要的模块。原因很简单。摄影师不会等系统处理完一张照片再拍下一张。连续拍摄时新的图片不断产生。下载。上传。AI 修图。全部同时进行。如果没有任务队列很容易出现重复下载顺序错乱上传阻塞。因此我们采用下载队列 上传队列 AI 队列三条流水线独立运行。四、为什么我们没有使用目录轮询很多 Demo 会不断扫描相机目录。发现新文件以后开始下载。这种方式实现简单。但是摄影师高速连拍时。轮询会越来越慢。甚至漏掉部分图片。后来我们改成PTP Event 实时监听。当相机产生新照片时直接收到事件通知。无需不断扫描目录。这样实时性更高。CPU 占用更低。稳定性也明显提升。五、真实项目中的几个优化经过持续迭代目前我们重点优化了以下几个方面。1、连接状态机连接。工作。异常。恢复。整个生命周期都有明确状态。避免重复初始化。2、自动重连USB 被误碰。相机休眠。OTG 重连。SDK 自动恢复连接。无需人工重新操作。3、多品牌兼容不同品牌相机USB Descriptor。PTP Event。对象获取方式。都会存在细微差异。因此我们增加了兼容层。统一对外接口。业务层无需区分品牌。4、上传异步化照片下载完成以后立即进入上传队列。AI 修图。上传。云端同步。全部异步执行。摄影师几乎感觉不到等待。六、真实项目运行效果经过持续优化目前整个方案已经应用于真实摄影活动。整体能力包括✅ Android USB Host✅ Android OTG 有线连接专业相机✅ iPhone / iPad 有线连接专业相机✅ PTP 协议通信✅ MTP 文件读取✅ 新照片实时监听✅ 边拍边传✅ 自动上传✅ AI 修图流程接入✅ 自动断线恢复✅ 多品牌相机兼容Canon / Sony / Nikon 等目前该方案已经能够稳定支持长时间连续工作并服务于真实摄影业务而不仅仅停留在实验室 Demo。七、从 Demo 到商用我最大的感受这一年最大的体会是真正困难的不是让相机连接成功。而是让整个系统在真实环境下连续运行几个小时。商业项目真正需要关注的是稳定性容错能力状态管理队列调度长时间内存控制多设备兼容。协议只是基础。真正决定产品体验的是整个工作流的设计。写在最后随着照片直播、AI 修图、摄影 SaaS、云相册等产品不断发展相机连接已经不再只是一个底层功能而是一整套摄影工作流的起点。从 Demo 到商用最大的变化不是代码量增加了而是思维方式改变了从功能实现转向系统稳定运行。如果你也在开发 Android USB Host、PTP/MTP、摄影工具、照片直播或相关产品欢迎交流实践经验。