SDK开发最佳实践：架构设计与质量保障 #
SDK开发是一项复杂而富有挑战性的工作，需要在架构设计、接口易用性、质量保障等多个维度进行权衡。本文将基于实际开发经验，深入探讨如何构建一个优秀的SDK。 自从毕业之后，好像我一直都在做 SDK 相关的开发工作，但做了这么长时间貌似也没正经复盘一次。
最近有一些思考：
- 什么样的 SDK 才能称之为一个好的 SDK？
- 怎么才能做出一个好的 SDK？
- 怎么才能做好一个项目？
下面是我的粗浅看法：
- 接口简单易用：用户可以快速方便的接入，在确保提供相应能力的前提下，对外暴露的接口越少越简单越好。接口越多，用户接入的复杂性就越高，出 bug 的概率就越大。
- 接入的第三方库要做成插件化：一个 SDK 想要获取某些能力不可避免的要接入一些三方库。这里一定要做好隔离，实现同样的功能，可以灵活替换其他同类型的三方库。功能侧做好 mock，当发生某一问题时（比如 CPU 占用率高、难以排查的内存泄漏等），可以灵活去掉某个三方库，缩小复现路径，方便定位问题。
- 完备的日志：关键函数调用一定要有 log，可以在调试某个不容易复现的问题时打印完整的调用路径，方便定位问题，其实最好能有一个全链路追踪方案。这种方案也是我一直想要做的，但苦于到现在还没有找到合适的实现方法。
- 参数可配置：很多参数不要写死，最好做成可配置的。
- 要有监控手段：比如内存、CPU 占用率、帧率等的监控。保证质量第一，质量问题要量化，确定好什么指标才算是高质量 SDK。
- 线上出问题后可定位：这一般取决于 SDK 的 log 覆盖程度，以及开发人员的调试能力和经验。
其实这和开发一个好的项目类似，下面是我一些粗浅的想法：
- 整个项目代码风格统一：在项目启动前确定代码规范，C++ 的话一般都是参考的 Google 的编码规范。项目的编译环境、设计风格也要统一，比如消息传递方式、模块如何调用方通知错误、软件如何向用户通知错误、如何组织数据结构、模块间通信机制等。
- 想清楚：不用着急动手，写代码之前一定要想清楚。开发一个 SDK 之前要设计好整个架构，这可能会设计出多种架构，最好都能给出架构图，然后说明每个架构的优缺点。从中选择最合适的架构，想清楚自己的取舍，为什么选择了这个，而非其他。
- 文档先行：这里不要求文档格式，先制定方案，核心诉求是想清楚之后再开发。重要核心功能最好拉上组内核心成员 review，尽可能对方案做进一步优化。
- 方便扩展：这其实还是涉及到 SDK 的架构问题，我见到过很多扩展性非常差的 SDK，迭代需求非常困难，牵一发而动全身。想要做好扩展性，我想更多的还是要知道 SDK 的发展方向，只有预测到将来会有什么需求才能更好的设计架构。当然，也没必要过度设计，架构都是一点点演进的，没有一步到位的架构。其实只要合理定义好模块，抽象好接口，SDK 的扩展性还是大体可以保证的。
- 接口设计：做好接口的抽象与设计，让用户没有错误调用的机会。比如你的参数类型是 enum class，用户想传错参数都不可能，编译就会报错。
- 模块划分清晰：模块边界要清晰，尽量减少模块之间的耦合度，确定好每个模块的输入和输出，做好团队协作与沟通，每个模块划分责任人，确定时间点。
- 测试先行：这是基本的编程原则啦，但貌似真正做到的也没几个，我在这块做的也不好…但还是要说一说，写代码之前要提前想好测试方案，不要一口气写完一大块代码，要一边写代码一边测试，真正出现问题时也更好定位。
- 做好质量的监控与保障：
- CPU 占用
- GPU 占用
- 内部状态
- 内存
- 帧率
- 型号
- 错误和崩溃信息
- 画面评估：
- 声音是否卡顿
- 音画是否同步
- 是否有回声
- 要有监控的手段，比如音视频 SDK 中一些常见的指标：
- 做好自动化测试，测试的代码覆盖率要超过 90%
- 跨平台：SDK 最好做成跨平台的，拿我常做的移动端 SDK 来说，一般要求移动端 SDK 要支持双端，即 Android 和 iOS。所以一般都会使用双端都支持的 Native 语言开发，即 C/C++。
- 因为把所有业务逻辑都沉到底层，用一套语言实现，这样在后期需求迭代和维护时可以只使用一份人力，如果使用双端上层 Android 和 OC 语言开发，同一套需求需要使用双倍人力，而且双端效果可能还不一致，排期也可能不一致，bug 数也可能不一致。可能会影响整个 SDK 的交付进度。
- 为什么不使用平台相关的语言，而使用 Native 开发？
- 这里可能大家会有些问题，比如某些功能只能使用上层语言开发，比如 Android 的 Camera 和 MediaCodec，iOS 的 AVCaptureSession 和 VideoToolBox 等，这怎么办？
- 这里要按功能做好抽象，拿录制来说，只需要提供开启录制、停止录制的接口即可，内部谁管你怎么实现呢。可以设计成同一个头文件，然后把平台差异化隐藏在实现中，使用条件编译的方式选择编译某个平台下的源文件。
- 三方库接入：要确保做好封装，做到模块化、可复用、可插拔。比如 setBeautify、setFilter、setSticker 等。
如何才能做好一个项目？
我认为做好一个项目的前提是人，要有合适的人，其次还是要规范好流程。
然后还有一位前辈给我发的开源项目邮件里说了一些他的看法，我感觉非常不错，这里也贴出来给大家看看：
- 希望有完备而用心的 UT，追求 100% 逻辑覆盖率，UT 维护良好，短小易读
- 子系统解耦良好，各模块相对独立，以标准化 IO 接口，通过项目基础库进行通讯，能独立更新迭代，独立进行测试
- 不需要过多的 smoke test
- 子系统通讯和管理所经由的基础库希望由技术过硬的大佬写，希望跨平台，而且可读性高
- 数据链路有类似 kernel 的各种数据统计，数据统计不应耦合于业务，而是有数据统计子系统，高度解耦的方式
- 使用好的 log，多线程库，数据解析库，通讯库，而不是自己写
- 迅捷的编译，提交任何代码都需要门禁，快速的跑全量 UT 与 smoke
- 每日 daily 自动化跑全量 UT 与 smoke,weekly 性能测试；自动化测试跑出来的 bug 可以自动建立并根据模块自动分派给个人
- 希望使用比较新一点的技术栈