關于組件化開發實例講解
此簡書只做備份，強烈推薦原文，畢竟格式比簡書好看，還清晰
回憶之前
上篇文章中我們已經完美的解決了 使用swift第三方庫 ，使用混編的組件，使用use_framework！，但是會帶來別的問題。
果然是生命不息，折騰不止啊。
不建議在組件化的項目中使用Swift來寫業務
Q： C++/C 靜態庫依賴問題
A： 回想下我們在做C或者C++開發的時候。如果一個靜態庫依賴另外一個靜態庫（A依賴B）。那么被依賴庫B升級的時候A用重新編譯嗎？ 不一定，如果是一些方法的新增，維護，不一定會讓A重復編譯；但是如果修改了B里面的數據結構，A里面又用到了這些數據結構，那么很大可能性我們就要重新編譯A了。
Q： Objective-C 靜態庫依賴問題
A： 回想下我們在iOS中出現上述的依賴問題，貌似也沒有見到要重新編譯A的情景。主要是Objc2.0引入了 non-fragile特性，同時OC是嚴重依賴于Runtime的，只要接口兼容，就算你修改了B中的數據結構，一般也是不需要重新編譯A的。如果你不明白non-fragile 請看文后的參考鏈接
Q： Swift中庫依賴問題
A： 由于Swift不和OC一樣，所有的OC方法都是通過Runtime動態調度的。Swift對于方法是存在靜態調度和動態調度2種的。所以Swift的庫依賴極易引起二進制兼容性問題。更多關于Swift庫二進制接口（ABI）兼容性問題，請參考文后鏈接。
Q： 為什么不建議在組件化的項目中使用Swift或者和OC混編來寫業務？
A： 首先在組件化初期的時候，我們能做到的一般是基礎庫抽離，業務組件分離這些。但是一般來說我們這時候的殼工程，接入這些分離的組件的時候都是使用源碼接入，這時候問題暫時顯現不出來。
第二步。當我們的組件化的腳步越走越遠的時候，我們出于多方面的考慮可能有以下需求。
開發時重復編譯是痛點。我們可能更希望提供的是二進制版本，節省下大量的編譯耗時；
我們可能要做權限管理。有時候一個公司業務和人員規模都非常龐大。我們基礎庫設計到跨業務，跨APP使用。我們希望不同團隊有不同基礎組件的讀寫權限。那么我們更可能偏向提供二進制庫加文檔的形式。
綜上： 由于使用Swift開發ABI不兼容問題更易出現。在組件化的項目中，不建議使用Swift或者混編。
動態庫過多問題
上面說到的問題（麻煩）其實是帶給開發者的麻煩，但是動態庫多了會給用戶帶來麻煩（APP啟動耗時）。用了混編的項目我們在Podfile里面勢必要寫use_framework！，上篇文章中我們也說到用了這個指令。CocoaPods會幫我們把所有的庫全部編譯為動態庫。這些動態庫是在APP啟動時做去加載的。我們在組件化的時候，自己的業務組件馬上接近上百個。可以預想到以后隨著組件化的越來越深入，這些庫會越來越多。這個時間可能會達到1s的量級。對于用戶 這是不可接受的。關于動態庫過多導致的啟動慢的問題請參考文后的參考鏈接。
結合公司目前的情況的解決方案
我們公司目前的情況： Swift第三方庫個別，混編組件個別。既然都是個別的，我們總不能因為這些個別的特殊case讓APP原本的1個二進制文件變成 1個二進制文件+上百個動態庫framework。這肯定是不合理的。
解決辦法
不使用Swift，包括第三方庫和混編組件
部分組件（含有Swift）動態庫化，其他部分仍舊整合進app的二進制中
首先來看辦法1直觀感覺是不合適。首先很多公司的項目在做組件化的時候項目已經達到一定程度（沒有一定規模也沒必要做組件化），這就意味著大部分APP是有歷史包袱的。首先重寫這些已有的組件或者功能肯定是有風險的，在公司業務多。用戶量大的情況下，影響面會更大，雖然這樣是一勞永逸的，但是同時風險是更大的。我們在做組件化的工作中，改善大家開發的痛點，提高開發效率才是主要目標。至于重構甚至重寫則是業務方的重心。
第二種辦法就是做到部分組件動態庫化。
我們來回憶下靜態庫的特點。靜態庫和主工程鏈接的時候會把庫里面的代碼復制到可執行文件中。對于這部分符號在APP啟動時會省去load，rebase ，binding的時間。那么在iOS平臺中嵌入式動態庫的特點是不把庫里面的代碼復制到可執行文件中，而是單獨復制到APP里面的frameworks路徑下。所以通常來說動態庫節省內存。在iOS平臺上做不到。靜態庫的缺點是會讓APP安裝包增大。那么我們自己做的嵌入式動態庫也會有這個問題。并且還會導致APP啟動變慢。那豈不是優點變成了缺點~~。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%