这段时间接手了**魔盒的支付模块和供三方应用调用的支付SDK模块，这才发现SDK开发跟应用版本开发的理念不太相同。无线应用产品，版本更新越快越新可能就越开心，说明业务以及产品在不断发展、优化和改进；然而对于SDK来说，发布新版本的心情却是复杂的，开心又心塞... ... 开心的是有新功能，但是更多的是多版本维护带来的各种压力和成本，SDK一个版本的生命周期不可能像应用那么短，而且它带来的问题影响也会更加长久，接入方不可能轻易更换SDK版本，新功能要考虑到使用旧版SDK应用的适配性，因此要更加谨慎和慎重。
总的说来，一个好的SDK需要具备以下三个特性：
一、轻便且易扩展的SDK API
接入API一定要简单！要简单！要简单！重要的事情说三遍！对于SDK的客户端开发，虽然你可以任性地在不同版本随意的优化入参以及调用方式并且不会招致什么大问题。但是这对于接入SDK的开发来说，绝对是噩梦一般的存在。理想的SDK接入过程一定是非常“顺滑”的，哪怕不开文档只看接口，也能顺利接入，这才是一个设计良好的SDK。反之当SDK接入、更新的成本超过甚至逼近开发直接对接的成本时，这个SDK其实是失败的，而且也失去了应有的意义。
SDK也是一个产品，但是又有其特殊性：API一般说来要有一定的持久性和稳定性，因此需要在设计初期考虑到产品后期的业务发展趋势，提前留好接口的相关业务扩展参数。
二、已接入应用适配问题
保证已接入应用适配问题的关键在于两点：一个是极简集成、一个是分层设计。极简集成顾名思义就是把SDK做薄，只做最基本的业务参数传递和通道建立；分层设计则将SDK和业务核心模块区分了开来，这样可以让核心业务不受SDK版本的限制。
我所负责的**魔盒支付模块基本架构如下图所示：
采用这样的架构模式，业务方只需要在引入SDK jar包后加入短短几行代码，就可以把支付功能托付给支付核心模块来做，在不改变API的情况下，底层业务的更新可以直接供上层使用，无须再次接入新的SDK。
三、稳定性保障
SDK以及相关核心业务的稳定性也是至关重要，主要需要关注以下几点：
1、安全机制；
2、线程管理；
3、用户界面友好性；
4、内存使用情况；
5、CPU占用情况。
最后就是SDK的版本控制，个人觉得最好的版本状态是有三条分支：稳定版、开发版以及定制版。稳定版用于大面积的推广；开发版用于一些急于使用新功能的应用试用。稳定版本和开发版本的存在是为了提高SDK的版本质量，同时结合版本发布的一些策略，降低SDK版本质量对使用者的影响以及SDK的bug的影响范围。
