iOS移動端架構的那些事！（轉載）

一個app的初始階段，必然是先知足各類業務需求。而後，通過屢次版本迭代以後，先前的因爲急於知足需求而致使的雜亂代碼則會充斥整個項目。而此時，項目有了必定的規模，有了必定數量的開發人員，那麼爲了達到快速迭代版本的需求，則是須要有一個強大的架構來支撐。

 

在開始談app架構以前，曾經我一度認爲，一個好的app就是須要有好的架構，若是沒有一個我所認爲的「好架構」，那麼這個app就是很low。

 

直到去年參加北京ArchSummit時，聽了無數的公司他們對於產品的架構以後，我陷入沉思，由於我總在本身的認知裏選出一個本身認爲最好的架構，而後以爲其餘架構都是垃圾。

靜下心來想一想，每一個產品都有本身不一樣的定位，若是拋開它們的定位，拋開它們的業務需求去談若是給它們設計一個良好的架構，這簡直是扯淡。

 

更況且不少優秀的app架構也是由一開始很弱而慢慢變得愈來愈強。

因此沒有最好的架構，只有適合本身的業務的架構纔是最好的架構，而且它是逐步地變強變大。

本文將舉一個例子來演示這個過程。

 

---

那麼，到底什麼是架構？

 

架構，又名軟件架構，是有關軟件總體結構與組件的抽象描述，用於指導大型軟件系統各個方面的設計。

 

以個人理解，它就像是人的骨架通常，一我的從小生長到大，圍繞着整個骨架去發展，變高變胖。

能夠把app開發當作一個汽車工廠的流水線，造車身->噴漆->組裝等等。即把整個開發流程切成一個個模塊，每一個模塊相互獨立，併發工做。這就是所謂app架構。

 

---

沒有架構的「架構」

 

某天，一個叫Jim的開發者，他打算開發一個app，固然有必定計算機基礎的他知道採用MVC的設計模式來構造app，因而一個星期後，終於能跑起來一個app，可是此時，看一下項目的目錄結構：

 

v1.0

嗯，不錯，咱們不但能run，還能看出這個app用了MVC的設計模式耶。

可是隨着開發的頁面愈來愈多，一個月後，app有了10個頁面，此時，打開Controller、View、Model這三個文件夾以後，發現每一個文件夾裏面居然有幾十個文件，它們雜亂無章的灑落在一塊兒。此時不斷有用戶向Jim反映，xxx地方怎麼按鈕位置不對，xxx位置網絡請求不成功。

頭痛的Jim才知道，當初應該把粒度分的更細，因而又了接下來的架構。

 

---

分模塊的架構

 

Jim把不一樣的功能模塊放在一起，因而獲得了以下的架構：

 

v2.0

可是不對，一些工具類，公用類該放哪呢？Jim仔細思索了一番，因而又將上述架構進行改進，獲得如下的架構：

 

v2.1

嗯，這看起來纔像樣嘛。

 

---

Cocoapods

 

慢慢地，Jim發現網上有不少能夠現成拿來用的第三方框架，而他同時也學習了Cocoapods這個神器。

什麼是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.

它是一個能讓你方便地管理第三方庫的一個工具。

因而，項目變成了這樣：

 

v2.2

此時的架構已經知足了我的開發者，或者說是小型開發團隊的需求了。

 

---

多人開發的架構

 

可是在一個初具規模的公司，上述的架構模式是遠遠不行的，試想一下，若是有20我的同時開發一個app，而此時你們就算各自負責本身的模塊，若是同時有不一樣模塊的同窗添加或者刪除文件，對於.xcodeproj文件來講，會有嚴重的衝突。

那麼，怎麼辦呢？

想一下cocoapods的做用吧，其實利用它能作不少不少事，咱們徹底能夠把Home、Detail、Login等模塊抽出來，也把它視爲「第三方庫」（實際上能夠算是二方庫）。初期階段能夠這麼作：

 

v3.0

能夠看到咱們把Home這個模塊抽出來了。

這麼作有什麼好處？

若是咱們把各個業務模塊都抽出來，首先來講，能夠解決衝突的問題，而且業務團隊之間的工做不受影響，而且能夠並行開發，也無需再等待其餘兄弟業務團隊的進度了。
當其餘業務團隊的任務完成時，咱們只需pod update，將代碼升級到最新就能夠了。
而且當一個公司有多個app時，若是有公用的模塊，用這種方式會更優雅。
固然，若是你以爲直接指定git地址太low，你徹底能夠搞一個私有Spec，專門存放業務模塊代碼。

 

---

子project模式的架構

 

不少人會說上述方式很複雜，還不如採用在主工程下中放子工程（業務模塊）來實現抽象：

 

不合理的架構

 

可是我以爲這個方式管理起項目很麻煩，更新模塊代碼、不一樣app間複用模塊代碼都會沒上述的方式優雅，因此我以爲這種方式沒有上述的好。

 

---

對各個模塊進行解耦

 

如今雖然咱們對各個模塊進行了抽象，可是業務模塊間仍是互相引用，對於開發來講，雖然解決了代碼的耦合問題，對於代碼的引用關係卻沒有改變：

v3.0

 

上圖才只有4個模塊，若是有上百個模塊的話，這個關係能夠複雜成一個龐大的蜘蛛網，這對於後期維護來講，成本是巨大的。

 

因此咱們想，有木有好的方式來解耦呢，固然是有的，我以爲如下兩個方式是很好的：

• middleman

• urlRoute

先來介紹middleman（中間人模式）

middleman

如圖所示，咱們只需將全部的模塊依賴這個middleman，讓middleman來處理各個模塊的關係，模塊A若是須要依賴模塊B，徹底能夠考middleman來處理，而且返回模塊A所須要的模塊B的內容，這樣就解決了解耦。

 

再來講說urlRoute，其實這個方式相似於Facebook很早前的320結構了。

思路就是將每一個頁面當作是一個url，設置一套路由規則，在頁面打開時將url進行路由查找，而後這樣一來，只要模塊A按照既定的規則寫好url，那麼模塊B依賴模塊A時，只需根據url打開就好了。

urlRoute

---

middleman VS urlRoute

 

兩種方式各自有本身的優勢和缺點，他們主要的區別在於：

• 傳參的方式

• 所需維護的具體內容不一樣

我更傾向於urlRoute，爲何這麼說呢？

因爲本文講的是app架構，這裏就簡單介紹下：

若是一個頁面出現了問題，咱們能夠用各類patch的方式來打補丁。可是，若是一個頁面出現了致命的錯誤，打patch的成本過於高的話，此時若是用urlRoute，則有個妙招。

咱們能夠更改appConfig（app的配置，能夠從服務端動態更新），更改頁面所對應的url，而且改爲在路由規則裏跳到webview的規則。

這樣以後，當跳到此模塊時，則會打開對應的H5頁面，而不是原來的有問題的頁面。
固然middleman也能夠處理成這樣，可是從實現的角度來講，顯然是urlRoute更爲優秀。

 

---

總結

架構遠遠不是一篇文章能講清楚的，也不只僅只是結構層次方面的內容，還有例如push、hotpatch、動態化、appConf、Service中間件模塊的具體實現，MVCMVVMMVCS設計模式等等。本文只是從最基礎的地方展示具體業務模塊的解耦方式，但願能起到拋磚引玉的做用。