我为什么没有直接把 GitHub Demo 集成到项目里？一次 Android SDK 开发复盘

Android、SDK、USB Host、架构设计、模块化、开源项目、商业开发

很多开发者做 Android 项目时，第一反应都是：

GitHub 搜一个 Demo，改一改，项目就能上线。

我以前也是这么想的。

直到后来做一个需要长期稳定运行的相机连接项目，才发现：

Demo 和商业 SDK，完全不是一回事。

---

Demo 解决的是"能不能"

GitHub 上很多 Android USB Demo 都很优秀。

能够完成：

• USB 设备识别；
• 权限申请；
• 建立连接；
• 下载文件。

如果只是学习协议，它们已经足够。

但是它们更多是在回答：

Android 能不能连接相机？

而商业项目需要回答的是：

几十个客户同时使用，还能不能稳定运行？

这已经是两个完全不同的问题。

---

为什么我没有直接改 Demo？

项目刚开始，我们也尝试过。

结果不到两周，就发现越来越难维护。

比如：

一个类负责：

• USB 管理；
• 协议通信；
• 下载照片；
• 上传服务器；
• 回调业务层。

代码越来越长。

任何地方改动，都可能影响整个流程。

最后只能全部推倒重来。

---

SDK 真正需要的是"边界"

后来，我们重新划分了模块。

每一层只负责一件事情：

Business API
        │
Photo Service
        │
Transfer Engine
        │
PTP / MTP Engine
        │
USB Manager

这样的好处很明显：

• 上层不用关心 USB 细节；
• 协议层可以独立升级；
• 新增功能不会影响已有模块；
• 后续维护成本大幅降低。

对于 SDK 来说，边界比功能更重要。

---

一个接口，背后可能隐藏着很多逻辑

业务层最终只需要这样调用：

cameraService.start();

但底层实际上已经完成了：

• USB 权限检测；
• 设备识别；
• PTP Session 建立；
• 新照片监听；
• 自动下载；
• 异常恢复；
• 上传队列初始化。

业务开发几乎不用关心这些复杂细节。

这也是 SDK 存在的意义。

---

真正耗时间的不是写代码

很多朋友问我：

开发周期是不是都花在协议上？

其实并不是。

真正耗时间的是：

• 多品牌兼容；
• 生命周期管理；
• 自动重连；
• 队列调度；
• 日志排查；
• 长时间稳定运行测试。

这些内容，网上几乎没有现成答案。

也是商业项目和学习 Demo 最大的区别。

---

做完项目后，我最大的感受

以前我觉得：

SDK 就是一堆 API。

后来才发现：

SDK 更像是一套"隐藏复杂度"的能力。

调用的人越简单。

底层做得越复杂。

真正优秀的 SDK，不是功能最多，而是让业务开发几乎感觉不到它的存在。