對 Android SDK 開發的一些我的心得

前言

自從工做之後，大部分時間都是參與 Android SDK 方面的開發工做，滿打滿算也有兩年時間了，多多少少有點心得體會。以前偶然在脈脈上回答了一個「APP 開發和 SDK 開發有什麼區別」的問題，前幾天又有朋友問到了相似的問題，因此我總結了一下，算是我的心得吧。不過，畢竟我工齡不長，可能理解有不到位的地方，還請諒解！

對 SDK 開發的見解

SDK 開發和 APP 開發的區別仍是很大的。APP 更傾向於用戶體驗、功能更偏於特定業務、講究的是快速迭代、快速佔領市場。而 SDK 是爲 APP 服務的，提供的大可能是公共基礎服務，如網絡請求、打點統計、賬號服務等。下面從幾個點說說個人見解。

體積和功能

能夠用三個字形容：小而精。小是指包的體積要儘量的小，由於業務方接入的時候可能會有這樣的抱怨：怎麼接了大家的 SDK 後 APP 的包體積漲了好幾 M 啊？會下降下載率的...（嚶嚶嚶...）。精針對的就是 SDK 的功能了，必定要專一於特定功能，捨棄那些自覺得是的需求。要相信多變的業務方必定會反饋新需求的，到時候再對 SDK 的功能進行補充便可。

簡短總潔一下：

體積上：小！小！小！

1. 去除無用資源（主要是圖片和 so 庫）和代碼；
2. 不要依賴第三方庫，至少大致積的庫是不能夠的，能夠考慮移植開源代碼（只需移植關鍵代碼，有必要的話根據 SDK 特性作適當修改）；
3. 優化代碼結構，去除冗餘的代碼邏輯（考慮各類設計模式和分包策略）；
4. 打包時進行混淆優化；

功能上：

1. SDK 講究功能專注，去除那些花裏胡哨的東西；
2. 基本功能完善，適用於全部的業務線；
3. 根據業務方的需求反饋，考慮優化或者豐富 SDK 功能；

兼容性

SDK 的兼容性主要考慮幾個方面：

1. 對外接口（ API ）的兼容性：每次版本更新後，對外接口要儘量保持不變。對於更改較大的接口，可使用 @Deprecated 註解對老接口進行標記，而且作新接口調用的兼容，而不是直接刪除老接口。
2. 功能的兼容性：在不影響總體功能和項目結構的基礎上提供部分業務的需求定製化，能夠造成配置項（相信我，業務方確定會提一些亂七八糟的需求的，咱惹不起，只好提供配置項了...）。
3. 若是部分業務較難適配，那隻能新開 SDK 分支，作業務的定製化版本（儘可能不要這麼幹，能夠和業務商量，由於分支太多後期很難維護）。
4. SDK 支持的 Android 版本的兼容性：minSdkVersion 的值應該儘量的小，固然如今市場上基本都是 4.4 以上的手機了。這也從側面要求不要隨便依賴第三方庫。

穩定性

SDK 極其注重穩定性，要保證在不一樣 APP 環境下都能正常工做。若是出現問題就會致使發新版本，一方面要通知全部業務方作版本更新（這是一件很麻煩的事），另外一方面會打亂業務方 APP 的版本更新安排（這個鍋背定了...）。

因此：

1. 版本迭代要穩定：通常版本號都採用 x.y.z 模式，對於小功能或者是小的修復，增長 z 值便可，不能影響已經上線的服務。
2. 對於大版本的改動，增長 y 值甚至 x 值後，須要讓 PM 告知業務方下次發版時使用最新版本的 SDK （若是是大 BUG 的修復，那就必須強制要求業務方更新了）。
3. SDK 上線前必須通過完整的測試流程，保證功能正確、性能達到要求、對不一樣機型進行適配、對不一樣 Android 版本進行適配。業務方接入後，可讓業務方也走一遍測試，提供反饋報告。
4. SDK 的結構設計應該要有好的擴展性，好比接入一個新功能，就不能影響總體的代碼框架，不然可能形成一些潛在的威脅，也會增長測試的工做量。

安全性

不光是 APP 須要一些安全措施，SDK 也是有必要保證安全性的。

1. SDK 混淆、加固、安全審覈，這個通常是公司級別的安全管控。針對安全報告作對應修復便可。
2. 隱私數據的保護，必須進行加密或者掩碼處理。好比：本地保存用戶的登陸態，手機號的掩碼顯示等。
3. 網絡請求時的數據加密保護，部門通常都有本身的加密機制，大部分都是模仿 ssl 握手協議，採用非對稱加密和對稱加密結合的方式。更嚴格的話，能夠增長自定義證書校驗，不過這個成本較高。
4. 對於 SDK 中接入的部分第三方功能或者服務須要提供雲控機制。由於第三方服務存在不穩定性和弱安全性。

文檔規範

這個是被普遍忽視的一點，文檔真的很重要！文檔真的很重要！文檔真的很重要！

1. SDK 的最終形態中必定要包含接入文檔和演示 Demo 。雖然大部分業務方都不看文檔，但你必定要寫（至少甩鍋的時候好甩...）。至於演示 Demo ，必定要考慮儘量多的場景，把 SDK 的功能都展現出來。
2. 文檔要儘量詳細，但最好不要把全部內容都集中在一個文檔裏面，這樣致使文檔過長，業務方更加反感閱讀。能夠對文檔作細劃，好比：如何接入（jar、aar？或者是離線包仍是 maven 庫？）、基本功能如何使用（大部分業務只須要基本功能）、定製化功能如何使用、接入中可能遇到什麼問題、怎麼解決這些問題等等。
3. 最好能有個 Web 頁面的服務平臺（相似開放平臺），業務方能夠直接在平臺上進行應用的註冊、管理、文檔閱讀等。服務平臺也能夠作一些數據統計的可視化，方便 SDK 的後續發展。

總結

以上就是我目前對 SDK 開發的一些心得體會了，你們有其餘想法能夠交流交流。至於 APP 開發，本人經驗不足就不獻醜了。

總的來講，SDK 有本身的生命系統，但它依舊服務於業務、生存於業務、發展於業務，它是業務不可或缺的一部分。