自從前段時間離職后,因為個人的事情一直沒有選擇再工作,也導致原有的文章并沒有按時產出.最近個人的事情整理的也差不多了,恰好有不少朋友來問有關SDK開發方面的事情,在此就做個簡單的梳理,希望能幫助各位.
目前更多開發者熱衷于應用開發,極少數的開發者才有機會從事SDK開發工作,而市面上關于SDK開發介紹的文章少之又少,以至于讓大家覺得SDK開發是相對比較難而且非常無聊的工作,今天我們就來簡單的聊聊SDK開發的哪點事.
另外最近好像有博客之星評選,我也來湊個熱鬧,只求一票,不求其他:
點我,點我,投一票,一切為了妹紙
點我,點我,投一票,一切為了妹紙
關于SDK的解釋
什么是SDK
在開始正文之前,首先來聊聊SDK是個啥玩意.
SDK是Software Development Kit的縮寫,譯為"軟件開發工具包",通常是為輔助開發某類軟件而編寫的特定軟件包,框架集合等,SDK一般包含相關文檔,范例和工具.
SDK可以分為系統SDK和應用SDK.所謂的系統SDK是為特定的軟件包,軟件框架,硬件平臺,操作系統等簡歷應用時所使用的開發工具集合.而應用SDK則是基于系統SDK開發的獨立于具體業務而具有特定功能的集合.
比如在進行Android 應用開發時,我們使用Google提供的系統SDK(Android SDK),而我們經常使用的友盟SDK,極光SDK則是基于系統SDK開發的.
明確SDK的概念之后,再來聊一聊這三個概念:Library,API,Framework
什么是Library
Library即我們所說的庫,通常是一組或者幾組類的集合,通常是應用中某些功能的具體實現或者對系統已有功能的增強或補充.對Android開發者而言,最常見的莫過于是Support Library,另外就是我們經常使用各種網絡請求庫(OkHttp,Volley),數據庫操作,圖片加載庫(Glide,ImageLoader)等.
什么是Framework
Framework即我們所說的框架,通常是系統或者應用的骨架,很多時候,它表現為一組抽象的構建及構件實例間交互的方法.因此,可以認為,Framework規定了應用的體系結構,闡明了整體設計,寫作構件之間的依賴關系以及控制流程.注意自處的Framework并不完全等同于你所熟知的Android Framework框架,可以認為Android Framework中體現了Framework的思想,并進行了實現.
什么是API
API是Application Programming Interface,又稱為應用編程接口，是軟件系統不同組成部分銜接的約定。更加通俗的說就API就是我們常見和編寫的方法或函數.
小結
明確了上面提到的概念之后,現在就可以來描述這四者之間的關聯:
SDK主要包含Framework,API及Library的三部分.Framework定義了SDK整體的可重用設計,規定了SDK各功能模塊的職責以及依賴關系.其中個功能模塊體現為Library.模塊之間的內部通信及SDK外部通信(SDK對外提供服務的接口)則通過API進行.
另外完整的SDK還應該包含大量的示例和其他工具.比如在Android SDK的tools目錄下提供了大量的輔助開發工具.
對我們而言,大部分情況下是為某種具體的業務需求開發對應的SDK,以便作為第三正提供給其他需求方使用.比如百度推送的SDK主要實現消息推送功能,需求方只需要集成百度推送的SDK便可以使自己應用具備推送功能.
到現在已經介紹了SDK的主要構成,接下來我們重點來介紹SDK的實現目標以及在SDK架構中的一些核心點.
淺談SDK實現目標
上面介紹了開發中常見的概念,現在來談談SDK的實現目標.任何應用都應具備:簡潔易用,穩定,高效,輕量,SDK作為一種特定應用當然也不例外.
簡潔易用
按照"奧卡姆剃須刀"理論,一個好的產品對第三方使用者使用而言應該是簡潔易用,不用改讓使用者花費太長時間學習的.這對SDK同樣適用---SDK不應該對宿主應用有過多的代碼侵入,也不應該有復雜頻繁的接入工作.比如當開發者需要使用SDK的服務時,只需要在緣由的代碼中新增一行即可.常見的SDK初始化如下:
public class Ad{
@TargetApi(9)
public synchronized static void init(Context context, SdkParams params) {
//省略多行代碼
}
}
當我們需要使用該SDK的服務時,通過一行代碼便可啟用Ad.init(this,params)
要保證較少的代碼侵入主要在對外提供服務時充分考慮到使用者的使用場景來設計出優良的API.一個優良的API在定義的時候應該滿足絕大數開發者所預期的方式---語義上要求通俗易懂,使用上要求簡單可靠.
一個優良的API首先是簡單可靠的.在正常使用的情況下體現為穩定可靠的執行,在異常情況下體現為及時的告知使用者使用錯誤.初次之外,遵循一致的明明規則,并是所有的API呈現出一致的風格對開發而言無疑是個好消息.
穩定
站在SDK使用者角度來看,我們期望第三方的SDK服務應該是穩定高效的,體現在提供穩定可靠的服務,在不影響宿主穩定性的前提下足夠的高效,這就要求我們SDK設計者在設計并實現SDK時要盡可能的做到以下幾點:
- 對外提供穩定的API.SDK的API一旦確定,如無非常嚴重情況不可更改.作為提供服務方,發生API變更所帶來的變工成本非常大.
- 對外提供穩定的業務.在穩定的API后,必須要有穩定的業務來支撐.
- SDK運行時的穩定,作為服務提供方,我們必須確保SDK自身運行的穩定,并且保證接入方不會因為我們的SDK產生不穩定的情況.
- 版本迭代穩定.和面向普通用戶的應用相比,SDK版本的迭代是非常緩慢的.并且需要盡可能的對開發者屏蔽迭代過程,以免給開發者帶來不必要的適配開銷.
高效
無論是普通的應用開發還是SDK開發,都應該考慮到性能問題,SDK設計者應該著重考慮以下問題:
- 更少的內存占用.在不使用多進程的情況下,SDK服務和宿主程序運行在同一進程中,這種情況下必須要求限制SDK內存的占用,不能因為說因為我們SDK占用太多的內存資源,導致應用的存活時間變短.
- 更少的內存抖動.在占用更少內存的前提下,SDK設計者必須刻意的減少反復GC造成的內存抖動問題.
- 更少的電量消耗.盡管很多時候無法對電量消耗做一個很好的權衡,但是仍然有一些可以參考的做法,比如減少使用耗電模塊的時間.比如在使用定位服務時,不要求非常高的精度下優先使用網絡定位而不是GPS定位.
- 更少的流量消耗.
SDK整體架構設計
SDK的架構實現決定了SDK后續的維護難度,因此有必要在此對SDK整體架構中的一些點做些簡單的說明.
模塊化開發
根據單一職責將系統拆分為不同的小模塊，每個模塊保持相對獨立。
模塊之間通過協議或接口通信，以減少相互之間的依賴耦合.模塊內部按照設計的幾大原則進行實現,以保證模塊本身可以靈活實現
對于現代開發而言,模塊化是常用的手段,從宏觀角度來看,模塊是系統最小的組成單元.
組件化開發
組件開發同樣是個老生常提的概念,但從我個人的感受來說,組件是對邏輯的封裝,并具備單個可移植性.比如可以把日志記錄做成一個組件,之后它可以被輕松在應用在不同的項目中.對于android 開發者而言,Android 提供的每個UI 控件同樣也是組件,比如Button,TextView等.
在明確了組件這一概念之后,組件化開發也就不難理解:所謂的組件化就是將整個項目劃分成多個模塊,幾個模塊或者單個模塊作為一個組件,開發過程中我們可以對每個組件進行并行開發,最后發布時通過依賴將組件合并成完整的應用.
那為什么要使用組件化呢?
隨著android的逐漸成熟,現在的app業務越來越復雜,與此同時,android工程也變得日益龐大,代碼行數十幾萬已經是常態,此時有幾個問題便會凸顯出來:
- 工程任何一點改動都會造成整個工程的重新編譯.記憶最深的就是早期在沒有進行組件化的時候,龐大的工程動輒需要十幾分鐘的編譯時間,一杯茶的時間就出來了,很多時候,不得不眼巴巴的等著,盡管現在可以使用facebook出品的buck以及來自阿里的feeline來加速編譯過程,單仍然不夠.
- 整個工程中充斥的大量重復或者冗余的子模塊,業務耦合度非常高,牽一發而動全身.這就造成了"老人不敢改,新人無法改",因為誰也不能預知在做修改之后,會產生什么影響.
- 協作開發基本上是不可能的,天知道彼此在做什么.代碼合并的的時候更是令人痛苦.
- 不方便測試.高度耦合的業務和模塊導致無法下手進行測試,只能草草了事.
通過引入組件化,上面遇到的問題便可迎刃而解.在SDK當中,根據實際情況對其進行組件化,比如我們將分享功能組件化,可以輕松的支持多種渠道的分享,在需要更新分享功能時,可以對其進行單獨的編譯和測試.
通過組件化,我們也可以輕松的實現SDK的定制功能,通過編寫編譯腳本,我們可以決定哪些組件被依賴,最終合并到完整的應用當中.比如友盟中的提供的可定制分享組件(如下圖)的原理就是如此.
插件化開發
什么是插件化開發這里就不做介紹了,一方面插件化并不是個新概念,另外就是插件化到目前為止理論層次上已經非常成熟,不想15念開始研究的時候資料相對較少.
在SDK中為什么使用插件化呢?SDK不同于普通應用,不能頻繁的進行更新,以免讓開發者覺得SDK不穩定或者讓開發者頻繁的集成.SDK看起來變化較慢,實則變化頻繁.就以以前做的廣告SDK而言,有時候經常需要對某類機型進行數據采集或者及時更新反作弊模塊,在沒有使用插件化之前,解決該問題是非常麻煩的.但是在我們利用插件化之后,解決該問題就變得非常容易:我們將SDK整體劃分為兩部分:宿主和插件.宿主只向開發者提供必要的服務接口,并提供了自定義插件加載器.而核心的邏輯則是存在于插件中.當需要采集數據的時候,只需要由開發人員開發好數據采集插件并下發到指定設備即可;當需要修復SDK缺陷時,同樣也只需要下發新的插件包即可.
通過在SDK使用插件化方案,可以有效的對開發者屏蔽手動更新的過程.宿主相對穩定,一旦確定,一般不會變動,而后續的業務變化則只需要通過更新插件來支撐.
除了上面談到的利用插件化解決動態更新之外,通過將整個工程分為宿主和插件可以實現宿主的并行開發和分開編譯,并且能有效的解決方法數65535的限制.在沒有使用插件化之前,我們整個項目是由很多組件通過依賴形成的龐大工程,不得不通過
SDK初始化
和應用開發不同,很多情況下SDK沒有自身的上下文Context,而必須要借助應用提供.SDK初始化的常見做法:Ad.init(Context context,AdParams params),我們往往推薦開發者在應用Application組件中的onCreate()中去掉用該方法,這就意味著該初始化過程是同步的,假如SDK本身初始化時間較長,就會影響應用的啟動速度.
在這種情況下,作為SDK的設計者必須著手解決該問題.通常將SDK服務進一步劃分成核心服務和輔助服務,之后通過并行初始化和延遲初始化的手段來減少SDK初始化耗時.曾經在我所負責的廣告SDK中,有開發者反饋我們的SDK啟動較慢,通過對整個SDK啟動流程進行分析后,我們將插件加載服務和云控服務并行初始化,而對于像日志服務則采用顏值初始化,通過該手段有效的減少了初始化耗時
云更新控制
云控服務作為一種服務端控制客戶端的手段在SDK中開發中非常重要,現在的SDK開發可以不支持插件化,但是必須要提供云控服務,以便讓服務端能控制SDK,比如在不需要進行數據采集的時候,可以通過云控服務關閉SDK采集功能,在需要的時候在將其打開.
對本身是基于插件化開發的SDK而言,云控服務更是不可或缺.
從實現的角度而言,云控服務分為服務端主動和客戶端主動.服務端主動是指服務端會將最新的云控開關的信息推送到SDK,而客戶端主動則是SDK在進行操作之前會首先請求云控信息.對有推送開發經營的同學而言,這非常容易理解,就是像是為了實現消息推送功能,我們可以通過客戶端輪訓也可以通過服務端保持長連接進行消息推送一樣.
安全
SDK自身安全
為了區分接入者并挑高SDK自身安全性,我們通常會為開發者分配api key和api secret,SDK會讀取開發者配置的api key和api secret,并用于隨后的網絡通信中.這是非常常見的做法,比如當你集成極光推送SDK的時候,它也許需要你提供api key和api secret,如果沒有則需要到官網進行申請.
核心邏輯采用C/C++
為了安全起見,數據加密類,模塊算法類都都應該采用NDK開發,將其封裝在so文件當中.有很多開發者不明白為什么這樣會增強安全性.這里我們簡單的做個說明.由于.so文件是通過c/c++編譯出的文件,相對于java的反編譯文件來說,可讀性更差,另外大部分的Android開發者并不具備較深的C/C++能力,因此一定程度上增加了被破解的能力.
通訊加密
針對實際情況對通訊協議進行加密,具體是采用對稱加密還是非對稱加密,則需要根據實際情況做選擇.另外,請盡可能使用https來代替http.
設備安全
在很多情況下,比如廣告SDK中,有一些開發者會通過虛擬機來刷廣告,因此有必要針對此情況做判斷.一旦SDK檢測出非法請求后可以采取兩種方案,一種是SDK拒絕服務,另外一種則是正常服務,SDK會將作弊信息上傳至服務器,以便后端服務定向排除數據.
減少傳輸數據大小
在設計SDK和服務端通訊之間的數據協議時,需要根據實際情況考慮,但有以下幾條建議值得我們接受:
- 如果對傳輸的數據大小有要求,建議對數據進行壓縮.
- 可以采用json/xml/Protobuf等協議,如果它們仍然不能滿足則可以考慮自定義二進制協議.
選擇支持最低系統版本
作為SDK的設計者,面臨一個很大的問題是我們不得不考慮開發者應用所支持的系統最小版本,但是在SDK發布之前,我們并不知道會什么樣的開發者使用我們提供的服務,因此為了讓SDK支持更廣泛的設備,我們需要降低最低支持的系統版本.比如現在失眠上主流的系統版本是Android 5.0,那么對SDK而言,起碼要支持到Android 4.0,甚至是Android 2.3.
降低最低支持版本看起來很容易,但是我們不得不做更多的工作來確保SDK能表現出一致的工作行為(通常,我們在SDK內部檢測當前系統版本來確定哪些方法可以被調用).更殘酷的真相是我們花費了很大的精力去支持2.3,但來自2.3系統版本的請求量卻連1%都不到.
權限管理
Android中任何開發都避不開權限申請.作為SDK的設計者,對于權限遵循"如無必要,無需增加",換句話說就是用不到的權限,就不要加上去,這也是我們所謂的最小權限原則,該原則同樣適用于普通應用開發.
在剛接觸SDK開發時,某些早期功能需要某些權限,但是后期該功能被砍掉了,但是權限卻忘記去掉,這就導致不必要權限仍然存在的情況.
另外過多的權限申請,會讓開發者懷疑你的目的.比如一個廣告SDK的你申請照相機權限是想干嘛?恩,我懷疑你在偷拍我....好吧,這里我只是開個玩笑.
另外,從android 6.0以上,google改變了權限申請的策略,因此需要單獨對此做適配.
日志服務
無論系統大小,日志服務是基本的服務.一個良好的日志服務能夠幫助我們快速的發現問題,定位缺陷,從而獲得問題的解決方案.
SDK的日志服務和其他常見的日志服務并無太大的不同,但是要保證以下幾點:
- 日志服務能夠記錄有效的信息,在SDK要關鍵位置進行打點.
- 日志服務上傳日志信息到服務器時,要保證最大的可靠性,不能發生上傳失敗后拋棄日志的情況.
- 日志服務不能影響對正常的操作流程有過多的性能影響.SDK產生的日志信息往往是非常多的,因此必須考慮日志IO操作所帶來的開銷.
深究API設計
API的設計在任何開發中都是非常重要的,很多時候軟件的質量好不好在API的設計可以得到體現.在普通的應用開發中,API只會在應用開發人員間流通而不會暴露給非本應用開發的其他人員,但是SDK作為一種服務,需要向開發者暴露一部分API.通常我們將內部流通的API稱之為內部API,而開放給開發者的稱之為SDK API.
兩者使用場景雖然不同,但是都遵循著一些通用的設計規則,這里無法細說,只列出我認為需要重點關注的十一條原則:
方法名能夠表明其用途
方法名是理解方法含義的第一渠道.一個好的方法名首先是能夠向他人展示自身功能,這樣做的好處就是能夠減少不必要的溝通成本,對于開發者而言,還有什么比直接讀代碼更直觀呢.
參數的合法性檢驗
對參數進行合法性檢驗是非常重要的,請不要想當然的認為可以用運行時異常來代替.當合法性校驗不通過時,針對方法權限不同分別對應不同不同的處理策略:
- 對于公開方法通過顯示檢查拋出異常的方式，并且使用javadoc的@throw來說明拋出異常的原因
- 對于私有方法通過斷言的方式來檢查參數的合法
- 檢查構造方法的參數的合法性，以使對象處在統一狀態
需要注意,如果檢查的代價太大，需要綜合考量，比如如果接受的是一個很大的List，此時檢查的代價可能很大
方法要明確其單一的功能
一個方法應該具有單一的功能，盡可能做更少，但是更專的事情.這也是我們常說的單一職責原則.另外一定要記住寧可提供小而美的方法也不要提供大而全的方法,經驗正面大而全的方法往往發生變動,產生風險的可能性更高,因此不如提供更小的方法以便組合使用
方法異常問題
對于需要暴露給開發者的方法要及時的拋出可查異常來幫助開發者在編譯階段發現問題,另外,對于運行時異常,SDK設計者必須保證該類異常不會導致宿主程序出問題并且需要告知開發者.
方法權限控制
方法的權限也是需要著重考慮的,SDK設計者必須同時從安全和業務的角度考慮哪些方法是可公開的,哪些是不可公開以及哪些是靜態的.
避免過長參數
過長的參數會造成記憶上困難,需要慎重對待.在無法避免過長參數的情況下,需要考慮其他的方法進行解決:
a. 通過使用Builder模式來實現
b. 通過使用輔助類,通常采用靜態內部類的方式,具體見靜態內部類的使用
c. 通過將多個參數封裝成類對象
d. 通過將參數拆解成多個方法的參數
謹慎使用方法重載
重載不應該讓使用者感到疑惑,即不應該出現這種情況:同樣的參數,但是開發者不能明確哪個方法會被執行.換言之就是不要產生歧義性.
另外需要注意,不要存在參數類型經過自動轉換就可以運行在另外一個方法的情況,我曾經在code review中看到這樣的代碼:list中的remove(Object)和remove(int),請務必保證自己不會犯類似的錯誤.盡管在java當中能夠使用重載,但是我不建議使用,尤其是不要重載變長參數,在需要重載的時候寧可使用不同方法名來代替也要好的多.關于這點java中提供的ObjectOutputStream類給我們做了很好的示范:它的write對于每個基本類型都有一個變形,比如寫出字符,寫出boolean等操作,我們發現設計者,并沒有使用重載將其設計成write(Long l),write(Boolean b),而是將其設計為writeLong(l),writeBoolean().
對于構造函數,則可以通過是用靜態工廠的方式來代替重載.
謹慎使用變長參數
多數情況下不需要使用變長參數,一般方法的參數在5個以上的時候,才 建議使用變長參數.在還有其他非變長參數的情況下,我覺得變長參數放在形參列表的最后.
避免方法直接返回NUll
對于需要返回數組或這集合的方法,不要返回null.比如我們去買糕點店買面包,面包沒了是一種正常狀態,就不應該返回null,而是返回長度為0的數組或集合.
必要時進行保護性拷貝
當類接受來自客戶端的對象或者需要向客戶端返回對象,如果該類不能容忍進來的對象再發生變化,那么有必要對對象進行保護性拷貝.另外要注意參數的合法性檢驗發生在保護性拷貝之后.
需要注意的是如果需要進行保護性拷貝的對象非常大,比如list集合中存在十多萬個對象,需要權衡處理.
這十一條原則是我在團隊中推廣并要求嚴格遵守的,下面,將對這十條原則分別進行說明.
SDK開發流程
關于SDK開發流程,我會從以下三個方面寫:一時團隊中如何協同開發,二是SDK的持續集成,三是SDK多倉庫拆分和管理.
這三方面會再另外的篇章中展現(具體什么時候寫完目前還未確定)
SDK版本管理策略
SDK 版本號命名及修改原則
SDK版本號命名和我們以往的命名規則并無太大不同,通由4部分組成,格式為:
V主版本號子版本號階段版本號_日期版本號加希臘字母版本號.比如V1_1_2_161209_beta.
希臘字母版本號說明
- Alpha版:內部測試版,此版本表示該軟件在該階段主要是以實現功能為主,Bug相對較多,需要繼續修改,通常只在內部流通流通而不對外開放.
- Beta版:外部測試版,該版本相對Alpha已經有了很大的改進,不存在嚴重的Bug,但還是存在一些缺陷,需要進一步的測試以檢查和消除Bug.
- RC版:該版本已經相當成熟,不存在導致錯誤的Bug.與正式版相差無幾.
- Release版:該版本意味著"最終版本",是最終交付用戶或者公開發布的版本,也稱為標準版.需要注意的是,該版本在發布的時候回以符合R來代替Release單詞.
版本號修改規則
- 主版本號變化:當功能模塊有較大的變化或者整體架構發生變化
- 子版本號變化:當功能有一定變化
- 階段版本號變化:一般是Bug修復或者較小的變動,根據反饋,需要經常發布修訂版本.
- 日期版本號(161209):用于記錄修改項目的當前日期,每天對項目的修改都要更改日期版本號.
- 希臘字母版本號:此版本?號用于標注當前軟件處于那個開發階段,當軟件進入到另一個階段是需要修改.
API版本管理
和普通應用API版本管理不同,SDK設計者需要著重關注SDK API的管理.原則上SDK API一旦公開發布后其狀態(簽名和具體實現)應為不可變.
對于特殊情況下API的變更,需要遵守"開閉原則",即一個類,模塊,方法應該對擴展開發,對修改關閉.這就要求我們做到以下幾點:
- 在需要調整SDK API時,優先選擇添加新方法,而不是在原方法上修改.對于實現相同功能的新方法,盡可能的要兼容原始方法.
- 在需要廢除某些方法時,需要在正式版發版前使用@deprecated標識,并給出替代方案和廢棄的時間(通常是SDK版本號)
接入文檔和API文檔版本管理
接入文檔是用來告訴SDK使用者,如何使用SDK,使用的詳細步驟和可能發生的問題,每個公司會有自己的一套規則,這個不需要做太多的解釋.
另外,接入文檔通常分為兩份:內部版和公開版.內部版通常用于內部開發人員和測試人員,信息較為詳細,而公開版則是面向開發者,相比內部版會省略的一些信息.
API文檔其實就是對SDK API的更詳細說明,類似java中的api doc,可以借助jdk的自帶javadoc直接生成,當然在android studio也提供了便捷的生成方式.
無論是接入文檔還是api說明文檔,其變更一般發生在SDK版本發生變化時.當SDK發生變更時,文檔必須隨之更新,不能出現SDK更新后說明文檔不與之匹配的情況.
集成Demo版本管理
集成Demo通常是一個簡單的app,用來展示如何快速的接入SDK.其版本變更策略和SDK版本的變化保持一致.
總結
SDK開發中需要關注的點非常多,每個點都不能用三言兩語完成的,后面會在此基礎上慢慢的補充.
