簡述
本文主要講述了在iOS開發(fā)過程中，模塊化工程架構(gòu)的一種組織方式，本文主要講述基于cocoapods來做模塊化的方案，詳細(xì)講述了iOS開發(fā)怎么進(jìn)行模塊劃分的內(nèi)容，主要會(huì)在以下方面做闡述：
為什么要做模塊化
模塊設(shè)計(jì)原則
模塊化開發(fā)有哪些優(yōu)點(diǎn)和缺點(diǎn)
解耦與通信
1.為什么要做模塊化？
我們都知道最基本的代碼設(shè)計(jì)原則：“Don’t repeat yourself!”，每一個(gè)工程都會(huì)有自己的架構(gòu)，即使你是剛?cè)腴T的開發(fā)者，寫幾天代碼也會(huì)發(fā)現(xiàn)要把一些常用到的重復(fù)代碼單獨(dú)拿出來放在一個(gè)叫common的地方，實(shí)現(xiàn)代碼復(fù)用。這樣看來每個(gè)開發(fā)者其實(shí)都或多或少的做過架構(gòu)方面的事情，每個(gè)團(tuán)隊(duì)至少有1~2個(gè)人在做這樣的事情。
說道app代碼架構(gòu)，記得Samurai的開發(fā)者郭虹宇在群里說過這段精辟的話，引用一下:
一派是說app開發(fā)并不需要什么狗P架構(gòu)，第二派說我們有自己NB的架構(gòu)，第三派說只要模塊化夠好，每個(gè)模塊應(yīng)該有自己的架構(gòu)。
這三個(gè)觀點(diǎn)的出發(fā)點(diǎn)，我覺得也比較好理解，第一種應(yīng)該是一些個(gè)人開發(fā)者，個(gè)人能力很強(qiáng)，經(jīng)常一個(gè)人很快搞出來一個(gè)app，他的映像中不需要弄太多的框框框住自己，但是其實(shí)他也是有一套自己的架構(gòu)的。第二派應(yīng)該是一些公司或者大公司，有一套NB的架構(gòu)對(duì)于團(tuán)隊(duì)的意義就比較大了，可以保證穩(wěn)定迭代，保證規(guī)范和持久可維護(hù)性。第三派應(yīng)該是BAT這樣的有很多BU的超級(jí)公司，或者一些先進(jìn)的開源開發(fā)者們，模塊化能夠更好的實(shí)現(xiàn)跨app的代碼和功能的復(fù)用, 能夠更好的共享資源，避免重復(fù)造輪子。
那么為什么要做模塊化？已經(jīng)很明顯了，模塊化的代碼框架最屌，不信，看看蘋果的框架怎么做的，你就明白了。
2. 模塊設(shè)計(jì)原則
既然模塊化最屌，那怎么才能做好project的模塊化拆分呢，哪些代碼應(yīng)該被放到一個(gè)模塊？這里分享一些我的經(jīng)驗(yàn)。
越底層的模塊，應(yīng)該越穩(wěn)定，越抽象，越具有高復(fù)用度。
這一點(diǎn)，目測(cè)大家應(yīng)該比較認(rèn)同，越是底層的SDK，就應(yīng)該越穩(wěn)定，穩(wěn)定的最直觀表現(xiàn)就是API很久都不用變化，所有的變化因子不要暴露出來，避免傳遞給依賴它的模塊。但是要做到設(shè)計(jì)一套API很久都不用改變，那么就需要設(shè)計(jì)的時(shí)候能越抽象, 即需要我們抽象總結(jié)的能力。
穩(wěn)定性還有一個(gè)特點(diǎn)就是會(huì)傳遞，比如 B 模塊依賴了 A 模塊，如果 B 模塊很穩(wěn)定，但是 A 模塊不穩(wěn)定，那么B模塊也會(huì)變的不穩(wěn)定了，因此下一個(gè)原則：
不要讓穩(wěn)定的模塊依賴不穩(wěn)定的模塊， 減少依賴
既然上面說最好不要依賴，但是我發(fā)現(xiàn)我的 B 模塊的確依賴了 A 模塊里面不可或缺的代碼怎么辦？ 假設(shè)依賴的代碼段為 x , 現(xiàn)在來看x的特性, 如果X是一個(gè)可能高復(fù)用的代碼段，那么無妨把x從 A 模塊里面拿出來，單做成一個(gè)模塊 X, 那么 B 模塊依賴 X 模塊就好了；靈一種情況，x是一個(gè)方法或函數(shù)，而且不太適合單做成一個(gè)模塊，所以那就在B模塊里面拷貝一份 x 代碼就ok了，因?yàn)檫@樣可以保證模塊的穩(wěn)定性和自完備性.
如果上面兩種方法都不太合適，我們會(huì)在后面解耦里面講到如何解耦
提升模塊的復(fù)用度，自完備性有時(shí)候要優(yōu)于代碼復(fù)用
什么是自完備性，就是盡可能的依賴少的模塊來達(dá)到代碼可復(fù)用。
舉個(gè)例子，我有個(gè)模塊Utils里面放了大量的category工具方法等，在日常UI產(chǎn)品開發(fā)中，依賴這個(gè)Utils會(huì)很方便，但是我現(xiàn)在要寫一個(gè)比較基礎(chǔ)的模塊，應(yīng)該就要求復(fù)用度更高一些，這個(gè)時(shí)候需要用到Utils里面的幾個(gè)方法，那這個(gè)時(shí)候還適合直接依賴Utils嗎，當(dāng)然不合適了，這與我們上面的設(shè)計(jì)原則相悖了啊，因此我們這時(shí)候?yàn)榱诉@個(gè)模塊的自完備性，就可以重新實(shí)現(xiàn)下這幾個(gè)方法，而不是依賴Utils模塊
每個(gè)模塊只做好一件事情，不要讓Common出現(xiàn)
模塊化結(jié)構(gòu)是讓工程結(jié)構(gòu)更清晰，每個(gè)模塊都只做一件事情，都有自己的一個(gè)命名，這樣這個(gè)模塊才能良性發(fā)展， 但是這個(gè)名字千萬不要再叫Common了，試想下你有沒有做過這樣的事情：“哎呀，這塊代碼放哪都不太合適，放Common吧”， 日久以后，這個(gè)Common就變成了毒瘤，大家都依賴它，還一堆不相關(guān)的代碼，這個(gè)Common模塊就是我們?cè)O(shè)計(jì)原則第一點(diǎn)的反面教材： “非常不穩(wěn)定，大量依賴，全是耦合，整個(gè)模塊無法復(fù)用到其他app”, 所以刪掉工程里面的Common吧，再遇到不知道放哪的代碼，就要好好思考模塊的設(shè)計(jì)，再不行如果具有可復(fù)用性就單建一個(gè)模塊吧，為什么不可以呢？
按照你架構(gòu)的層數(shù)從上到下依賴，不要出現(xiàn)下層模塊依賴上層模塊的現(xiàn)象
業(yè)務(wù)模塊之間也盡量不要耦合
3. 模塊化開發(fā)有哪些優(yōu)點(diǎn)和缺點(diǎn)
優(yōu)點(diǎn)： 1、不只提高了代碼的復(fù)用度，還可以實(shí)現(xiàn)真正的功能復(fù)用，比如同樣的功能模塊如果實(shí)現(xiàn)了自完備性，可以在多個(gè)app中復(fù)用 2、業(yè)務(wù)隔離，跨團(tuán)隊(duì)開發(fā)代碼控制和版本風(fēng)險(xiǎn)控制的實(shí)現(xiàn) 3、模塊化對(duì)代碼的封裝性、合理性都有一定的要求，提升開發(fā)同學(xué)的設(shè)計(jì)能力。
缺點(diǎn),模塊化當(dāng)然也有它的缺點(diǎn)： 1、入門門檻較高，新手入門需要的成本也更高 2、工具的使用成本，團(tuán)隊(duì)間和模塊間的配合成本升高，開發(fā)效率短期會(huì)降低。
但是從長期的影響來說，帶來的好處遠(yuǎn)大于壞處的，因此模塊化仍然是最佳的架構(gòu)選擇。
4. 解耦與通信
我先說說為什么要解耦吧，模塊化并不是說你把工程的代碼拆分成 50 個(gè) pod 或者framework就算完事了，要實(shí)現(xiàn)模塊之間真正的解耦才算真正的模塊化，否則如果模塊之間還都是互相調(diào)用代碼，循環(huán)依賴，那么和原本放文件夾里面沒啥兩樣。那么什么是模塊間的解耦呢？
模塊解耦的目標(biāo)就是, 在基于模塊設(shè)計(jì)原則上, 讓模塊之間沒有循環(huán)依賴, 讓業(yè)務(wù)模塊之間解除依賴。
4.1 公共模塊下沉
這塊其實(shí)還是講的模塊設(shè)計(jì)，一個(gè)工程的架構(gòu)可能會(huì)分為很多層，然而在開發(fā)的過程中，很容易有人不注意讓應(yīng)該處于較底層的模塊依賴了上層的模塊，這種情況下應(yīng)該對(duì)模塊的設(shè)計(jì)進(jìn)行改造實(shí)現(xiàn)單向依賴。
比如一個(gè)常見的普遍的例子： 一個(gè)公共的WebView模塊，里面可能有WebViewController的基類，然后還有JSBridge的服務(wù)，如果設(shè)計(jì)的時(shí)候沒有注意，很容易在開發(fā)過程中，這個(gè)模塊被塞入大量的其他業(yè)務(wù)代碼，依賴了一大堆業(yè)務(wù)模塊，因?yàn)榻?jīng)常注冊(cè)JSBridge服務(wù)需要跟業(yè)務(wù)耦合。
這個(gè)時(shí)候怎么做呢，首先我們要思考WebView模塊的定位，從更全局的角度思考，每個(gè)app的架構(gòu)應(yīng)該都需要這樣一個(gè)模塊，那么我們完全可以把這個(gè)模塊單獨(dú)拎出來下沉為基礎(chǔ)模塊，這個(gè)時(shí)候的解耦就需要你對(duì)WebView模塊做出一些設(shè)計(jì)，添加一些注冊(cè)型Api，修改JSBridge的服務(wù)為可以通過注冊(cè)的方式添加邏輯，這樣來實(shí)現(xiàn)與業(yè)務(wù)解耦，業(yè)務(wù)完全可以把與自己業(yè)務(wù)相關(guān)的代碼放在自己的模塊里面，然后通過你設(shè)計(jì)的Api注冊(cè)到WebView模塊中。
4.2 面向接口調(diào)用
雖然說公共模塊可以通過架構(gòu)設(shè)計(jì)來避免耦合業(yè)務(wù)，但是業(yè)務(wù)模塊之間還是會(huì)有耦合的啊，而且這種情況是最多的，比如頁面跳轉(zhuǎn)啊，數(shù)據(jù)傳遞啊，這些情況前面的方法已經(jīng)不夠用了。那如何解耦不同業(yè)務(wù)模塊之間的代碼調(diào)用呢？
那就是面向接口調(diào)用，我們知道只要直接引用代碼，就會(huì)有依賴，比如：
123456789
// A 模塊-(void)getSomeDataFromB{B.getSomeData();}// B 模塊-(void)getSomeData{returnself.data;}
那么我們可以實(shí)現(xiàn)一個(gè)getSomeDataFromB的接口，讓 A 只依賴這個(gè)接口，而 B 來實(shí)現(xiàn)這個(gè)接口，這樣就實(shí)現(xiàn)了 A 與 B 的解耦。
12345678910111213141516171819
// 接口@protocolBService-(void)getSomeData;@end// A 模塊, 只依賴接口-(void)getSomeDataFromB{idb=findService(@protocol(BService));b.getSomeData;}// B 模塊，實(shí)現(xiàn)BService接口@interfaceB:NSObject-(void)getSomeData{returnself.data;}@end
這樣就可以實(shí)現(xiàn)了即滿足了模塊之間調(diào)用，也實(shí)現(xiàn)了解耦
優(yōu)點(diǎn)：
1、接口類似代碼，可以非常靈活的定義函數(shù)和回調(diào)等。
缺點(diǎn)：
1、接口定義文件需要放在一個(gè)模塊以供依賴，但是這個(gè)模塊不回貢獻(xiàn)代碼，所以還好。
2、使用較為麻煩，每各調(diào)用都需要定義一個(gè)service，并實(shí)現(xiàn), 對(duì)于一些具有普適性規(guī)律的場(chǎng)景不太合適，比如頁面統(tǒng)一跳轉(zhuǎn)
4.3 面向協(xié)議調(diào)用
面向接口調(diào)用的缺點(diǎn)導(dǎo)致并不能滿足所有的需求，也解耦的不夠徹底，那么終極手段就是通過定義一套協(xié)議來實(shí)現(xiàn)模塊間的通信，協(xié)議現(xiàn)成的，那就是URL跳轉(zhuǎn)協(xié)議，基本滿足需要，簡單易上手，基本上現(xiàn)在很多的App架構(gòu)里面都會(huì)有“統(tǒng)一跳轉(zhuǎn)” 這一套東西的，這個(gè)不光是對(duì)模塊解耦有幫助，對(duì)于統(tǒng)一化運(yùn)營都是有極好的幫助的，比如app里面的任何頁面，或者任何操作都是通過一個(gè)URL來喚起的話，這樣是不是就把各個(gè)復(fù)雜的業(yè)務(wù)之間解耦了呢，通信都使用URL.
5. 源碼推薦
說了這么多，也要放點(diǎn)干貨吧，下面給出2個(gè)庫的介紹，對(duì)你模塊化的進(jìn)程希望有幫助。
1、JLRoutes是一個(gè)URL跳轉(zhuǎn)協(xié)議支持的庫，跟我想要的簡直很契合，強(qiáng)烈推薦。
2、 我自己寫的一個(gè)解耦框架AppLord. 簡單介紹一下幾個(gè)概念
* Module 是負(fù)責(zé)管理啟動(dòng)模塊的工具，可以幫助你把AppDelegate里面一坨初始化的代碼分別放到不同的module里面去
* Service 就是對(duì)上面 4.2 中面向接口解耦方式的一種封裝
* Task, 全局的后臺(tái)任務(wù)管理器，有時(shí)候一些不知道放哪的任務(wù)執(zhí)行可以塞進(jìn)去
