** 注意：本文并非原創(chuàng)文章，轉(zhuǎn)載自（原創(chuàng))：https://blog.cnbluebox.com/blog/2015/11/28/module-and-decoupling/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io **
** 前些天讀到這篇文章，印象中感覺這篇文章簡短精煉，所以今天重新翻出來分享給大家！ **

簡述

本文主要講述了在iOS開發(fā)過程中，模塊化工程架構(gòu)的一種組織方式，本文主要講述基于cocoapods來做模塊化的方案，詳細講述了iOS開發(fā)怎么進行模塊劃分的內(nèi)容，主要會在以下方面做闡述：

• 為什么要做模塊化
• 模塊設(shè)計原則
• 模塊化開發(fā)有哪些優(yōu)點和缺點
• 解耦與通信

1.為什么要做模塊化？

我們都知道最基本的代碼設(shè)計原則：“Don’t repeat yourself!”，每一個工程都會有自己的架構(gòu)，即使你是剛?cè)腴T的開發(fā)者，寫幾天代碼也會發(fā)現(xiàn)要把一些常用到的重復(fù)代碼單獨拿出來放在一個叫common的地方，實現(xiàn)代碼復(fù)用。這樣看來每個開發(fā)者其實都或多或少的做過架構(gòu)方面的事情，每個團隊至少有1~2個人在做這樣的事情。

說到app代碼架構(gòu)，記得Samurai的開發(fā)者郭虹宇在群里說過這段精辟的話，引用一下:
一派是說app開發(fā)并不需要什么狗P架構(gòu)，第二派說我們有自己NB的架構(gòu)，第三派說只要模塊化夠好，每個模塊應(yīng)該有自己的架構(gòu)。

這三個觀點的出發(fā)點，我覺得也比較好理解，第一種應(yīng)該是一些個人開發(fā)者，個人能力很強，經(jīng)常一個人很快搞出來一個app，他的映像中不需要弄太多的框框框住自己，但是其實他也是有一套自己的架構(gòu)的。第二派應(yīng)該是一些公司或者大公司，有一套NB的架構(gòu)對于團隊的意義就比較大了，可以保證穩(wěn)定迭代，保證規(guī)范和持久可維護性。第三派應(yīng)該是BAT這樣的有很多BU的超級公司，或者一些先進的開源開發(fā)者們，模塊化能夠更好的實現(xiàn)跨app的代碼和功能的復(fù)用, 能夠更好的共享資源，避免重復(fù)造輪子。

那么為什么要做模塊化？已經(jīng)很明顯了，模塊化的代碼框架最屌，不信，看看蘋果的框架怎么做的，你就明白了。

2. 模塊設(shè)計原則

既然模塊化最屌，那怎么才能做好project的模塊化拆分呢，哪些代碼應(yīng)該被放到一個模塊？這里分享一些我的經(jīng)驗。
*** 越底層的模塊，應(yīng)該越穩(wěn)定，越抽象，越具有高復(fù)用度。 ***

這一點，目測大家應(yīng)該比較認同，越是底層的SDK，就應(yīng)該越穩(wěn)定，穩(wěn)定的最直觀表現(xiàn)就是API很久都不用變化，所有的變化因子不要暴露出來，避免傳遞給依賴它的模塊。但是要做到設(shè)計一套API很久都不用改變，那么就需要設(shè)計的時候能越抽象, 即需要我們抽象總結(jié)的能力。

穩(wěn)定性 還有一個特點就是會傳遞，比如 B 模塊依賴了 A 模塊，如果 B 模塊很穩(wěn)定，但是 A 模塊不穩(wěn)定，那么B模塊也會變的不穩(wěn)定了，因此下一個原則：
*** 不要讓穩(wěn)定的模塊依賴不穩(wěn)定的模塊， 減少依賴。 ***

既然上面說最好不要依賴，但是我發(fā)現(xiàn)我的 B 模塊的確依賴了 A 模塊里面不可或缺的代碼怎么辦？ 假設(shè)依賴的代碼段為 x , 現(xiàn)在來看x的特性, 如果X是一個可能高復(fù)用的代碼段，那么無妨把x從 A 模塊里面拿出來，單做成一個模塊 X, 那么 B 模塊依賴 X 模塊就好了；靈一種情況，x是一個方法或函數(shù)，而且不太適合單做成一個模塊，所以那就在B模塊里面拷貝一份 x 代碼就ok了，因為這樣可以保證模塊的 穩(wěn)定性 和 自完備性。
如果上面兩種方法都不太合適，我們會在后面解耦里面講到如何解耦。
*** 提升模塊的復(fù)用度，自完備性有時候要優(yōu)于代碼復(fù)用。 ***

