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