關(guān)于組件化開發(fā)實(shí)例講解

　　此簡(jiǎn)書只做備份，強(qiáng)烈推薦原文，畢竟格式比簡(jiǎn)書好看，還清晰

　　回憶之前

　　上篇文章中我們已經(jīng)完美的解決了 使用swift第三方庫(kù) ，使用混編的組件，使用use_framework！，但是會(huì)帶來別的問題。

　　果然是生命不息，折騰不止啊。

　　不建議在組件化的項(xiàng)目中使用Swift來寫業(yè)務(wù)

　　Q： C++/C 靜態(tài)庫(kù)依賴問題

　　A： 回想下我們?cè)谧鯟或者C++開發(fā)的時(shí)候。如果一個(gè)靜態(tài)庫(kù)依賴另外一個(gè)靜態(tài)庫(kù)（A依賴B）。那么被依賴庫(kù)B升級(jí)的時(shí)候A用重新編譯嗎？ 不一定，如果是一些方法的新增，維護(hù)，不一定會(huì)讓A重復(fù)編譯；但是如果修改了B里面的數(shù)據(jù)結(jié)構(gòu)，A里面又用到了這些數(shù)據(jù)結(jié)構(gòu)，那么很大可能性我們就要重新編譯A了。

　　Q： Objective-C 靜態(tài)庫(kù)依賴問題

　　A： 回想下我們?cè)?a href='http://srfitnesspt.com/tags/ios/' target='_blank' class='arckwlink_none'>iOS中出現(xiàn)上述的依賴問題，貌似也沒有見到要重新編譯A的情景。主要是Objc2.0引入了 non-fragile特性，同時(shí)OC是嚴(yán)重依賴于Runtime的，只要接口兼容，就算你修改了B中的數(shù)據(jù)結(jié)構(gòu)，一般也是不需要重新編譯A的。如果你不明白non-fragile 請(qǐng)看文后的參考鏈接

　　Q： Swift中庫(kù)依賴問題

　　A： 由于Swift不和OC一樣，所有的OC方法都是通過Runtime動(dòng)態(tài)調(diào)度的。Swift對(duì)于方法是存在靜態(tài)調(diào)度和動(dòng)態(tài)調(diào)度2種的。所以Swift的庫(kù)依賴極易引起二進(jìn)制兼容性問題。更多關(guān)于Swift庫(kù)二進(jìn)制接口（ABI）兼容性問題，請(qǐng)參考文后鏈接。

　　Q： 為什么不建議在組件化的項(xiàng)目中使用Swift或者和OC混編來寫業(yè)務(wù)？

　　A： 首先在組件化初期的時(shí)候，我們能做到的一般是基礎(chǔ)庫(kù)抽離，業(yè)務(wù)組件分離這些。但是一般來說我們這時(shí)候的殼工程，接入這些分離的組件的時(shí)候都是使用源碼接入，這時(shí)候問題暫時(shí)顯現(xiàn)不出來。

　　第二步。當(dāng)我們的組件化的腳步越走越遠(yuǎn)的時(shí)候，我們出于多方面的考慮可能有以下需求。

　　開發(fā)時(shí)重復(fù)編譯是痛點(diǎn)。我們可能更希望提供的是二進(jìn)制版本，節(jié)省下大量的編譯耗時(shí)；

　　我們可能要做權(quán)限管理。有時(shí)候一個(gè)公司業(yè)務(wù)和人員規(guī)模都非常龐大。我們基礎(chǔ)庫(kù)設(shè)計(jì)到跨業(yè)務(wù)，跨APP使用。我們希望不同團(tuán)隊(duì)有不同基礎(chǔ)組件的讀寫權(quán)限。那么我們更可能偏向提供二進(jìn)制庫(kù)加文檔的形式。

　　綜上： 由于使用Swift開發(fā)ABI不兼容問題更易出現(xiàn)。在組件化的項(xiàng)目中，不建議使用Swift或者混編。

　　動(dòng)態(tài)庫(kù)過多問題

