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

　　此簡書只做備份，強烈推薦原文，畢竟格式比簡書好看，還清晰

　　回憶之前

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

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

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

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

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

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

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

　　Q： Swift中庫依賴問題

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

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

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

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

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

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

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

　　動態(tài)庫過多問題

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

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

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

　　解決辦法

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

　　部分組件（含有Swift）動態(tài)庫化，其他部分仍舊整合進app的二進制中

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

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

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