前言
目前我們所開發(fā)SDK的目的是為了流程簡化的同時,保證數(shù)據(jù)邏輯安全;說到底,我們就是為了要讓流程變簡潔而已。但隨著這些年所開發(fā)出來的SDK,不斷的經(jīng)由客戶的考驗和反饋;越發(fā)覺得開發(fā)SDK的工作前期設計部分非常重要,因為每一版所發(fā)布的SDK,在接口上不能產(chǎn)生太大的變化,為了讓SDK有更好的兼容性,我大概總結了下面的一些方法。
1、提供全能類型的初始化方式
這個方法是我在Objective-c的一些優(yōu)化語言中找到的,因為我們所設計的接口是基于開發(fā)者的角度,所以初始化最好提供全面的初始化方法。
需要盡量提供可能會用到的所有接口,這樣有助于二次開發(fā)(當然這些事情是不可以一步到位的)
- (instancetype) init {
if (self = [super init]) {
[self commonInit:6];
}
return self;
}
- (instancetype) initWithFrame:(CGRect)frame {
if (self = [super initWithFrame:frame]) {
[self commonInit:6];
}
return self;
}
-(instancetype)initWithFrame:(CGRect)frame withCount:(int)index{
self = [super initWithFrame:frame];
if (self) {
[self commonInit:index];
}
return self;
}
-(instancetype)initWithFrame:(CGRect)frame withCount:(int)index withType:(int)type{
self = [super initWithFrame:frame];
if (self) {
[self commonInt:index with:type];
}
return self;
}
2、對象多使用不可變對象
這個是需要看情況而定的,但是對于封裝的類對象,尤其是用于數(shù)據(jù)操作類的,建議盡量創(chuàng)建使用不可變的對象,如果想支持可操作的屬性,可以提供方法來實現(xiàn)修改屬性。
3、使用前綴命名來避免沖突
在使用到更多的類庫以后,就更容易出現(xiàn)名字相同的沖突,尤其是在一些功能性相仿的類,我們之前寫過的DV12的類庫和DFUnit還有最新的DV16的庫就存在過沖突,通常這類沖突在編譯的時候就能檢索出來。
為了避免這種情況,我們可以通過以下的方法來實現(xiàn):
- 命名的引申義:通過類的功能可以使用駝峰法來命名,但功能總有相似性,于是我們可以使用公司前綴或者簡稱等來命名類以及類方法
- 第三方庫的引用:對于我們引用的第三方庫的引用,我們通常也能發(fā)現(xiàn)他們具備了自己獨特的類命名方式,而這個時候,我們要做的就是保留他們原有的名字,這不僅僅是避免命名沖突的問題,更多的是對原作者的尊重。
- 為私有類提供前綴:對于私有不開放的類,我們也可以通過前綴的方式來做區(qū)分,這樣有利于我們在發(fā)布或者打包的時候有效區(qū)分那些是私有的,那些是應該公布出去的。
4、API的層級處理
SDK是應該具備層級架構的,這不僅僅是功能性的體現(xiàn),更是一個庫的核心所在,如果層級架構做得好,那么在二次開發(fā)的時候就能避免很多的問題,邏輯也變得更加的清晰,每個層級關系的嵌套要清晰。
- 通過類別或功能來進行層級劃分
- 關于內(nèi)部流程的控制
因為SDK的工作本來就是需要將復雜的流程封裝起來,讓二次調(diào)用的人更簡單、更方便的去使用,但是我們的SDK并不是一次開發(fā)不需要后期維護的,所以為了以后的維護和方便些,我們需要對涉及業(yè)務流程的流程圖和相關邏輯記錄下來,可以通過類內(nèi)部的注釋或者流程圖的方式來記錄。
另外流程也需要獨立性高一點,盡量提高一些簡單流程的復用性,避免整個SDK的庫非常臃腫。
5、錯誤結果的處理
由于SDK是給開發(fā)者二次開發(fā)的,所以log記錄很重要,它可以在第一時間替我們找到問題的發(fā)生點,為此我在SDK中添加了Log打印的等級控制,方便控制打印,還有一個就是需要對這些打印內(nèi)容保存,保存在文件里,當出現(xiàn)問題的時候就可以翻出來查找問題所在了。
錯誤內(nèi)容的反饋還不局限體現(xiàn)在打印上,也可以通過增加錯誤碼列表,來分析定位問題。
6、SDK中消息的傳遞
我們的SDK涉及到較多的數(shù)據(jù)交互,這些是不能局限于庫的內(nèi)部,還要通過協(xié)議上傳給上層,讓二次開發(fā)更加清晰、簡單的獲取到所需的數(shù)據(jù),目前iOS上的消息傳遞大概分為以下幾種,我們可以根據(jù)他們的優(yōu)缺點來進行選擇,當然最好在設計接口的時候能夠考慮到都用上。
傳遞方式 | 優(yōu)點 | 缺點 |
---|---|---|
Delegate:代理 | 數(shù)據(jù)回調(diào)屬于類對象擁有內(nèi)容,數(shù)據(jù)回調(diào)高效可靠,可實現(xiàn)多個函數(shù)來回調(diào)不同數(shù)據(jù)內(nèi)容 | 局限于當前類,如果要多個類之間傳遞,實現(xiàn)起來的代碼會非常臃腫 |
block:代碼塊 | 輕量級的回調(diào),代碼簡潔,邏輯清晰 | 容易造成循環(huán)引用,臨時性;代碼塊存放在堆棧上,容易造成內(nèi)存泄露 |
KVO:觀察者 | 提供了簡單的實現(xiàn)兩個對象同步屬性的方法,能對非我們創(chuàng)建的對象進行狀態(tài)監(jiān)聽,不需要高邊內(nèi)部對象 | 觀察屬性比較單一,適用的場景較少 |
NSNotification:通知 | 整個APP內(nèi)都可以監(jiān)聽這個通知消息,屬于ARC,不用管理內(nèi)存問題 | 需要配對remove使用,會導致多處接收,多處處理,代碼整體架構處理很混亂 |
整體的腦圖如下: