其實(shí)很簡單，SDK 就是 Software Development Kit 的縮寫，中文意思就是“軟件開發(fā)工具包”。

這是一個(gè)覆蓋面相當(dāng)廣泛的名詞，可以這么說：輔助開發(fā)某一類軟件的相關(guān)文檔、范例和工具的集合都可以叫做“SDK”。具體到我們這個(gè)系列教程，我們后面只討論廣義 SDK 的一個(gè)子集——即開發(fā) Windows 平臺(tái)下的應(yīng)用程序所使用的 SDK。

呵呵，其實(shí)上面只是說了一個(gè) SDK 大概的概念而已，理解什么是 SDK 真有這么容易嗎？

恐怕沒這么簡單！為了解釋什么是 SDK 我們不得不引入 API、動(dòng)態(tài)鏈接庫、導(dǎo)入庫等等概念。^_^，不要怕，也就是幾個(gè)新的名詞而已，其實(shí)學(xué)習(xí)新知識(shí)就是在學(xué)習(xí)新名詞、新概念和新術(shù)語。

首先要接觸的是“API”，也就是 Application Programming Interface，其實(shí)就是操作系統(tǒng)留給應(yīng)用程序的一個(gè)調(diào)用接口，應(yīng)用程序通過調(diào)用操作系統(tǒng)的 API 而使操作系統(tǒng)去執(zhí)行應(yīng)用程序的命令（動(dòng)作）。其實(shí)早在 DOS 時(shí)代就有 API 的概念，只不過那個(gè)時(shí)候的 API 是以中斷調(diào)用的形式（INT 21h）提供的，在 DOS 下跑的應(yīng)用程序都直接或間接的通過中斷調(diào)用來使用操作系統(tǒng)功能，比如將 AH 置為 30h 后調(diào)用 INT 21h 就可以得到 DOS 操作系統(tǒng)的版本號(hào)。而在 Windows 中，系統(tǒng) API 是以函數(shù)調(diào)用的方式提供的。同樣是取得操作系統(tǒng)的版本號(hào)，在 Windows 中你所要做的就是調(diào)用 GetVersionEx() 函數(shù)。可以這么說，DOS API 是“Thinking in 匯編語言”的，而 Windows API 則是“Thinking in 高級(jí)語言”的。DOS API 是系統(tǒng)程序的一部分，他們與系統(tǒng)一同被載入內(nèi)存并且可以通過中斷矢量表找到他們的入口，那么 Windows API 呢？要說明白這個(gè)問題就不得不引入我們下面要介紹得這個(gè)概念——DLL。

DLL（又是一個(gè)縮寫，感覺 IT 這個(gè)行業(yè)里三字頭縮寫特別多），即 Dynamic Link Library（動(dòng)態(tài)鏈接庫）。我們經(jīng)常會(huì)看到一些 .dll 格式的文件，這些文件就是動(dòng)態(tài)鏈接庫文件，其實(shí)也是一種可執(zhí)行文件格式。跟 .exe 文件不同的是，.dll 文件不能直接執(zhí)行，他們通常由 .exe 在執(zhí)行時(shí)裝入，內(nèi)含有一些資源以及可執(zhí)行代碼等。其實(shí) Windows 的三大模塊就是以 DLL 的形式提供的（Kernel32.dll，User32.dll，GDI32.dll），里面就含有了 API 函數(shù)的執(zhí)行代碼。為了使用 DLL 中的 API 函數(shù)，我們必須要有 API 函數(shù)的聲明（.H）和其導(dǎo)入庫（.LIB），函數(shù)的原型聲明不難理解，那么導(dǎo)入庫又是做什么用的呢？我們暫時(shí)先這樣理解：導(dǎo)入庫是為了在 DLL 中找到 API 的入口點(diǎn)而使用的。

所以，為了使用 API 函數(shù)，我們就要有跟 API 所對(duì)應(yīng)的 .H 和 .LIB 文件，而 SDK 正是提供了一整套開發(fā) Windows 應(yīng)用程序所需的相關(guān)文件、范例和工具的“工具包”。到此為止，我們才真正的解釋清楚了 SDK 的含義。

