隨著業(yè)務(wù)的發(fā)展或者項(xiàng)目的增長(zhǎng)，為了更好的維護(hù)代碼，在項(xiàng)目的開發(fā)后期都會(huì)對(duì)項(xiàng)目的一些公有組件和基礎(chǔ)業(yè)務(wù)進(jìn)行封裝。最近由于一個(gè)人需要負(fù)責(zé)多個(gè)SDK的開發(fā)，后續(xù)公司可能還會(huì)繼續(xù)開發(fā)新的SDK，對(duì)于每一個(gè)新的SDK的開發(fā)，如果我都從底層的基礎(chǔ)庫（網(wǎng)絡(luò)，解析，工具類等）再到業(yè)務(wù)邏輯層都重新開發(fā)的話，會(huì)需要很多的時(shí)間，并且在開發(fā)過程中會(huì)發(fā)現(xiàn)不同的SDK除了具體的業(yè)務(wù)邏輯不一樣的話，其他基本一致。所以對(duì)于需要快速的去試錯(cuò)開發(fā)一個(gè)SDK的話，抽離封裝基組件庫和公共業(yè)務(wù)勢(shì)在必行，不然代碼拷來拷去很容易出錯(cuò)，吃力不討好。
整體的架構(gòu)思想就是，抽離公共組件庫和公共業(yè)務(wù)代碼庫，做成一個(gè)通用的libCommon.a供其他SDK使用，這樣做的好處很多：
- 通用庫一次開發(fā)，享用一生；
- 新的SDK開發(fā)，只需要專注具體SDK業(yè)務(wù)邏輯的開發(fā)；節(jié)約開發(fā)時(shí)間；
libCommon.a分解
在通用基礎(chǔ)庫中主要包括兩部分，一部分是公共組件庫，一部分是公共業(yè)務(wù)模塊。
- 公共業(yè)務(wù)模塊：我們一般只需要SDK部分幫我們啟動(dòng)業(yè)務(wù)就好，或者再增加一些回調(diào)處理。他的頭文件一般也只會(huì)有一個(gè)。
- 公共組件模塊：有很多子模塊，例如數(shù)據(jù)解析，字符串處理，存儲(chǔ)、網(wǎng)絡(luò)基礎(chǔ)庫等等，這樣的話我們就需要公開很多的頭文件，因此我想到了先使用Framework來封裝公共組件，然后再讓libCommon.a來引用Framework，最后我在SDK中通過libCommon.a使用這個(gè)Framework。整體架構(gòu)就會(huì)變成下面這樣：
錯(cuò)誤的原因
首先說下為什么我要把多個(gè)公共組件制作成一個(gè)Framework，因?yàn)檫@樣的話SDK在調(diào)用的時(shí)候不需要添加很多的.h頭文件。想法是很完美，但是現(xiàn)實(shí)卻很殘酷，我在實(shí)現(xiàn)的過程中l(wèi)ibCommon.a引用了Framework，但是我繼續(xù)在我的libSDK1.a里面繼續(xù)用的時(shí)候，發(fā)現(xiàn)會(huì)報(bào)錯(cuò)(Undefined symbols for architecture x86_64)，在Framework里面定義的方法都找不到了，出現(xiàn)這個(gè)的原因就是沒有在運(yùn)行的時(shí)候沒有找到實(shí)現(xiàn)文件，所以動(dòng)態(tài)去鏈接找方法的時(shí)候出了問題。這里我們需要明白Static Library和Framework的編譯原理。
- Static Library編譯的時(shí)候會(huì)把所有的代碼編譯進(jìn)去；
- Framework編譯的時(shí)候只是進(jìn)行鏈接，函數(shù)在調(diào)用的時(shí)候才會(huì)去尋找實(shí)現(xiàn)，所以在編譯過程Framework里面的組件代碼沒有被編譯到libCommon.a里面，所以我們?cè)谏蠈诱{(diào)用的時(shí)候還是需要引用Framework的，所以這里就不適合我的開發(fā)場(chǎng)景了，因?yàn)槲曳庋b的Framework是不想對(duì)外公開的，只能我內(nèi)部知道和使用。
最后我還是回到原點(diǎn)，將公共組件編譯成靜態(tài)庫然后公開多個(gè)頭文件來處理。
