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

　　回憶之前

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

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

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

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

　　A： 回想下我們在做C或者C++開發(fā)的時(shí)候。如果一個(gè)靜態(tài)庫依賴另外一個(gè)靜態(tài)庫（A依賴B）。那么被依賴庫B升級的時(shí)候A用重新編譯嗎？ 不一定，如果是一些方法的新增，維護(hù)，不一定會讓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特性，同時(shí)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的庫依賴極易引起二進(jìn)制兼容性問題。更多關(guān)于Swift庫二進(jìn)制接口（ABI）兼容性問題，請參考文后鏈接。

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

　　A： 首先在組件化初期的時(shí)候，我們能做到的一般是基礎(chǔ)庫抽離，業(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ǔ)庫設(shè)計(jì)到跨業(yè)務(wù)，跨APP使用。我們希望不同團(tuán)隊(duì)有不同基礎(chǔ)組件的讀寫權(quán)限。那么我們更可能偏向提供二進(jìn)制庫加文檔的形式。

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

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

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

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

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

　　解決辦法

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

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

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

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

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

相關(guān)電子資料下載

• 如何在Windows系統(tǒng)上設(shè)置Docker鏡像源 55
• 怎樣延長半導(dǎo)體元器件的壽命呢？ 183
• 新思科技攜手臺積公司加速N2工藝下的SoC創(chuàng)新 200
• Microchip誠邀您參加Tech Insights China 2023系列在線研討會 32
• 機(jī)器學(xué)習(xí)需要掌握的九種工具盤點(diǎn) 16
• 貿(mào)澤開售用于高級駕駛輔助系統(tǒng)和自動泊車的 Texas Instruments TDA4x SoC處理器 181
• RISC-V要顛覆GPU嗎？ 212
• RocketMQ的定時(shí)任務(wù)設(shè)計(jì)精髓！ 13
• 用于光學(xué)設(shè)備的柔性變色系統(tǒng)研究探討 141
• 雷迪埃 OCTIS 在通訊行業(yè)Open Ran中的應(yīng)用 318