由于 SDK 包含了使用 API 的必需資料，所以人們也常把僅使用 API 來編寫 Windows 應(yīng)用程序的開發(fā)方式叫做“SDK 編程”。而 API 和 SDK 是開發(fā) Windows 應(yīng)用程序所必需的東西，所以其它編程框架和類庫都是建立在它們之上的，比如 VCL 和 MFC，雖然他們比起“SDK 編程”來有著更高的抽象度，但這絲毫不妨礙它們?cè)谛枰臅r(shí)候隨時(shí)直接調(diào)用 API 函數(shù)。

開發(fā)SDK時(shí)需要注意的問題

1.修改類別文件名及類別方法。

開發(fā)ＳＤＫ時(shí)通常會(huì)用到比較多的第三方的類別方法， 這樣的話， 開發(fā)者在使用你的ＳＤＫ時(shí)， 因?yàn)樗赡芤矔?huì)加一些第三方的開源庫， 比如都使用了NSString的md5類別文件。由于這兩個(gè)文件都是從網(wǎng)上下載來下的， 所以文件名是一樣的。這樣在編譯時(shí)就會(huì)報(bào)錯(cuò)。然后就想到要去修改這個(gè)類別文件名， 等修改類別文件名后。發(fā)現(xiàn)類別中的方法名是一樣的， 而iOS在調(diào)用兩個(gè)相同方法的類別方法時(shí)， 不能確定其調(diào)用的哪個(gè)方法， 但可以肯定地是只會(huì)調(diào)用一個(gè)類別方法， 如果恰好開發(fā)者自己又修改了這個(gè)類別方法， 那就有問題了。

所以在ＳＤＫ開發(fā)過程中， 需要修改引入進(jìn)來的類名， 及方法名， 建議添加項(xiàng)目前綴， 最好是三個(gè)字母的， 如ＮＡＢ， （兩個(gè)字母為蘋果自己保留使用）

2.在開發(fā)ＳＤＫ時(shí)， 如果發(fā)現(xiàn)某個(gè)方法命名時(shí)比較困難， 那么幾乎可以肯定的是， 這個(gè)方法藕合度太高，需要再次進(jìn)行分解。

3.開發(fā)ＳＤＫ時(shí)， 需要考慮到升級(jí)的問題， 并且可以指定某些版本必須強(qiáng)制升級(jí)。（以防某些版本到后期發(fā)現(xiàn)有明顯問題， 需要及時(shí)替換）

4.開發(fā)ＳＤＫ時(shí)， 需要留出一個(gè)接口， 能通過后臺(tái)服務(wù)器強(qiáng)制關(guān)閉掉某個(gè)接入應(yīng)用的調(diào)用。（這可能會(huì)發(fā)生在惡意地攻擊行為， 以及非惡意地使用行為，如某應(yīng)用頻繁自動(dòng)重啟事故，每次重啟都會(huì)調(diào)用咱們的ＳＤＫ，然后就會(huì)使得咱們的ＳＤＫ服務(wù)器壓力陡增）， 這個(gè)時(shí)候， 如果后臺(tái)能根據(jù)這個(gè)應(yīng)用的ＡＰＰ ＩＤ啥的， 強(qiáng)制關(guān)閉它發(fā)的請(qǐng)求，或者屏掉他的請(qǐng)求， 你會(huì)發(fā)現(xiàn)世界如此美好。

5.統(tǒng)計(jì)方面， ＳＤＫ存儲(chǔ)每個(gè)接口調(diào)用的次數(shù)，以在一定的情況下發(fā)送給服務(wù)器， 便于后期分析某些接口是否有問題，或者是根本就沒有用戶使用的情況。

6.有些ＳＤＫ使用的前提條件，最好是在編譯期就提示給用戶，而不是在運(yùn)行期， 可以使用類似下面代碼來進(jìn)行提示

#warning - Release scheme, this is not work.

#if !__has_feature(objc_arc)

#error iBeaconSDK requires automatic reference counting

#endif

更好地構(gòu)建SDK

1. 了解墻外的世界，把握好需求

試著去關(guān)注你的競爭對(duì)手或者與你相似領(lǐng)域的公司都做了什么。這可能會(huì)給你一些參考的角度。采納你喜歡的地方，改善你不喜歡的地方。

2. 簡潔

代碼簡潔——簡潔的代碼意味著你的客戶用起來得心應(yīng)手。這可能包括盡可能減少與代碼交互的方式，比如只公開一個(gè)接口類；或是簡短的方法簽名，比如少量的輸入參數(shù)，等等。

