相比于APP的开发，SDK的开发有些不同：
1、拓展性要求更高：SDK需要对外提供接口，无论是迭代还是重构，原有接口都不能变更，否则会对SDK使用者带来兼容、维护成本；
2、质量要求更高：SDK可能在各种业务场景中使用，使用情况复杂；且如果有质量问题时每个SDK使用方都需要升级，所以发布的SDK版本一定要是高质量的版本；
3、测试难度更大：SDK很多时候只有接口没有界面，对于测试来讲既是黑盒、又不确定SDK使用者怎么调用，即使测试时没问题也很难保证在业务中使用时没有问题。
对于1已有成熟的解决方案，有新需求或需求变动，新增接口并让原接口过时即可。下面结合我实际负责SDK开发的经历，谈一谈2和3，即如何保障SDK的开发质量：
一、评审环节：
评审环节最为重要的是在满足当前需求之外，还要基于对业务的理解，洞察可能的潜在需求，基于对需求的理解和洞察，设计接口和。尽可能在SDK设计时就考虑到需求可能的变更情况，设计出职责明确、兼容性强的接口，避免因为需求变更导致接口的改动。比如下载接口的设计，一次可以添加一个下载任务，也可能有一次性添加多个下载任务的需求。
除此之外，还需要为SDK制定版本号（在代码中写明版本，而非在SDK名字上体现）和一套错误码，便于在SDK出问题时能够快速定位问题。
SDK设计完成后，需要要求APP需求方的开发人员一起参与评审，主要评审接口设计的合理性和易用性，确保达成一致后才进入开发环节。
二、开发环节：
因为SDK的特殊性，质量保障不能强依赖测试，既然SDK不好测，那就想办法让开发出来的SDK质量有保障、通过开发端提供测试工具简化测试的工作。
靠谱的解决方案是为SDK开发Demo，Demo中演示每个接口的调用方式，并提供测试模式，用于对接口的性能、安全性等测试。通过Demo既引导了APP开发人员尽可能按预期的方式使用接口，又为测试人员提供了方便，通过测试模式可以对各接口做性能、安全等专项，专项验证SDK的质量。如果SDK存在需要长时间运行等可能导致功耗问题的情况，需要通过多渠道打包生成多个Demo，通过专项验证同时运行对整机性能的影响。
为了便于开发者使用，为SDK写ReadMe，介绍接口的使用方法、使用流程是必不可少的。
三、发布环节：
SDK的发布可以借鉴APP的发布流程，先和需求方拿一个APP联调，集成进APP灰度验证SDK的质量，如果质量OK再全量。
四、维护环节：
为SDK设计一套单独的异常采集方案，将SDK和APP的异常分开，避免因为SDK集成到APP中无法单独统计SDK的异常率，通过统计SDK的异常率来衡量SDK的质量。
刚开始接手SDK开发时情况是比较糟糕的，发布SDK版本时总是心惊胆战，市场反馈有APP的问题时，经常听到APP开发人员反馈这是SDK的问题。通过将上面的做法融入到流程和规范中，并不定期抽查团队成员对流程和规范的遵守情况约束团队遵守规范。现在几乎很难遇到之前那样的情况了，一年下来因为SDK导致的严重问题最多有1-2次，SDK的异常率远低于APP的异常率。
上述的总结只讲了在开发过程中有真正实践过的方法，并非完美方案，像通过单元测试保障SDK接口的稳定性、通过热更新实现SDK补丁的动态更新都是有效保障SDK开发质量的方法。
下面是对这篇文章的总结：
1、SDK相比于APP，需要更为注重开发质量；
2、保障SDK开发质量的方法有：为SDK开发测试模式、输出SDK使用Demo和说明文档、对SDK做专项测试、先灰度再全量、对SDK做异常采集；
3、SDK的开发，永远是质量第一、效率第二。严格遵守流程和规范，只有这样，才不会陷入被使用方质疑的境况，才有机会始终以实现新增需求而非维护为主。
