引言：一個(gè)app的初始階段，必然是先滿足各種業(yè)務(wù)需求。然后，經(jīng)過多次版本迭代之后，先前的由于急于滿足需求而導(dǎo)致的雜亂代碼則會(huì)充斥整個(gè)項(xiàng)目。而此時(shí)，項(xiàng)目有了一定的規(guī)模，有了一定數(shù)量的開發(fā)人員，那么為了達(dá)到快速迭代版本的需求，則是需要有一個(gè)強(qiáng)大的架構(gòu)來支撐。
在開始談app架構(gòu)之前，曾經(jīng)我一度認(rèn)為，一個(gè)好的app就是需要有好的架構(gòu)，如果沒有一個(gè)我所認(rèn)為的“好架構(gòu)”，那么這個(gè)app就是很low。
直到去年參加北京ArchSummit時(shí)，聽了無數(shù)的公司他們對(duì)于產(chǎn)品的架構(gòu)之后，我陷入沉思，因?yàn)槲铱傇谧约旱恼J(rèn)知里選出一個(gè)自己認(rèn)為最好的架構(gòu)，然后覺得其他架構(gòu)都是垃圾。
靜下心來想想，每個(gè)產(chǎn)品都有自己不同的定位，如果拋開它們的定位，拋開它們的業(yè)務(wù)需求去談如果給它們?cè)O(shè)計(jì)一個(gè)良好的架構(gòu)，這簡(jiǎn)直是扯淡。
更何況很多優(yōu)秀的app架構(gòu)也是由一開始很弱而慢慢變得越來越強(qiáng)。
所以沒有最好的架構(gòu)，只有適合自己的業(yè)務(wù)的架構(gòu)才是最好的架構(gòu)，并且它是逐步地變強(qiáng)變大。
本文將舉一個(gè)例子來演示這個(gè)過程。
那么，到底什么是架構(gòu)？
架構(gòu)，又名軟件架構(gòu)，是有關(guān)軟件整體結(jié)構(gòu)與組件的抽象描述，用于指導(dǎo)大型軟件系統(tǒng)各個(gè)方面的設(shè)計(jì)。
以我的理解，它就像是人的骨架一般，一個(gè)人從小生長到大，圍繞著整個(gè)骨架去發(fā)展，變高變胖。
可以把a(bǔ)pp開發(fā)看成一個(gè)汽車工廠的流水線，造車身->噴漆->組裝等等。即把整個(gè)開發(fā)流程切成一個(gè)個(gè)模塊，每個(gè)模塊相互獨(dú)立，并發(fā)工作。這就是所謂app架構(gòu)。
沒有架構(gòu)的“架構(gòu)”
某天，一個(gè)叫Jim的開發(fā)者，他打算開發(fā)一個(gè)app，當(dāng)然有一定計(jì)算機(jī)基礎(chǔ)的他知道采用MVC的設(shè)計(jì)模式來構(gòu)造app，于是一個(gè)星期后，終于能跑起來一個(gè)app，但是此時(shí)，看一下項(xiàng)目的目錄結(jié)構(gòu)：
嗯，不錯(cuò)，我們不但能run，還能看出這個(gè)app用了MVC的設(shè)計(jì)模式耶。
但是隨著開發(fā)的頁面越來越多，一個(gè)月后，app有了10個(gè)頁面，此時(shí)，打開Controller、View、Model這三個(gè)文件夾之后，發(fā)現(xiàn)每個(gè)文件夾里面竟然有幾十個(gè)文件，它們雜亂無章的灑落在一起。此時(shí)不斷有用戶向Jim反映，xxx地方怎么按鈕位置不對(duì)，xxx位置網(wǎng)絡(luò)請(qǐng)求不成功。
頭痛的Jim才知道，當(dāng)初應(yīng)該把粒度分的更細(xì)，于是又了接下來的架構(gòu)。
分模塊的架構(gòu)
Jim把不同的功能模塊放在一塊兒，于是得到了如下的架構(gòu)：
但是不對(duì)，一些工具類，公用類該放哪呢？Jim仔細(xì)思索了一番，于是又將上述架構(gòu)進(jìn)行改進(jìn)，得到以下的架構(gòu)：
嗯，這看起來才像樣嘛。
Cocoapods
慢慢地，Jim發(fā)現(xiàn)網(wǎng)上有很多可以現(xiàn)成拿來用的第三方框架，而他同時(shí)也學(xué)習(xí)了Cocoapods這個(gè)神器。
什么是Cocoapods：
CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over eighteen thousand libraries and can help you scale your projects elegantly.
它是一個(gè)能讓你方便地管理第三方庫的一個(gè)工具。
于是，項(xiàng)目變成了這樣：
此時(shí)的架構(gòu)已經(jīng)滿足了個(gè)人開發(fā)者，或者說是小型開發(fā)團(tuán)隊(duì)的需求了。
多人開發(fā)的架構(gòu)
但是在一個(gè)初具規(guī)模的公司，上述的架構(gòu)模式是遠(yuǎn)遠(yuǎn)不行的，試想一下，如果有20個(gè)人同時(shí)開發(fā)一個(gè)app，而此時(shí)大家就算各自負(fù)責(zé)自己的模塊，如果同時(shí)有不同模塊的同學(xué)添加或者刪除文件，對(duì)于.xcodeproj文件來說，會(huì)有嚴(yán)重的沖突。
那么，怎么辦呢？
想一下cocoapods的作用吧，其實(shí)利用它能做很多很多事，我們完全可以把Home、Detail、Login等模塊抽出來，也把它視為“第三方庫”（實(shí)際上可以算是二方庫）。初期階段可以這么做：
可以看到我們把
Home這個(gè)模塊抽出來了。這么做有什么好處？
如果我們把各個(gè)業(yè)務(wù)模塊都抽出來，首先來說，可以解決沖突的問題，并且業(yè)務(wù)團(tuán)隊(duì)之間的工作不受影響，并且可以并行開發(fā)，也無需再等待其他兄弟業(yè)務(wù)團(tuán)隊(duì)的進(jìn)度了。
當(dāng)其他業(yè)務(wù)團(tuán)隊(duì)的任務(wù)完成時(shí)，我們只需
pod update，將代碼升級(jí)到最新就可以了。并且當(dāng)一個(gè)公司有多個(gè)app時(shí)，如果有公用的模塊，用這種方式會(huì)更優(yōu)雅。
當(dāng)然，如果你覺得直接指定git地址太low，你完全可以搞一個(gè)私有Spec，專門存放業(yè)務(wù)模塊代碼。
子project模式的架構(gòu)
很多人會(huì)說上述方式很復(fù)雜，還不如采用在主工程下中放子工程（業(yè)務(wù)模塊）來實(shí)現(xiàn)抽象：
但是我覺得這個(gè)方式管理起項(xiàng)目很麻煩，更新模塊代碼、不同app間復(fù)用模塊代碼都會(huì)沒上述的方式優(yōu)雅，所以我覺得這種方式?jīng)]有上述的好。
對(duì)各個(gè)模塊進(jìn)行解耦
現(xiàn)在雖然我們對(duì)各個(gè)模塊進(jìn)行了抽象，但是業(yè)務(wù)模塊間還是互相引用，對(duì)于開發(fā)來說，雖然解決了代碼的耦合問題，對(duì)于代碼的引用關(guān)系卻沒有改變：
上圖才只有4個(gè)模塊，如果有上百個(gè)模塊的話，這個(gè)關(guān)系可以復(fù)雜成一個(gè)龐大的蜘蛛網(wǎng)，這對(duì)于后期維護(hù)來說，成本是巨大的。
所以我們想，有木有好的方式來解耦呢，當(dāng)然是有的，我覺得以下兩個(gè)方式是很好的：
- middleman
- urlRoute
先來介紹middleman（中間人模式）
如圖所示，我們只需將所有的模塊依賴這個(gè)middleman，讓middleman來處理各個(gè)模塊的關(guān)系，模塊A如果需要依賴模塊B，完全可以考middleman來處理，并且返回模塊A所需要的模塊B的內(nèi)容，這樣就解決了解耦。
再來說說urlRoute，其實(shí)這個(gè)方式類似于Facebook很早前的320結(jié)構(gòu)了。
思路就是將每個(gè)頁面看成是一個(gè)url，設(shè)置一套路由規(guī)則，在頁面打開時(shí)將url進(jìn)行路由查找，然后這樣一來，只要模塊A按照既定的規(guī)則寫好url，那么模塊B依賴模塊A時(shí)，只需根據(jù)url打開就行了。
middleman VS urlRoute
兩種方式各自有自己的優(yōu)點(diǎn)和缺點(diǎn)，他們主要的區(qū)別在于：
- 傳參的方式
- 所需維護(hù)的具體內(nèi)容不同
我更傾向于urlRoute，為什么這么說呢？
由于本文講的是app架構(gòu)，這里就簡(jiǎn)單介紹下：
如果一個(gè)頁面出現(xiàn)了問題，我們可以用各種patch的方式來打補(bǔ)丁。但是，如果一個(gè)頁面出現(xiàn)了致命的錯(cuò)誤，打patch的成本過于高的話，此時(shí)如果用urlRoute，則有個(gè)妙招。
我們可以更改appConfig（app的配置，可以從服務(wù)端動(dòng)態(tài)更新），更改頁面所對(duì)應(yīng)的url，并且改成在路由規(guī)則里跳到webview的規(guī)則。
這樣之后，當(dāng)跳到此模塊時(shí)，則會(huì)打開對(duì)應(yīng)的H5頁面，而不是原來的有問題的頁面。
當(dāng)然middleman也可以處理成這樣，但是從實(shí)現(xiàn)的角度來說，顯然是urlRoute更為優(yōu)秀。
總結(jié)
當(dāng)然，架構(gòu)遠(yuǎn)遠(yuǎn)不是一篇文章能講清楚的，也不僅僅只是結(jié)構(gòu)層次方面的內(nèi)容，還有例如push、hotpatch、動(dòng)態(tài)化、appConf、Service中間件模塊的具體實(shí)現(xiàn)，MVC\MVVM\MVCS設(shè)計(jì)模式等等。
本文只是從最基礎(chǔ)的地方展現(xiàn)具體業(yè)務(wù)模塊的解耦方式，希望能起到拋磚引玉的作用。
個(gè)人微博：@kuailejim
個(gè)人博客：http://kuailejim.com
