本文將要講的架構設計可能沒有那麼真正的架構那麼準確，可以理解為在建立App時專案的一個目錄結構吧。
做iOS開發3年，其實深刻的架構設計感覺還談不上，主要是現在接手了一套架構比較牛的程式碼，然後回頭看了一下自己之前的App架構，覺得豁然開朗了很多。在這裡主要總結分享一下我自己寫過的比較渣的架構，希望大家以此為鑑！
第一份工作的第一個App，那個時候知道的架構也只有MVC模式，但是可能理解的也不是很透徹，寫出來的專案結構如下圖：

那個時候剛開始寫專案的時候覺得還可以，畢竟程式碼不是很多的時候還是很清晰的，就是ViewController裡面有時候程式碼會很多。後來就把功能比較複雜的ViewController裡面的檢視抽出來寫一個類，在對應的model中將資料處理好再給到ViewController。這樣可以稍微減少一下ViewController中的程式碼，讓程式碼可讀性和可維護性提高。
隨著專案功能的增多，這個架構的弊端也暴露的越來越多，找一個功能對應的程式碼也不好找。為了程式碼的可讀性和後期維護，我又重新改了專案的結構，專案架構還是基於MVC，結構如下圖：

修改後的結構，在剛剛改的時候，我覺得還是很好的。特別是與之前相比，感覺清晰了很多。當然這兩種在一些人眼裡都是很爛的，覺得好的可以參考參考用用看，覺得爛的歡迎留言交流好的架構，讓我學習學習。第二種我覺得還是可取的，看上去也比較小清新，維護起來也不是很困難。但是看了現在的專案架構之後，我覺得第二種還需要優化的地方就是公用類，不宜寫的太多。呼叫的時候確實是方便，但是這會讓很多程式碼都有耦合，不符合程式碼應有的低耦合性。
現在的專案結構是基於MVP的，各模組都是以元件化的形式來開發的。頁面的跳轉用的是路由表的方法，每個ViewController會關聯一個interactor，在interactor中處理資料和互動，每個interactor會關聯一個adapter，在adapter中實現網路介面方法的呼叫。現在這個專案架構的優點在於解耦處理的很到位，跨模組的呼叫幾乎沒有，實在要跨模組操作的話基本都用了通知。不過個人覺得這樣的架構比較適合大型專案，如果專案不是很大，用這個架構的話，會覺得很繁瑣，特別是ViewController與interactor和adapter的關聯，在看程式碼的時候要在各類間跳轉，程式碼可讀性不是很高。
我說它是基於MVP的原因是因為，大量的提供方法呼叫的類，比如網路請求的介面封裝類，都是以協議的方式來開放介面的。這樣可以更好的元件化，特別是需要將某一模組的功能獨立出來封裝成SDK時，可以以協議的方式開放外部呼叫的介面。
如果是新手的話建議用圖二的架構，上手比較容易，可以把公用的工具類按照功能需要分別已類別或者子類的形式分散到各模組中，這樣可以降低程式碼中的耦合性。至於第三種，感覺用起來還是挺複雜的，但是很符合程式碼的高內聚、低耦合，然後元件化處理的很到位，可以用在大型專案或者是要做成SDK的模組。