除了初始化階段（只發(fā)生一次且可能要求進(jìn)行配置），請(qǐng)讓SDK方法使用起來盡可能簡單。

同樣地，請(qǐng)盡量減少方法簽名中的參數(shù)。

你可以通過提供默認(rèn)配置以及允許高級(jí)用戶進(jìn)行覆蓋的默認(rèn)實(shí)現(xiàn)類來達(dá)到這一目的。

隱藏用戶不需要使用的類和方法，比如，只將用戶必須使用的類/方法設(shè)定為公有的，否則就將它們的使用范圍設(shè)定為局部或者私有。一個(gè) IDEs 提供了代碼檢查與清除功能，可以幫你自動(dòng)實(shí)現(xiàn)這一點(diǎn)。

參考文檔簡潔——讓你的文檔盡可能簡單易懂。這意味著有時(shí)候你得多寫注釋，有時(shí)候又得盡量少寫。內(nèi)聯(lián)樣本代碼通常很有幫助，因?yàn)榇蠖鄶?shù)人都是通過例子來學(xué)習(xí)的。

3. 提供簡單的開始步驟

這是指一個(gè)人可以在五分鐘內(nèi)上手使用你的代碼。這一點(diǎn)非常重要，因?yàn)榭蛻敉ＭM可能不費(fèi)力地進(jìn)行集成。除此之外，有時(shí)候客戶想要評(píng)估你的產(chǎn)品，但如果無法進(jìn)行簡單的測試，他們就很可能選擇跳過你的產(chǎn)品。

4. 短小精悍

保持簡短主要是文檔的責(zé)任，但是同樣與用戶和SDK代碼的交互方式有關(guān)；為了保持文檔的簡短，可以提供代碼樣例、一目了然的方法名或使用默認(rèn)數(shù)據(jù)來實(shí)現(xiàn)。

5. 集成

請(qǐng)謹(jǐn)記客戶開發(fā)環(huán)境的多樣性。

比如說，如果你在寫一個(gè)安卓庫，它的集成方式在客戶使用Android Studio加gradle 框架和使用Eclipse集成開發(fā)環(huán)境時(shí)就非常不同。前者需要aar工件并發(fā)布到遠(yuǎn)程存儲(chǔ)庫中，而后者需要你提供jar文件，以及關(guān)于如何為SDK更改AndroidManifext.xml文件和獨(dú)立eclipse項(xiàng)目的指導(dǎo)。

這可能會(huì)影響你的構(gòu)建機(jī)制及其工件。然而，不要試圖取悅所有客戶，請(qǐng)先滿足你的第一位客戶，或者預(yù)期中的大多數(shù)客戶的需求。

6. 項(xiàng)目示例

在GitHub上創(chuàng)建一個(gè)最基本的項(xiàng)目，模擬使用SDK包的用戶。

這可以向客戶展示你的產(chǎn)品如何滿足他們的需求，以及如何集成你的產(chǎn)品。如果你想展示高級(jí)用法，那就在另一個(gè)項(xiàng)目里進(jìn)行展示。通常，客戶會(huì)將項(xiàng)目示例作為主要的參考文檔，因此，請(qǐng)?zhí)峁┬袃?nèi)評(píng)論，并盡量用一目了然的方式書寫代碼。

7. 概述

在參考文檔的開頭，或是GitHub項(xiàng)目的README.md文件中，請(qǐng)用直白的語言對(duì)你的解決方案進(jìn)行概述。在此部分，筆者通常會(huì)提供一個(gè)使用樣例來解釋SDK的典型用法。如果有可能，請(qǐng)?zhí)峁┮粋€(gè)簡單的表格或是圖表，這樣一來，不喜歡閱讀操作指南的用戶也可以快速了解該SDK的優(yōu)勢(shì)。

8. 初始化

使用在SDK域內(nèi)可接受的慣例。

這些慣例可能是可重載的構(gòu)造函數(shù)，某種構(gòu)建模式等。初始化應(yīng)當(dāng)巧妙地使用默認(rèn)值來簡化流程。

9. 默認(rèn)值

默認(rèn)值對(duì)于保持代碼的簡潔性和減少配置過程（見簡潔性部分）是非常重要的。你所提供的默認(rèn)值（不管是在配置還是實(shí)施過程）應(yīng)該代表在你眼中大多數(shù)SDK用戶會(huì)進(jìn)行的操作。

編輯：黃飛