　　上面說到的問題（麻煩）其實(shí)是帶給開發(fā)者的麻煩，但是動(dòng)態(tài)庫(kù)多了會(huì)給用戶帶來麻煩（APP啟動(dòng)耗時(shí)）。用了混編的項(xiàng)目我們?cè)赑odfile里面勢(shì)必要寫use_framework！，上篇文章中我們也說到用了這個(gè)指令。CocoaPods會(huì)幫我們把所有的庫(kù)全部編譯為動(dòng)態(tài)庫(kù)。這些動(dòng)態(tài)庫(kù)是在APP啟動(dòng)時(shí)做去加載的。我們?cè)诮M件化的時(shí)候，自己的業(yè)務(wù)組件馬上接近上百個(gè)?？梢灶A(yù)想到以后隨著組件化的越來越深入，這些庫(kù)會(huì)越來越多。這個(gè)時(shí)間可能會(huì)達(dá)到1s的量級(jí)。對(duì)于用戶 這是不可接受的。關(guān)于動(dòng)態(tài)庫(kù)過多導(dǎo)致的啟動(dòng)慢的問題請(qǐng)參考文后的參考鏈接。

　　結(jié)合公司目前的情況的解決方案

　　我們公司目前的情況： Swift第三方庫(kù)個(gè)別，混編組件個(gè)別。既然都是個(gè)別的，我們總不能因?yàn)檫@些個(gè)別的特殊case讓APP原本的1個(gè)二進(jìn)制文件變成 1個(gè)二進(jìn)制文件+上百個(gè)動(dòng)態(tài)庫(kù)framework。這肯定是不合理的。

　　解決辦法

　　不使用Swift，包括第三方庫(kù)和混編組件

　　部分組件（含有Swift）動(dòng)態(tài)庫(kù)化，其他部分仍舊整合進(jìn)app的二進(jìn)制中

　　首先來看辦法1直觀感覺是不合適。首先很多公司的項(xiàng)目在做組件化的時(shí)候項(xiàng)目已經(jīng)達(dá)到一定程度（沒有一定規(guī)模也沒必要做組件化），這就意味著大部分APP是有歷史包袱的。首先重寫這些已有的組件或者功能肯定是有風(fēng)險(xiǎn)的，在公司業(yè)務(wù)多。用戶量大的情況下，影響面會(huì)更大，雖然這樣是一勞永逸的，但是同時(shí)風(fēng)險(xiǎn)是更大的。我們?cè)谧鼋M件化的工作中，改善大家開發(fā)的痛點(diǎn)，提高開發(fā)效率才是主要目標(biāo)。至于重構(gòu)甚至重寫則是業(yè)務(wù)方的重心。

　　第二種辦法就是做到部分組件動(dòng)態(tài)庫(kù)化。

　　我們來回憶下靜態(tài)庫(kù)的特點(diǎn)。靜態(tài)庫(kù)和主工程鏈接的時(shí)候會(huì)把庫(kù)里面的代碼復(fù)制到可執(zhí)行文件中。對(duì)于這部分符號(hào)在APP啟動(dòng)時(shí)會(huì)省去load，rebase ，binding的時(shí)間。那么在iOS平臺(tái)中嵌入式動(dòng)態(tài)庫(kù)的特點(diǎn)是不把庫(kù)里面的代碼復(fù)制到可執(zhí)行文件中，而是單獨(dú)復(fù)制到APP里面的frameworks路徑下。所以通常來說動(dòng)態(tài)庫(kù)節(jié)省內(nèi)存。在iOS平臺(tái)上做不到。靜態(tài)庫(kù)的缺點(diǎn)是會(huì)讓APP安裝包增大。那么我們自己做的嵌入式動(dòng)態(tài)庫(kù)也會(huì)有這個(gè)問題。并且還會(huì)導(dǎo)致APP啟動(dòng)變慢。那豈不是優(yōu)點(diǎn)變成了缺點(diǎn)~~。