1. 前言
從事 SDK 的研發工作有近兩年的工作時間了，期間一直在維護和開發公司的 Android 資料採集埋點 SDK。主要想通過這篇總結簡要介紹下 SDK 開發過程中的一些經驗。
1.1 什麼是 SDK
相信做 Android 開發的同學，肯定使用過很多第三方的 SDK，比如極光 SDK、支付寶 SDK、微博 SDK 等等。所謂 SDK 就是一個開發工具包，全稱是 Software Development Kit，翻譯過來是軟體開發工具包。SDK 通常是為輔助開發某類軟體而編寫的特定軟體包。
App 開發與 SDK 開發的工作有什麼區別呢？App 開發更偏向於使用者層面，從 UI 展示到業務邏輯處理，全程處理使用者的行為。而 SDK 開發更偏向於功能方面，注重功能的開發實現，輕 UI。
2. SDK 設計原則
2.1 核心原則
核心原則：一定要穩定，不能引起客戶 App 的崩潰。
由於我們的 SDK 是服務於 2B 行業，所以會有很多 App 整合我們的 SDK，這就要求 SDK 的核心原則不能引起客戶 App 的崩潰。一旦 SDK 的出現引起崩潰的 bug，這將對眾多 App 造成災難性的影響，如果出現這種情況，是非常致命的。所以對於 Android SDK 開發來說，要注意 try...catch 的使用、物件的檢查等等。
2.2 SDK 設計原則
首先需要明確，一方面，SDK 的價值是給呼叫者帶來價值。所以要努力降低使用者的上手難度，易於理解。另一方面要時 SDK 程式碼易於維護。
1. 介面易用性
做 App 開發時，我也抱怨過XX 的 SDK 真難用。一個 SDK 好不好用，關鍵就看介面的設計是否簡單易用，對於接入方來說他不會關注你的實現細節，能用一個 API 介面搞定的業務，堅決不用兩個。注意控制介面的數量。
另一方面，**注意介面的命名。**一個好的 API 介面的命名能夠讓呼叫者見名思意，做到不需要藉助幫助文件就能使用的程度就說明這個介面命名是成功的。比如對於 Android 中設定點選事件的介面 setOnClickListener。
2. 命名規範要統一
對於 SDK 開發來說，統一命名規範很重要，最好的狀態是**接入方看到介面命名就能知道是哪家廠商的 SDK。**換句話說就是 SDK 的命名規範統一，形成自己公司的品牌效應。同時也方便接入方使用。
對於編碼規範，網上都有各個大廠的規範模板，可以選擇其中一個或自定義自己團隊的規範，儘早統一程式碼風格。
3. 跨端介面儘量保持一致
對於同一套 SDK，儘量保持各端介面命名、實現邏輯要一致。在我們的開發過程中，也出現由於跨端之間的邏輯有差異導致客戶在 Android 和 iOS 上體驗不一致的問題，同時也會帶來額外的支援工作。所以對於涉及到多個端的需求設計，一定要進行詳細的溝通和確認，防止出現介面命名和實現不一致的情況。
4. 儘量不依賴第三方庫
隨著開源的普及，GitHub 上有很多經典的開源專案供開發者使用。對於 App 開發者，會經常使用到開源專案，比如網路請求 OkHttp、圖片載入 Glide 等等。但是在 SDK 的開發中，一般的原則是儘量避免使用開源專案庫。主要有以下幾點原因：
- 原因是為了避免與呼叫方由於使用相同的庫引起的衝突，增加呼叫方整合的工作量，降低整合方的體驗。
- 開源庫的不斷更新，所以
SDK需要及時保持更新，會增加額外的維護的工作量。 - 由於引入開源庫，出現問題排查困難。
5. SDK 包儘量小
SDK 包一定要小而精。
小是指包的體積要儘可能的小。避免造成接入方的 App 增加很大，不然會引起接入方的不滿，甚至下架。
精是指功能要專注。比如我們的 SDK 是用於埋點的，那裡面設計提供很多常見的工具類顯然是不合適的。
6. 相容性
相容性是每個開發者都會遇到的問題。在 SDK 開發中更要保證新版本對於舊版本的相容。常見的相容性問題分為兩類。
新老介面相容
一般出現介面相容性的問題主要是由於最初需求考慮不完善，導致後面進行方案優化時引起介面的變更，使之前的介面成為歷史的老大難問題，最終造成刪除難度大。
新功能相容性
這裡的相容性問題分為兩個方面：接入新功能的 App 和未接入新功能的 App。舉個例子，當初我們 SDK 適配 OAID 的方案時，由於需要使用 MSA 提供的整合包才能獲取，但是在 SDK 中一般是不輕易整合一個第三方的庫，所以在設計這個方案時，就需要讓接入方自己整合庫，SDK 中提供獲取的程式碼邏輯。最終在確定開發方案時，就需要考慮到一部分接入方使用了該功能，需要保證該功能正常讀取。一部分接入方沒有使用到該功能，要確保無異常出現。一般這種相容性問題會決定開發方案的技術實現。
3. 整合與維護
3.1 SDK 整合
整合方式要多樣同時靈活方便。比如對於 Android 來說，我們提供通過maven、gradle 依賴引入等方式，也是推薦的整合方式。但是對於一些接入方由於網路的限制，無法直接依賴 maven，這裡就需要提供 aar 包或原始碼來整合。
3.2 整合指南
對於 SDK 的整合和使用，以及版本更新內容和 API 介面介紹，一定要準備比較完善的使用者接入指南。比如我們的 SDK 接入指南分為：
- 基本使用
- 常見問題
- 高階應用
- 外掛配置
- ......
儘管根據經驗來看，有些開發者沒有看文件的習慣，但是一份完整的指導文件還是非常有必要，它可以節省很多整合的成本和時間。
同時文件要注意合理的規劃設計，避免一份文件內容太多，造成閱讀困難。對於使用性的部分，最好有示例程式碼進行展示。
3.3 完備的測試報告
在實際的接入過程中，有很多接入方需要提供相關的效能測試說明，這部分的內容需要及早準備。測試報告的工作可以研發和測試一起協助進行輸出，最終方便後續的支援工作，降低維護成本。
4. 開發經驗
4.1 不做想太多需求
在最初開發 SDK 時，經常會由客戶的一個簡單需求擴充套件很多需求，導致最終增加了多個介面，儘管看似 SDK 非常靈活，但是多出來的介面增加了很多維護成本。
曾經我們做過一個開啟 Fragment 名稱採集的需求，客戶提出的需求是通過檔案配置，然後 SDK 進行讀取。在實施的過程中就出現很多想太多。
- 如果有別的客戶不想通過配置檔案，想使用介面怎麼辦？
- 如果使用者想刪除配置檔案中已配置項怎麼辦？
- 如果客戶想恢復忽略的配置怎麼辦？
這些想太多的需求，會增加很多額外的工作和交付成本，所以在 SDK 開發中一定要避免想太多的需求。
4.2 配置項不提倡提供讀取方法
在 SDK 中經常會有很多初始化開關配置介面，這類介面一般是暴露 set 方法讓使用者去設定，常見在初始化一次性配置，所以這類配置項一般就不需要提供 get 方法，防止介面太多。
總結
目前就想到這麼多內容，歡迎交流，後續有更好的想法積極補充。