iOS 從0到1搭建高可用App框架（二）

前言：

本文是繼《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的思想是抽象每個接口爲一個對象，實例化接口對象去發起網絡請求，從而可以針對每個請求定製化，還有一些其他的功能，靈活性比較強，適合稍微複雜一些的項目，框架中兩種我都保留了，大家可根據項目實際情況進行選擇，但建議都瞭解一下，特別是後者。

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。

YYKit

3. 佈局框架

這裏想必最大的分歧不是框架，而是佈局方式，我瞭解的開發者通常有三種佈局方式，分別是：代碼計算frame、Masonry代碼約束，SB/xib直拖約束。

我認爲三種方式各有優缺點，不做評價，免得被罵，我個人是靈活運用，沒有瞧不起任何一個，在不同的場景下，使用最合適的方式，才能達到最佳效果，舉個栗子：“關於我們”，一個簡單展示的頁面，這時候通過xib拖出來這個頁面，應該不超過5分鐘，手寫代碼計算frame也許得10分鐘，而且！代碼寫的東西不夠直觀，其他同事不能直接的看到你這個頁面是什麼樣子。所以無論哪種方式都不是絕對的不好，也沒有絕對的好，看場景，選姿勢。

4.上下拉刷新框架

大部分應用都會有TableView或CollectionView，上下拉刷新是比較常用的，MJRefresh提供的功能比較強大，支持自定義，提供樣式齊全，更新及時，所以，我選它！

MJRefresh

5. Toast提示

比較主流的兩款Toast提示框架可供選擇，分別是 MBProgressHUD 和 SVProgressHUD，二者更新都比較及時，功能也都類似，根據個人習慣了，選擇哪個不重要，重要的是要對其二次封裝，讓它變得更好用，框架中我封裝了一個MBProgressHUD+XY的category，類方法的形式調用。