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

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

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

恐怕沒這么簡單！為了解釋什么是 SDK 我們不得不引入 API、動態鏈接庫、導入庫等等概念。^_^，不要怕，也就是幾個新的名詞而已，其實學習新知識就是在學習新名詞、新概念和新術語。

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

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

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

由于 SDK 包含了使用 API 的必需資料，所以人們也常把僅使用 API 來編寫 Windows 應用程序的開發方式叫做“SDK 編程”。而 API 和 SDK 是開發 Windows 應用程序所必需的東西，所以其它編程框架和類庫都是建立在它們之上的，比如 VCL 和 MFC，雖然他們比起“SDK 編程”來有著更高的抽象度，但這絲毫不妨礙它們在需要的時候隨時直接調用 API 函數。

開發SDK時需要注意的問題

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

開發ＳＤＫ時通常會用到比較多的第三方的類別方法， 這樣的話， 開發者在使用你的ＳＤＫ時， 因為他可能也會加一些第三方的開源庫， 比如都使用了NSString的md5類別文件。 由于這兩個文件都是從網上下載來下的， 所以文件名是一樣的。 這樣在編譯時就會報錯。 然后就想到要去修改這個類別文件名， 等修改類別文件名后。 發現類別中的方法名是一樣的， 而iOS在調用兩個相同方法的類別方法時， 不能確定其調用的哪個方法， 但可以肯定地是只會調用一個類別方法， 如果恰好開發者自己又修改了這個類別方法， 那就有問題了。

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

2.在開發ＳＤＫ時， 如果發現某個方法命名時比較困難， 那么幾乎可以肯定的是， 這個方法藕合度太高，需要再次進行分解。

3.開發ＳＤＫ時， 需要考慮到升級的問題， 并且可以指定某些版本必須強制升級。 （以防某些版本到后期發現有明顯問題， 需要及時替換）

4.開發ＳＤＫ時， 需要留出一個接口， 能通過后臺服務器強制關閉掉某個接入應用的調用。 （這可能會發生在惡意地攻擊行為， 以及非惡意地使用行為，如某應用頻繁自動重啟事故，每次重啟都會調用咱們的ＳＤＫ，然后就會使得咱們的ＳＤＫ服務器壓力陡增）， 這個時候， 如果后臺能根據這個應用的ＡＰＰ ＩＤ啥的， 強制關閉它發的請求，或者屏掉他的請求， 你會發現世界如此美好。

5.統計方面， ＳＤＫ存儲每個接口調用的次數，以在一定的情況下發送給服務器， 便于后期分析某些接口是否有問題，或者是根本就沒有用戶使用的情況。

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

#warning - Release scheme, this is not work.

#if !__has_feature(objc_arc)

#error iBeaconSDK requires automatic reference counting

#endif

更好地構建SDK

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

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

2. 簡潔

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

除了初始化階段（只發生一次且可能要求進行配置），請讓SDK方法使用起來盡可能簡單。

同樣地，請盡量減少方法簽名中的參數。

你可以通過提供默認配置以及允許高級用戶進行覆蓋的默認實現類來達到這一目的。

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

參考文檔簡潔——讓你的文檔盡可能簡單易懂。這意味著有時候你得多寫注釋，有時候又得盡量少寫。內聯樣本代碼通常很有幫助，因為大多數人都是通過例子來學習的。

3. 提供簡單的開始步驟

這是指一個人可以在五分鐘內上手使用你的代碼。這一點非常重要，因為客戶往往希望盡可能不費力地進行集成。除此之外，有時候客戶想要評估你的產品，但如果無法進行簡單的測試，他們就很可能選擇跳過你的產品。

4. 短小精悍

保持簡短主要是文檔的責任，但是同樣與用戶和SDK代碼的交互方式有關；為了保持文檔的簡短，可以提供代碼樣例、一目了然的方法名或使用默認數據來實現。

5. 集成

請謹記客戶開發環境的多樣性。

比如說，如果你在寫一個安卓庫，它的集成方式在客戶使用AndroidStudio加gradle 框架和使用Eclipse集成開發環境時就非常不同。前者需要aar工件并發布到遠程存儲庫中，而后者需要你提供jar文件，以及關于如何為SDK更改AndroidManifext.xml文件和獨立eclipse項目的指導。

這可能會影響你的構建機制及其工件。然而，不要試圖取悅所有客戶，請先滿足你的第一位客戶，或者預期中的大多數客戶的需求。

6. 項目示例

在GitHub上創建一個最基本的項目，模擬使用SDK包的用戶。

這可以向客戶展示你的產品如何滿足他們的需求，以及如何集成你的產品。如果你想展示高級用法，那就在另一個項目里進行展示。通常，客戶會將項目示例作為主要的參考文檔，因此，請提供行內評論，并盡量用一目了然的方式書寫代碼。

7. 概述

在參考文檔的開頭，或是GitHub項目的README.md文件中，請用直白的語言對你的解決方案進行概述。在此部分，筆者通常會提供一個使用樣例來解釋SDK的典型用法。如果有可能，請提供一個簡單的表格或是圖表，這樣一來，不喜歡閱讀操作指南的用戶也可以快速了解該SDK的優勢。

8. 初始化

使用在SDK域內可接受的慣例。

這些慣例可能是可重載的構造函數，某種構建模式等。初始化應當巧妙地使用默認值來簡化流程。

9. 默認值

默認值對于保持代碼的簡潔性和減少配置過程（見簡潔性部分）是非常重要的。你所提供的默認值（不管是在配置還是實施過程）應該代表在你眼中大多數SDK用戶會進行的操作。

審核編輯 ：李倩