前言：
本文是繼《iOS 從0到1搭建高可用App框架》之後，通過專案實踐以及同行交流思考總結出來的一些新的架構思想，但初心仍不變，目的為搭建高可用App框架，保持框架底層健壯的同時讓程式碼更清晰，為後期頂層業務開發時，避免出現風格迥異的程式碼。
架構圖：
思考：
一、面對一個版本迭代頻繁，改版頻率高的專案，如何設計才能避免程式碼越改越亂？
二、當業務極其複雜時，如果減輕VC的壓力，讓程式碼更清晰？
三、如何正確選擇第三方框架？都需要考慮哪些因素？
正文：
直面問題，解決問題：
一、許多創業專案為了趕時間上線，前期沒有框架設計，沒有程式碼規範，每個人隨意發揮，不出幾個月就會出現 產品體驗差、崩潰率飆升、開發進度緩慢等問題，不得不進行重構。在戰略角度上也許是對的，先佔坑再完善，但在架構角度這是不可取的，還是要嚴格遵循“高內聚，低耦合”的理念，確保框架由底層服務到頂層業務，各模組分工明確，各司其職，相對獨立，模組間通過介面呼叫，嚴禁在A裡直接使用B，B裡直接使用C，這樣會使得各模組藕斷絲連難捨難分，後期只會越來越亂。
很多時候，現在的問題都是當初偷懶埋下的禍根，合格的程式設計師基本都是懶人，但摔的多了總要長點記性。適當克服一下惰性，前期將框子搭起來，真正的去物件導向程式設計。
二、我曾接手過一款直播App，光直播間ViewController程式碼就5500行，裡面摻和著介面請求、資料轉換、檢視管理、業務邏輯等等，讀起來十分費勁，Bug定位比較困難，想重構卻無從下手，這種情況的發生首先是沒有嚴格遵循模組化的設計理念，各模組沒有各司其職，其次是過於嚴格的遵循了MVC設計模式，只建立了Model View Controller三個資料夾，VC的壓力自然非常大。
在我理解來看，MVC只是表達了一種模組化思想，並不需要嚴格遵循MVC的目錄格式。
如上圖，我將每個模組在MVC的基礎上又抽出了兩層，分別是Logic層和Service層。Logic資料夾內，存放在每個VC的邏輯處理類。
我們們的目的是解放VC，ViewController顧名思義是檢視控制器，不應做太多與其不相關的工作，將邏輯處理交給對應這個VC的Logic類，Logic承擔著邏輯處理和Service的呼叫拿到資料並解析，通過delegate回撥給VC，VC拿到已經處理完畢的資料，去渲染檢視。
這樣做的話，VC內只剩下與Logic的互動，還有管理View的程式碼，必然清晰很多。
三、大部分應用為了快速開發，都會使用一些第三方框架，但第三方框架如此之多，我們該如何選擇才能夠發揮它們最大優勢？
首先要分析自己的應用，都用得著哪些框架，在同一型別的框架裡選擇的宗旨是——符合自身且維護及時，超過一年沒更新的就要慎重了，下面是我選擇時的一些思考：
1.網路框架
網路請求是一款APP必須的，大家通常都會選擇AFNetworking作為基礎網路框架，但這只是個基礎框架，雖說可以直接呼叫請求資料，但如果有一些其他需求，例如加密或者加公共引數等，想要滿足就比較費勁了，所以大多數開發者會對其進行二次封裝，目的為了自定義一些需求，可以自己掌控並處理請求和返回資料，也為將來如果更換網路框架，減少程式碼改動量。很多人自己封裝一些簡單的Post Get請求方法，中小型應用使用起來也足夠。
當前框架中我最開始選擇的是PPNetworkHelper，原因是比較簡單易用，其中還包含了快取機制。後來看了猿題庫的網路庫YTKNetwork，引入使用了一下，發現使用方法跟PPNetworkHelper完全不同，YTKNetwork的思想是抽象每個介面為一個物件，例項化介面物件去發起網路請求，從而可以針對每個請求定製化，還有一些其他的功能，靈活性比較強，適合稍微複雜一些的專案，框架中兩種我都保留了，大家可根據專案實際情況進行選擇，但建議都瞭解一下，特別是後者。
2. 基礎元件庫
之前就提到過的，功能強大，效能優秀的——YYKit
它包含了解析資料，快取，影像處理，文字處理，非同步繪製等元件，當然也有些瑕疵下面說
YYModel— 高效能的 iOS JSON 模型框架。
YYCache— 高效能的 iOS 快取框架。
YYImage— 功能強大的 iOS 影像框架。
YYWebImage— 高效能的 iOS 非同步影像載入框架。
YYText— 功能強大的 iOS 富文字框架。
YYKeyboardManager— iOS 鍵盤監聽管理工具。
YYDispatchQueuePool— iOS 全域性併發佇列管理工具。
YYAsyncLayer— iOS 非同步繪製與顯示的工具。
YYCategories— 功能豐富的 Category 型別工具庫。
選擇這個框架的原因是功能和效能都比較強大，用一個框架就可以做很多事，而且YYKit的設計思想是category，幾乎沒有入侵性，使用起來也非常方便。
但是同事發現YYWebImage— 這個高效能非同步影像載入框架可能有點過時，因為其使用的是NSURLConnection請求，而SDWebImage已替換成了URLSession。所以影像非同步載入上，我還是選擇更加專業的SDWebImage。
3. 佈局框架
這裡想必最大的分歧不是框架，而是佈局方式，我瞭解的開發者通常有三種佈局方式，分別是：程式碼計算frame、Masonry程式碼約束，SB/xib直拖約束。
我認為三種方式各有優缺點，不做評價，免得被罵，我個人是靈活運用，沒有瞧不起任何一個，在不同的場景下，使用最合適的方式，才能達到最佳效果，舉個例子：“關於我們”，一個簡單展示的頁面，這時候通過xib拖出來這個頁面，應該不超過5分鐘，手寫程式碼計算frame也許得10分鐘，而且！程式碼寫的東西不夠直觀，其他同事不能直接的看到你這個頁面是什麼樣子。所以無論哪種方式都不是絕對的不好，也沒有絕對的好，看場景，選姿勢。
4.上下拉重新整理框架
大部分應用都會有TableView或CollectionView，上下拉重新整理是比較常用的，MJRefresh提供的功能比較強大，支援自定義，提供樣式齊全，更新及時，所以，我選它！
5. Toast提示
比較主流的兩款Toast提示框架可供選擇，分別是 MBProgressHUD 和 SVProgressHUD，二者更新都比較及時，功能也都類似，根據個人習慣了，選擇哪個不重要，重要的是要對其二次封裝，讓它變得更好用，框架中我封裝了一個MBProgressHUD+XY的category，類方法的形式呼叫。
關於其他框架的選擇，其實道理一樣，首先要了解他們的優缺點，本著符合自身且維護及時的宗旨去選擇就沒有錯。
以上內容的原始碼都整理在GitHub – UniversalProject框架內，大家可以下載參閱，順便動動小手指點顆✨