什么是自完備性，就是盡可能的依賴少的模塊來達到代碼可復(fù)用。
舉個例子，我有個模塊 Utils 里面放了大量的category工具方法等，在日常UI產(chǎn)品開發(fā)中，依賴這個Utils會很方便，但是我現(xiàn)在要寫一個比較基礎(chǔ)的模塊，應(yīng)該就要求復(fù)用度更高一些，這個時候需要用到Utils里面的幾個方法，那這個時候還適合直接依賴Utils嗎，當然不合適了，這與我們上面的設(shè)計原則相悖了啊，因此我們這時候為了這個模塊的自完備性，就可以重新實現(xiàn)下這幾個方法，而不是依賴Utils模塊。
*** 每個模塊只做好一件事情，不要讓Common出現(xiàn)。 ***

模塊化結(jié)構(gòu)是讓工程結(jié)構(gòu)更清晰，每個模塊都只做一件事情，都有自己的一個命名，這樣這個模塊才能良性發(fā)展， 但是這個名字千萬不要再叫Common了，試想下你有沒有做過這樣的事情：“哎呀，這塊代碼放哪都不太合適，放Common吧”， 日久以后，這個Common就變成了毒瘤，大家都依賴它，還一堆不相關(guān)的代碼，這個Common模塊就是我們設(shè)計原則第一點的反面教材： “非常不穩(wěn)定，大量依賴，全是耦合，整個模塊無法復(fù)用到其他app”, 所以刪掉工程里面的Common吧，再遇到不知道放哪的代碼，就要好好思考模塊的設(shè)計，再不行如果具有可復(fù)用性就單建一個模塊吧，為什么不可以呢？
按照你架構(gòu)的層數(shù)從上到下依賴，不要出現(xiàn)下層模塊依賴上層模塊的現(xiàn)象。
業(yè)務(wù)模塊之間也盡量不要耦合。

3. 模塊化開發(fā)有哪些優(yōu)點和缺點

優(yōu)點： 1、不只提高了代碼的復(fù)用度，還可以實現(xiàn)真正的功能復(fù)用，比如同樣的功能模塊如果實現(xiàn)了自完備性，可以在多個app中復(fù)用 2、業(yè)務(wù)隔離，跨團隊開發(fā)代碼控制和版本風險控制的實現(xiàn) 3、模塊化對代碼的封裝性、合理性都有一定的要求，提升開發(fā)同學(xué)的設(shè)計能力。

缺點：模塊化當然也有它的缺點： 1、入門門檻較高，新手入門需要的成本也更高 2、工具的使用成本，團隊間和模塊間的配合成本升高，開發(fā)效率短期會降低。

但是從長期的影響來說，帶來的好處遠大于壞處的，因此模塊化仍然是最佳的架構(gòu)選擇。

4. 解耦與通信

我先說說為什么要解耦吧，模塊化并不是說你把工程的代碼拆分成 50 個 pod 或者framework就算完事了，要實現(xiàn)模塊之間真正的解耦才算真正的模塊化，否則如果模塊之間還都是互相調(diào)用代碼，循環(huán)依賴，那么和原本放文件夾里面沒啥兩樣。那么什么是模塊間的解耦呢？
*** 模塊解耦的目標就是, 在基于模塊設(shè)計原則上, 讓模塊之間沒有循環(huán)依賴, 讓業(yè)務(wù)模塊之間解除依賴。 ***

4.1 公共模塊下沉

這塊其實還是講的模塊設(shè)計，一個工程的架構(gòu)可能會分為很多層，然而在開發(fā)的過程中，很容易有人不注意讓應(yīng)該處于較底層的模塊依賴了上層的模塊，這種情況下應(yīng)該對模塊的設(shè)計進行改造實現(xiàn)單向依賴。

比如一個常見的普遍的例子： 一個公共的WebView模塊，里面可能有WebViewController的基類，然后還有JSBridge的服務(wù)，如果設(shè)計的時候沒有注意，很容易在開發(fā)過程中，這個模塊被塞入大量的其他業(yè)務(wù)代碼，依賴了一大堆業(yè)務(wù)模塊，因為經(jīng)常注冊JSBridge服務(wù)需要跟業(yè)務(wù)耦合。

