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 方法，防止接口太多。
總結
目前就想到這麼多內容，歡迎交流，後續有更好的想法積極補充。