如何写一个可用的SDK？

有些第三方平台的SDK有点儿难用，大概很多人都有过这样的感慨。

如果是你来写，怎么写出一个别人觉得可以用的SDK？

从使用者的角度，SDK要遵循组件封装的一些基本要求：

1. 稳定性
2. 易用性
3. 灵活性

稳定性

稳定性是基础要求。你能接受一个动不动会触发Crash的组件库吗？不可能的。稳定性压倒一切——这句话怎么这么熟悉。组件再重要，可不能影响主要业务的运行。

如何保证稳定性？

从源头上说，肯定是先得保证代码质量。如果能维护一份“SDK开发设计文档”，那更好不过了——当然你得知道，90%的维护者是不会看你这个的，除非出了问题。请坚持保持清晰的代码结构、入参检查、错误/异常处理，这些都是提高代码质量的通用之道。然后，是的，每一个项目都会经过众多维护者的“洗礼”，SDK也不例外。在SDK迭代过程中，要保证后续开发者能准确理解SDK的设计思路。保持一致的代码风格尤其重要——即使你认为你创造的模式更好，也不要混杂多种代码风格/模式。除非推倒重来。记录SDK开发/发布日志。“设计文档”不常有，但发布日志可以有。记录项目的更新内容，对问题排查检查是一个有效工具。

从输出来说，需要保证产品的质量——SDK是平台方向它的用户提供的产品。发布前经过QA的测试与质量检查是必不可少的。另外，对功能模块进行单元测试，也能保证迭代过程中，不会意外导致功能异常。

一些具体的check list：

• 兼容测试：不同系统版本、机型设备的兼容问题。新出的系统API，请务必检查API的可用性。
• 覆盖测试：缓存问题是日常出bug的主力。请检查覆盖安装的情况下，是否存在异常。
• 帐号切换测试：缓存问题。

易用性

简单而言，就是直观、易上手。这个就涉及开发者的设计能力了。有一些常见的指标，让我们回答几个问题：
1、接口优雅吗？
接口优雅，则产品的使用体验是极大提升的。首先一点，接口尽量要所见即所得，参数类型必须是明确的。其次，可以考虑使用者的接口调用场景，提供替代方案。

2、细节隐藏了吗？
配置项请尽量简化。合理使用默认参数。使用者无关的参数不需要暴露。
可以考虑将常用的配置项打包成一个选项，Builder模式。

3、内部重试机制？
内部维护的参数请内部保证可用性。内部流程失败，应该设定重试机制。
这里有一个很新鲜的例子：我司有维护了一个SDK，封装了微信授权、拉取用户信息并映射到公司用户系统的功能。该SDK会在SDK初始化时，向服务器登记并获取一个设备ID，并且该ID在后续的所有接口调用中都会使用到。结果在某些产品更新微信登录流程时，出现了SDK初始化设备ID失败的情况，而SDK内部没有重试机制，效果可想而知。大多数情况SDK初始化只会进行一次、调用方不会重复初始化SDK，几乎是常识性的错误。

4、API稳定吗
API接口声明请保持稳定。动不动只能改API来适配新需求，是一种可耻的行为。

5、接入方便吗？
准备了demo了吗？README能按条理写明白主要功能了吗？现在CocoaPods创建个组件库都十分方便了，能简化项目的接入成本又何乐不为呢。

灵活性

SDK面对的开发场景复杂，应当提供一定的灵活性，满足开发需要。

调试日志。调试日志对开发者很重要，SDK应该支持输出一定的日志，至少保证错误日志。如果能提供日志格式化器、控制日志输出级别则更好。

减少依赖项。尽量避免依赖外部项目。一些稳定并且持续跟进维护的可以考虑引入，建议谨慎，如果只为了一点工具就引入整个第三方库，不值得。引入第三方库需要进行符号重命名，mangling。

降低模块耦合度。