前言
自從工作以後，大部分時間都是參與 Android SDK 方面的開發工作，滿打滿算也有兩年時間了，多多少少有點心得體會。之前偶然在脈脈上回答了一個“APP 開發和 SDK 開發有什麼區別”的問題，前幾天又有朋友問到了類似的問題，所以我總結了一下，算是個人心得吧。不過，畢竟我工齡不長，可能理解有不到位的地方，還請諒解！
對 SDK 開發的看法
SDK 開發和 APP 開發的區別還是很大的。APP 更傾向於使用者體驗、功能更偏於特定業務、講究的是快速迭代、快速佔領市場。而 SDK 是為 APP 服務的，提供的大多是公共基礎服務，如網路請求、打點統計、帳號服務等。下面從幾個點說說我的看法。
體積和功能
可以用三個字形容：小而精。小是指包的體積要儘可能的小，因為業務方接入的時候可能會有這樣的抱怨：怎麼接了你們的 SDK 後 APP 的包體積漲了好幾 M 啊？會降低下載率的...（嚶嚶嚶...）。精針對的就是 SDK 的功能了，一定要專注於特定功能，捨棄那些自以為是的需求。要相信多變的業務方一定會反饋新需求的，到時候再對 SDK 的功能進行補充即可。
簡短總潔一下：
體積上：小！小！小！
- 去除無用資源（主要是圖片和 so 庫）和程式碼；
- 不要依賴第三方庫，至少大體積的庫是不可以的，可以考慮移植開原始碼（只需移植關鍵程式碼，有必要的話根據 SDK 特性做適當修改）；
- 優化程式碼結構，去除冗餘的程式碼邏輯（考慮各種設計模式和分包策略）；
- 打包時進行混淆優化；
功能上：
- SDK 講究功能專一，去除那些花裡胡哨的東西；
- 基本功能完善，適用於所有的業務線；
- 根據業務方的需求反饋，考慮優化或者豐富 SDK 功能；
相容性
SDK 的相容性主要考慮幾個方面：
- 對外介面（ API ）的相容性：每次版本更新後，對外介面要儘可能保持不變。對於更改較大的介面，可以使用 @Deprecated 註解對老介面進行標記，並且做新介面呼叫的相容，而不是直接刪除老介面。
- 功能的相容性：在不影響整體功能和專案結構的基礎上提供部分業務的需求定製化，可以形成配置項（相信我，業務方肯定會提一些亂七八糟的需求的，我們惹不起，只好提供配置項了...）。
- 如果部分業務較難適配，那隻能新開 SDK 分支，做業務的定製化版本（儘量不要這麼幹，可以和業務商量，因為分支太多後期很難維護）。
- SDK 支援的 Android 版本的相容性：minSdkVersion 的值應該儘可能的小，當然現在市場上基本都是 4.4 以上的手機了。這也從側面要求不要隨便依賴第三方庫。
穩定性
SDK 極其注重穩定性，要保證在不同 APP 環境下都能正常工作。如果出現問題就會導致發新版本，一方面要通知所有業務方做版本更新（這是一件很麻煩的事），另一方面會打亂業務方 APP 的版本更新安排（這個鍋背定了...）。
所以：
- 版本迭代要穩定：一般版本號都採用 x.y.z 模式，對於小功能或者是小的修復，增加 z 值即可，不能影響已經上線的服務。
- 對於大版本的改動，增加 y 值甚至 x 值後，需要讓 PM 告知業務方下次發版時使用最新版本的 SDK （如果是大 BUG 的修復，那就必須強制要求業務方更新了）。
- SDK 上線前必須經過完整的測試流程，保證功能正確、效能達到要求、對不同機型進行適配、對不同 Android 版本進行適配。業務方接入後，可以讓業務方也走一遍測試，提供反饋報告。
- SDK 的結構設計應該要有好的擴充套件性，比如接入一個新功能，就不能影響整體的程式碼框架，否則可能造成一些潛在的威脅，也會增加測試的工作量。
安全性
不光是 APP 需要一些安全措施，SDK 也是有必要保證安全性的。
- SDK 混淆、加固、安全稽核，這個一般是公司級別的安全管控。針對安全報告做對應修復即可。
- 隱私資料的保護，必須進行加密或者掩碼處理。比如：本地儲存使用者的登入態，手機號的掩碼顯示等。
- 網路請求時的資料加密保護，部門一般都有自己的加密機制，大部分都是模仿 ssl 握手協議，採用非對稱加密和對稱加密結合的方式。更嚴格的話，可以增加自定義證書校驗，不過這個成本較高。
- 對於 SDK 中接入的部分第三方功能或者服務需要提供雲控機制。因為第三方服務存在不穩定性和弱安全性。
文件規範
這個是被廣泛忽視的一點，文件真的很重要！文件真的很重要！文件真的很重要！
- SDK 的最終形態中一定要包含接入文件和演示 Demo 。雖然大部分業務方都不看文件，但你一定要寫（至少甩鍋的時候好甩...）。至於演示 Demo ，一定要考慮儘可能多的場景，把 SDK 的功能都展示出來。
- 文件要儘可能詳細，但最好不要把所有內容都集中在一個文件裡面，這樣導致文件過長，業務方更加反感閱讀。可以對文件做細劃，比如：如何接入（jar、aar？或者是離線包還是 maven 庫？）、基本功能如何使用（大部分業務只需要基本功能）、定製化功能如何使用、接入中可能遇到什麼問題、怎麼解決這些問題等等。
- 最好能有個 Web 頁面的服務平臺（類似開放平臺），業務方可以直接在平臺上進行應用的註冊、管理、文件閱讀等。服務平臺也可以做一些資料統計的視覺化，方便 SDK 的後續發展。
總結
以上就是我目前對 SDK 開發的一些心得體會了，大家有其他想法可以交流交流。至於 APP 開發，本人經驗不足就不獻醜了。
總的來說，SDK 有自己的生命系統，但它依舊服務於業務、生存於業務、發展於業務，它是業務不可或缺的一部分。