這段時間接手了**魔盒的支付模塊和供三方應用調用的支付SDK模塊，這才發(fā)現SDK開發(fā)跟應用版本開發(fā)的理念不太相同。無線應用產品，版本更新越快越新可能就越開心，說明業(yè)務以及產品在不斷發(fā)展、優(yōu)化和改進；然而對于SDK來說，發(fā)布新版本的心情卻是復雜的，開心又心塞... ... 開心的是有新功能，但是更多的是多版本維護帶來的各種壓力和成本，SDK一個版本的生命周期不可能像應用那么短，而且它帶來的問題影響也會更加長久，接入方不可能輕易更換SDK版本，新功能要考慮到使用舊版SDK應用的適配性，因此要更加謹慎和慎重。
總的說來，一個好的SDK需要具備以下三個特性：
一、輕便且易擴展的SDK API
接入API一定要簡單！要簡單！要簡單！重要的事情說三遍！對于SDK的客戶端開發(fā)，雖然你可以任性地在不同版本隨意的優(yōu)化入參以及調用方式并且不會招致什么大問題。但是這對于接入SDK的開發(fā)來說，絕對是噩夢一般的存在。理想的SDK接入過程一定是非常“順滑”的，哪怕不開文檔只看接口，也能順利接入，這才是一個設計良好的SDK。反之當SDK接入、更新的成本超過甚至逼近開發(fā)直接對接的成本時，這個SDK其實是失敗的，而且也失去了應有的意義。
SDK也是一個產品，但是又有其特殊性：API一般說來要有一定的持久性和穩(wěn)定性，因此需要在設計初期考慮到產品后期的業(yè)務發(fā)展趨勢，提前留好接口的相關業(yè)務擴展參數。
二、已接入應用適配問題
保證已接入應用適配問題的關鍵在于兩點：一個是極簡集成、一個是分層設計。極簡集成顧名思義就是把SDK做薄，只做最基本的業(yè)務參數傳遞和通道建立；分層設計則將SDK和業(yè)務核心模塊區(qū)分了開來，這樣可以讓核心業(yè)務不受SDK版本的限制。
我所負責的**魔盒支付模塊基本架構如下圖所示：
采用這樣的架構模式，業(yè)務方只需要在引入SDK jar包后加入短短幾行代碼，就可以把支付功能托付給支付核心模塊來做，在不改變API的情況下，底層業(yè)務的更新可以直接供上層使用，無須再次接入新的SDK。
三、穩(wěn)定性保障
SDK以及相關核心業(yè)務的穩(wěn)定性也是至關重要，主要需要關注以下幾點：
1、安全機制；
2、線程管理；
3、用戶界面友好性；
4、內存使用情況；
5、CPU占用情況。
最后就是SDK的版本控制，個人覺得最好的版本狀態(tài)是有三條分支：穩(wěn)定版、開發(fā)版以及定制版。穩(wěn)定版用于大面積的推廣；開發(fā)版用于一些急于使用新功能的應用試用。穩(wěn)定版本和開發(fā)版本的存在是為了提高SDK的版本質量，同時結合版本發(fā)布的一些策略，降低SDK版本質量對使用者的影響以及SDK的bug的影響范圍。
