1. 開篇
本文的初衷，是爲了給正在做混編或者模塊化的同學們一個建議和參考。
因爲來餓廠以後做的項目是全公司唯一一個 Swift/OC 混編的 iOS 項目，所以一路上踩坑無數，現在把一些踩坑的過程和經驗總結起來，供大家參考。
相信在瀏覽本文後，一定會有所收穫。
我來的時候項目已經開始 Swift 改造了，慢慢的把項目 Swift 化，新代碼都是 Swift 的。
先公佈七個月成果，下圖是我們最終的項目結構：
對於我們混編的情況，在五個月前大家就展開了討論。
給我們的選擇有兩種：
-
慢慢將 OC 代碼替換成 Swift
-
儘快模塊化，分離兩種語言代碼
一開始我們是從 選擇1 開始做的，但是很快我們就發現，對於我們 74% 都是 OC 代碼的項目來說，太痛了，太漫長了，而且期間迭代的過程中還在不斷地迭代，不斷的耦合。
所以在經過一番利害分析後我們迅速投入到了 選擇2 中。一方面，模塊化本身就是越來越臃腫的項目的最終歸宿，一方面可以慢慢將兩種語言剝離。
2. 模塊劃分
刀怎麼切，是混編模塊化最重要的一步，完全決定了後續工作的難與否。
不用從業務模塊拆分，類似『實時訂單模塊』、『歷史訂單模塊』、『個人中心』這樣直接拆分，保準你後面哭到無法自已。
正確的做法應該從底層部分開始抽離，首先能想到的應該是『類擴展 Extension』、『工具類』、『網絡庫』、『DB 管理』（當然這個我們沒有用到比較重的 DB）。
平常我們看到一些大型庫，或者一些公司介紹自己產品架構時候都是什麼樣的？是不是下層有 OpenGL ES 和 Core Graphics 纔有上層 Core Animation，再到 UIKit。下層決定上層，只有把複用率高的部分抽出才能逐步構建上層業務。
所以首先我們做的就是抽工具類和 Extension，諸如：
-
各類 Constants 文件
-
NSTimer、NSString、UILabel 等等類的 Extension
-
RouterHelper、JavascripInterface 等等 Utils 和 Helper
這一塊的工作，不僅僅可以抽出 OC 代碼，也同時可以抽出 Swift 的代碼。我們將 OC 部分的代碼新建了庫爲 LPDBOCFoundationGarbage，Swift 部分的代碼新建庫爲 LPDBPublicModule。
2.1 LPDBOCFoundationGarbage
先說 LPDBOCFoundationGarbage，叫這個名字顯然不僅僅會放入上面所提到的文件。LPDBOCFoundationGarbage 還會大量放入長期不跟隨業務變動的 OC 代碼。這是因爲，在實踐中，我們發現總是『理想很美好』，雖然大家都抱有把舊代碼整理一遍的願望，但是實際上，我們項目的舊代碼已經到了剪不斷理還亂的地步，所以期望一邊整理、一邊分離的想法基本是不可靠的。這時候就要借用 MM 大佬給我們傳授的一句話『讓噁心的代碼噁心到一起』，LPDBOCFoundationGarbage 正是爲此而創建。
大量放入長期不跟隨業務變動的 OC 代碼包括：
-
自定義的 Customer View，諸如：Refresh 控件、Loading 控件、紅點控件等等
-
自定義的小型控制器，諸如：TextField 和其五六個過濾器 PhoneNumValidator、IDCardValidator 等等
-
不隨業務變動的 Controller，諸如：自定義的 AlertController、自定義的 WebController、自定義的 BaseViewController 等等
關於前綴說兩句。我們所有抽出的庫都帶有前綴 LPDB，但是針對 Swift 庫和 OC 庫稍有區分的是，OC 庫內的文件也都帶有前綴，而 Swift 庫是去掉了前綴，這也符合兩種語言的規範。
2.2 LPDBPublicModule
LPDBPublicModule 情況很簡單，主要是新業務迭代時候產生的一些複用性高的代碼，但是這顯然和 OC 那個垃圾桶庫不一樣，要乾淨整潔的多。主要存放的是：
-
Swift Extension
-
Lotusoot 及其他公開協議
Lotusoot 是個由我開發的模塊化工具和規範，一開始我叫它『路由』，但是隨後發現部門這邊因爲叫它『路由庫』而曲解了它的意思，所以後來我就叫『模塊化工具』了。關於 Lotusoot 將會有另一篇文章。
2.3 LPDBNetwork
這塊毋庸置疑，不管什麼項目都基本有的一塊，基本上我們項目中網絡相關的舊代碼都是 OC 的，唯一比較麻煩的是，我們的網絡層，早期人員寫的比較粗糙，甚至和 UI 層代碼有很多耦合，比如網絡請求中和網絡請求失敗有一些 HUD 顯示，轉轉菊花什麼的。所以導致在從主工程抽離的時候有很多噁心的地方。
所以對於這種強耦合，最後解決的方式是分成了兩遍代碼改造，第一遍先通過反射先將 OC 代碼抽出，保證代碼可用，通過基礎測試。第二遍是通過協議來代替原先的反射。第三遍是使用 Lotusoot 徹底規範服務調用。在後面一節『過程中的一些難點總結』中會介紹
2.4 LPDBUIKit
這塊是 Swift 的 UI 庫，一些比較常用到的控件等等。
2.5 LPDBEnvironment
這塊是用於環境控制的，切換要訪問的服務器環境，這塊本身可以不抽出的，但是由於有其他基礎模塊，比如 LPDBNetwork 依賴，而且其中相關代碼比較多，環境相關的代碼也比較獨立，所以單獨抽出。
3. 業務模塊抽離
到這裏爲止，比較底層的代碼就基本抽出結束了，剩下的就可以較爲輕鬆一些的抽取業務庫了。
抽取業務庫的重點在於：
-
抽取的業務庫不會經常改動，以防止在抽取、重構過程中由於業務需求發生更動
-
抽取的業務庫可以高度獨立，抽取後應當和積木一樣，如 LPDBLoginModule，抽取後快速被集成在任何模塊，並能保證登錄功能，更好的服務其他模塊
我們目前抽出的三個業務模塊分別是： LPDBHistoryModule、LPDBUserCenterModule、LPDBLoginModule。
4. 過程中的一些重難點
剩下的就是，來說一下在這個過程中的疑難問題。
4.1 處理模塊耦合代碼-反射調用
抽取代碼第一遍使用反射的原因主要是，通常你在遞歸某個文件的依賴的時候，會遞歸出非常多的東西（尤其是我們的蜜汁舊代碼），往往就是 A->B->C->D->F，中間有各種依賴，甚至到最後一層的時候還引用了 Swift 的類。直到最後你看 #import 就想吐。
爲什麼沒有辦法一步到位，通過協議解決耦合？
這主要是因爲單個 Pod 庫開發時使用開發模式是很容易調試的，但是兩個 Pod 庫同時在不發版本的情況下使用開發模式是比較難處理的。這種情況下，反覆操作兩個或者兩個以上的庫是麻煩的，所以優先考慮將代碼儘快分離開來，並能通過基本測試，不影響功能。
所以在這一遍處理結束後，子庫中出現了很多 NSClassFromString 等等。
以 LPDBLoginMoudle 爲例：
NSString *className = [NSString stringWithFormat:@"%@.`AuthLoginManager", [NSString targetName]];
id authLoginManager = NSClassFromString(className);
if (![authLoginManager conformsToProtocol:@protocol(authLoginSuccess)]) {
return;
}
[authLoginManager authLoginSuccess];
id delegate = [[UIApplication sharedApplication] delegate];
[delegate jumpToShopListVC:shops];
4.2 處理模塊耦合代碼-協議調用
保持第一遍中充滿 NSClassFromString 是不可取的，因爲這類代碼往往屬於硬編碼，不能在類名出現改動、或者方法名出現改動的時候及時在編譯階段拋出 error。
在這裏引出一段討論。
之前跟大神們討論組件化（模塊化）的具體實踐時候，說到了主流的組件化可能都借用了 + (void)load 方法和 rumtime 操作來註冊路由和服務。這時候 casa 大神提出了一種說法『組件化的根本目的是隔離、隔離問題影響域、隔離業務、隔離開發時的依賴。所以讓兩個本來有關係的人變得沒有關係，就需要一箇中間人，如果不用 runtime 能省掉不少事，如果考慮可維護性，用字符串足夠了，也就是用字符串來表徵方法、方法字典表徵參數，URL 是字符串的更復雜表徵，其本質還是字符串，用 URL 不如用字符串』。
那個時候聽了 casa 大神的說法覺得『哎？好像有點道理』，但是在後期的實踐中，我覺得就我個人的代碼習慣，是希望儘可能的將問題暴露在編譯階段，能讓它拋出 error 就拋出 error，縱使使用字符串可以定義常量，但由於大家不是獨立負責項目，在其他人看到你的方法參數時，比如：+ (void)callService:(NSString *)sUrl 或者 + (void)openURL:(NSString *)url ，對方發現你的參數是 NSStrring，很有可能直接硬編碼字符串而不去查閱常量列表，這是習慣性編碼很容易出現的問題。
最後一點原因是，反射或者通過類/方法字符串字典的方式實在太 OC 了，不管怎麼樣我們是一個儘量 Swift 化的項目，應該儘量吸取其優點，雖然抽出的 OC 庫可以使用反射，那 Swift 庫咋辦？目前 Swift3 與 4 都沒有很好的支持反射。
所以，第二遍處理使用協議替換反射是很有必要的。但實質上，處理的並不是很好。大致如下（我們以 LPDBLoginModule 爲例）：
4.2.1 在 LPDBLoginModule 整理用到的服務，歸類整理
如我們的 LPDBLoginModule 用到了 AppDelegate 中的一些方法，同事用到了 AuthLogin 相關類中的一些方法
4.2.2 在 LPDBLoginModule 中建立相應的協議
即建立 AuthLoginDelegate.h 和 AppDelegateProtocol
大致的代碼如下：
@protocol AppDelegateProtocol <NSObject>
- (void)jumpToHomeVC;
- (void)jumpToShopListVC:(NSArray *)shops;
- (CLLocationCoordinate2D)getCoordinate;
@end
@protocol AuthLoginDelegate <NSObject>[Pods](media/Pods.)
+ (void)authLoginSuccess;
@end
4.2.3 在主工程中去實現協議
AppDelegateProtocol 由 AppDelegate 擴展實現：
@import LPDBLoginModule;
@interface AppDelegate (Protocol) <AppDelegateProtocol>
@end
@implementation AppDelegate (Protocol)
- (CLLocationCoordinate2D)getCoordinate {
...
}
- (void)jumpToHomeVC {
...
}
- (void)jumpToShopListVC:(NSArray *)shops {
...
}
@end
AuthLoginDelegate 由 AuthLoginManager(這個 Manager 在主工程中是 swift 編寫的) 實現：
extension AuthLoginManager: AuthLoginDelegate {
static func authLoginSuccess() {
...
}
}
4.2.4 在 LPDBLoginModule 調用服務
id delegate = [[UIApplication sharedApplication] delegate];
if (![delegate conformsToProtocol:@protocol(AppDelegateProtocol)]) {
return;
}
CLLocationCoordinate2D coordinate = [delegate coordinate];
NSString *className = [NSString stringWithFormat:@"%@.AuthLoginManager", [NSString targetName]];
id authLoginManager = NSClassFromString(className);
if (![authLoginManager conformsToProtocol:@protocol(LPDBAuthLoginDelegate)]) {
return;
}
[authLoginManager authLoginSuccess];
[self jumpToSelectShopView:shops];
但是，可以很明顯感受到，這次的改變並不徹底：
-
還是存在大量的 ![delegate conformsToProtocol:@protocol(AppDelegateProtocol)] 這樣的判斷，僅僅是起到了容錯，保證不會 crash，但是卻不能將問題暴露在編譯階段。
-
AppDelegateProtocol 明明是一個公共的，多個模塊使用的協議，卻被定義到了 LPDBLoginModule
-
概念顛倒，理想狀態下，應該是各個子模塊提供協議和實現，告知其他模塊可以調用該模塊哪些功能。而目前是子模塊告知其他模塊需要調用哪些方法，由其他模塊實現。
那麼爲了徹底解決問題，我們引入了 Lotusoot —— 組件通信和工具。
4.3 處理模塊耦合代碼-Lotusoot
Lotusoot 的最初目的就是爲了解決模塊間的耦合，並且同時支持 OC 和 Swift 使用，也是這幾個月中去做的一個比較重要的東西，庫本身小巧靈活，包含的東西也很少，但是起到的規範作用卻是我非常滿意的一點。
Lotusoot 規範的核心思想主要是以下幾步，我們同樣使用上面的 LPDBLoginModule 爲例：
4.3.1 建立共用模塊——LPDBPublicModule
LPDBPublicModule中定義了各個模塊可以提供的服務，做成協議，稱爲 Lotus，一個 Lotus 協議包含了一個模塊的所有的能調用的方法的列表。舉例如下：
@objc public protocol AppDelegateLotus {
func jumpToHomeVC()
func jumpToSelectShopVC(shops: [Any], isNapos: Bool)
func getCoordinate() -> CLLocationCoordinate2D
}
@objc public protocol MainLotus {
func authLoginSuccess()
}
4.3.2 各個模塊中，實現 LPDBPublicModule 中對應的 Lotus 協議
實現協議的 Class 稱爲 Lotusoot。舉例如下：
class AppDelegateLotusoot: NSObject, AppDelegateLotus {
func jumpToHomeVC() {
...
}
func jumpToSelectShopVC(shops: [Any], isNapos: Bool) {
...
}
func getCoordinate() -> CLLocationCoordinate2D {
...
}
}
class MainLotusoot: NSObject, MainLotus {
func authLoginSuccess() {
...
}
}
4.3.3 註冊服務
需要着重說明的是，這一步是可以省略的，通過 Lotusoot 提供的腳本和註解，可以自動爲所有的路由進行註冊。請移步 Lotusoot參考『3. 註解與規範』部分。
didFinishLaunchingWithOptions 中註冊服務：
[LotusootCoordinator registerWithLotusoot:[AppDelegateLotusoot new] lotusName:@"AppDelegateLotus"];
[LotusootCoordinator registerWithLotusoot:[MainLotusoot new] lotusName:@"MainLotus"];
4.3.3 在其他模塊中調用服務
現在只需要 import Lotusoot、import ModulePublic
id<MainLotus> mainModule = [LotusootCoordinator lotusootWithLotus:@"MainLotus"];
[mainModule authLoginSuccess];
// 如果使用字符串 @"AppDelegateLotus" 註冊，建議定義在 LPDBPublicModule
// 也可以使用 NSStirngFromClass(AppDelegateLotus.class)
id<AppDelegateLotus> appDelegateLotus = [LotusootCoordinator lotusootWithLotus:@"AppDelegateLotus"];
[appDelegateLotus goToHomeVC];
無論 OC 還是 Swift，都可以順暢調用
// 或者使用類似字符串 "AccountLotus"，但需要你管理好 kAccountLotus，儘量不要硬編碼
let appDelegateLotus = s(AppDelegateLotus.self)
let appDelegateLotusoot: AppDelegateLotus = LotusootCoordinator.lotusoot(lotus: appDelegateLotus) as! AppDelegateLotus
accountModule.goToHomeVC()
let mainLotus = s(MainLotus.self)
let mainModule: MainLotus = LotusootCoordinator.lotusoot(lotus: mainLotus) as! MainLotus
mainModule.authLoginSuccess()
到此爲止，就比較完整的解決了模塊間耦合。
LPDBPublicModule 中的 Lotus 協議，像一張清單列出了所有模塊提供的服務聲明，而在各個模塊中，直接通過這些公共協議就可以調用想要的服務。很多問題都可以在編譯前和編譯階段顯示出來（如果模塊不提供服務，是不能通過編譯的；如果沒有一項服務沒有聲明，是不能通過編譯的）。
4.4 語言耦合
我們抽模塊中一個重要的目的就是『分割兩種語言』，但是實踐過程中，會發現，分割語言比分割業務還要難。
一個 Pod 庫中只能包含一種語言，但往往，在抽離代碼的最後，會發現有無數的基礎 Model 耦合，如：
@interface ShopInfo : LPDBModel
...
@property (nullable, nonatomic, strong) DeliveryService *workingProduct;
@property (nullable, nonatomic, strong) DeliveryService *preEffectiveProduct;
@end
class DeliveryService: BaseModel {
...
}
如果需要將 ShopInfo 和 DeliveryService 抽出到一個模塊時，必須要『有舍有得』，在涉及到基礎 Model 語言不同時，可以適當的重寫，因爲 Model 的代碼量是極小的，Model 通常也只包含屬性聲明，作爲數據傳輸的中介，即使更改，產生的不可預支錯誤的可能性也較低。
如果要抽出的模塊主體使用 OC，那麼可以將 DeliveryService 重新用 OC 編寫。
但要注意，要先儘量通過拆分更基礎的服務模塊，在考慮重新編寫文件，保證項目的穩定性。
4.5 模塊的積木化
模塊化的最終目的，不僅僅是去耦，還應當讓每個模塊像積木一樣，隨意拼接，最後達到主工程完全沒有代碼，通過 Pod 集成各個模塊，組成完整的功能。而每個模塊也應當可以獨立測試，獨立開發。
還是以 LPDBLoginModule 和 LPDBNetWort 爲例。
登錄模塊是一個非常特殊的模塊，所有的子模塊如果想獨立測試和開發，一般都需要通過登錄驗證，比如訂單模塊，必須要登錄後，該業務模塊內能才能正確的拉取訂單信息。
由於 LPDBLoginModule 依賴基礎庫 LPDBNetWort，LPDBNetWort 需要做的有：
-
包含 cer 文件，可以正確的提供給其他模塊正常的 https 接口訪問
-
便利的網絡服務調用
而 LPDBLoginModule 至少要做的事有：
-
可以正確的保存登錄信息，完成登錄操作
-
提供登錄的 UI 界面，可以直接調用 LoginVC
在具備以上功能後，LPDBLoginModule 就可以快速的集成進其他模塊，爲其他模塊提供獨立開發、獨立測試的功能。
4.6 資源打包
上一小結提到『 LPDBLoginModule 要提供登錄的 UI 界面』。對於 UI 界面，需要做的是資源打包，在模塊拆分中，要非常注意資源分割。
因爲業務模塊的劃分，不僅僅是是代碼抽出，也有資源抽出。
資源庫包括但不僅限於：
-
.xib 文件
-
聲音資源
-
圖片資源
-
純文本文件
-
視頻資源
所以，所有的資源文件，應當單獨創立 Res 文件夾，放入其中，並在 .podspec 中表明資源文件路徑
s.resources = ["Source/**/*.xib", "Source/Res/*.xcassets"]
注意圖片資源，如果想保留 @2x、@3x，是可以按照 xcassets 的格式直接 copy 過來的。
參考：https://mp.weixin.qq.com/s/StJCJa_e7qCLPJcwEejgS