這個時候怎么做呢，首先我們要思考WebView模塊的定位，從更全局的角度思考，每個app的架構(gòu)應(yīng)該都需要這樣一個模塊，那么我們完全可以把這個模塊單獨拎出來下沉為基礎(chǔ)模塊，這個時候的解耦就需要你對WebView模塊做出一些設(shè)計，添加一些注冊型Api，修改JSBridge的服務(wù)為可以通過注冊的方式添加邏輯，這樣來實現(xiàn)與業(yè)務(wù)解耦，業(yè)務(wù)完全可以把與自己業(yè)務(wù)相關(guān)的代碼放在自己的模塊里面，然后通過你設(shè)計的Api注冊到WebView模塊中。

4.2 面向接口調(diào)用

雖然說公共模塊可以通過架構(gòu)設(shè)計來避免耦合業(yè)務(wù)，但是業(yè)務(wù)模塊之間還是會有耦合的啊，而且這種情況是最多的，比如頁面跳轉(zhuǎn)啊，數(shù)據(jù)傳遞啊，這些情況前面的方法已經(jīng)不夠用了。那如何解耦不同業(yè)務(wù)模塊之間的代碼調(diào)用呢？

那就是面向接口調(diào)用，我們知道只要直接引用代碼，就會有依賴，比如：

// A 模塊
- (void)getSomeDataFromB { 
    B.getSomeData();
}

// B 模塊
- (void)getSomeData { 
    return self.data;
}

那么我們可以實現(xiàn)一個 getSomeDataFromB 的接口，讓 A 只依賴這個接口，而 B 來實現(xiàn)這個接口，這樣就實現(xiàn)了 A 與 B 的解耦。

// 接口
@protocol BService <NSObject>
- (void)getSomeData;
@end

// A 模塊, 只依賴接口
- (void)getSomeDataFromB { 
    id b = findService(@protocol(BService)); 
    b.getSomeData;
}

// B 模塊，實現(xiàn)BService接口
@interface B : NSObject <BService>
- (void)getSomeData {
    return self.data;
}

這樣就可以實現(xiàn)了即滿足了模塊之間調(diào)用，也實現(xiàn)了解耦。

優(yōu)點：

• 1、接口類似代碼，可以非常靈活的定義函數(shù)和回調(diào)等。

缺點：

• 1、接口定義文件需要放在一個模塊以供依賴，但是這個模塊不回貢獻代碼，所以還好。
• 2、使用較為麻煩，每各調(diào)用都需要定義一個service，并實現(xiàn), 對于一些具有普適性規(guī)律的場景不太合適，比如頁面統(tǒng)一跳轉(zhuǎn)。

4.3 面向協(xié)議調(diào)用

面向接口調(diào)用的缺點導(dǎo)致并不能滿足所有的需求，也解耦的不夠徹底，那么終極手段就是通過定義一套協(xié)議來實現(xiàn)模塊間的通信，協(xié)議現(xiàn)成的，那就是URL跳轉(zhuǎn)協(xié)議，基本滿足需要，簡單易上手，基本上現(xiàn)在很多的App架構(gòu)里面都會有“統(tǒng)一跳轉(zhuǎn)” 這一套東西的，這個不光是對模塊解耦有幫助，對于統(tǒng)一化運營都是有極好的幫助的，比如app里面的任何頁面，或者任何操作都是通過一個URL來喚起的話，這樣是不是就把各個復(fù)雜的業(yè)務(wù)之間解耦了呢，通信都使用URL。

5. 源碼推薦

說了這么多，也要放點干貨吧，下面給出2個庫的介紹，對你模塊化的進程希望有幫助。
1、** JLRoutes** 是一個URL跳轉(zhuǎn)協(xié)議支持的庫，跟我想要的簡直很契合，強烈推薦。
2、 我自己寫的一個解耦框架 AppLord. 簡單介紹一下幾個概念。

• Module 是負責管理啟動模塊的工具，可以幫助你把AppDelegate里面一坨初始化的代碼分別放到不同的module里面去
• Service 就是對上面 4.2 中面向接口解耦方式的一種封裝
• Task, 全局的后臺任務(wù)管理器，有時候一些不知道放哪的任務(wù)執(zhí)行可以塞進去

文／VV木公子（簡書作者）
PS:如非特別說明，所有文章均為原創(chuàng)作品，著作權(quán)歸作者所有，轉(zhuǎn)載轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，并注明出處，所有打賞均歸本人所有！

如果您是iOS開發(fā)者，或者對本篇文章感興趣，請關(guān)注本人，后續(xù)會更新更多相關(guān)文章！敬請期待！