iOSAPP開發項目搭建

架構圖：

架構原則：易讀性、易維護性、易擴展性。

一、思考

做好一件事，花在思考上的時間應該多於執行。

首先根據產品需求和設計圖，腦中先建立一個產品架構：

1. 產品的定位是什么。

社交？媒體？游戲？運動？音視頻？電商……要搞清楚你要做一個什么類型的App，不同類型的產品，技術選型也有所不同，在這我是搭建一個基礎App架構，可以在此基礎上拓展社交、電商、音視頻等！

2. 技術選型

根據當前產品的需求以及未來可能有的需求（我怎么知道未來會有什么需求？可以參照競品，可以發揮想象，如果產品說：“我們要做IM文字聊天，只做文字！不做音視頻，以后都不做！” 類似這樣的承諾，你如果信了他的邪……后面的故事就精彩了。。哈哈哈哈哈哈。。。。所以說這時候你就要考慮到后面會有語音+視頻聊天，在設計的時候不要偷懶，預留一定空間，當某天產品反悔的時候，你可以微微一笑，從容應對。

一把拉回話題，接着說技術選型，通常我會選擇一些當下比較熱門、好用的第三方框架，例如：YYKit ，YYKit 是一組龐大、功能豐富的 iOS 組件，包含Model解析、圖片加載、緩存等基礎服務，都是基於Category設計的，使用方便且性能高於一些老的框架，用過的都說好。

其他框架的選擇可以根據項目需求，去GitHub上搜索，星星多的每個都看一下，會給你增加一些思路。

程序猿長得可以保守，思想一定不能太保守。

二、搭建目錄結構

目錄圖解

如上圖，我是這樣搭建App目錄結構的，從下到上，使用Pods管理第三方框架，將第三方框架進行二次封裝，供給頂層使用，盡可能減少各模塊之間的耦合度。

三、封裝基礎類

1.應用入口

 

1. AppDelegate是應用的代理，應用級的事件都委托它處理，包含啟動退出、推送等事件，以及IM、支付等第三方的回調，這使得AppDelegate內代碼龐大，錯綜復雜，十分不利於閱讀和維護，因此我新增了一個AppDelegate+AppService類別，用來處理生命周期之外的業務，AppDelegate作為事件入口，具體實現直接調用類別里的方法。

2. 功能模塊

2. Modules包含了應用內的功能模塊，根據底部Tab欄划分並關聯實體文件夾（默認是虛擬的要手動建立實體文件夾拖進來），每個模塊內使用的是MVC模式，有人會問為什么多了Resource和Service文件夾，MVC是一種設計思想，並非死套路就仨文件夾，根據實際需求適當增加，在這我選擇在Service封裝數據請求，VC里調用拿數據即可，至於Resource為什么在這，我認為當功能模塊層級較多時，每個大功能模塊都對應許多資源，對應到模塊內用起來方便，當然也可以放到最外層的Resource文件夾里，建立對應的模塊名稱，在這兒我是選擇把公共的放到最外層Resource里，功能相關的放到模塊里的Resource文件夾內。

 

3. 管理模塊

3. Manager的定義是全局基礎服務，通常使用類方法或者單例來實現，主要包含對應用、用戶的管理和服務，例如網絡狀態監聽，廣告頁應用介紹頁等；用戶快速登錄退出操作以及登錄狀態的獲取等。

 

4.工具類

4. Utils文件夾內主要包含全局通用工具，來源於對三方框架的二次封裝，或是自己寫的工具類。在這個項目里，我封裝了帶AES加密網絡請求工具，全局Toast提示，廣告頁等。

 

5. 基類

5. Base文件夾用來存放項目的基類，基類作用包含一些定制化的內容，例如頁面樣式，空數據頁面等，使用基類來實現，可以統一控制，利於維護，減少冗余，也為更清晰。

 

6.第三方 & 7.全局宏定義

6. 第三方文件夾放一些第三方的類庫和對第三方封裝，比如第三方登錄、支付、IM等，現在項目我還沒有添加第三方框架。

7.全局宏顧名思義是定義了一些全局通用宏。我這里定義了四個：

UtilsMacros定義的是一些工具宏，比如獲取屏幕寬高，系統版本，數據類型驗證等；

URLMacros定義服務器接口地址以及環境開關；

FontAndColorMacros定義全局用的色值、字體大小，這里建議跟設計師共同維護一個設計規范，例如：定義一個主色調宏 MainColor，色值是 0x333333，我們全局使用MainColor宏作為背景顏色，當某天App改版，色值改變，我們只需要去更改 0x333333即可，其他代碼不需要動，同時也能一定程度約束設計師，不要隨便增加一種顏色，非常接近的顏色應當使用一個。如果設計師不願意維護這個規范，你可以嘗試打一架，打不過的話，就只能自己維護了。

ThirdMacros 包含第三方框架相關的定義，例如keySecret等。

 

8. 資源文件

8. 資源文件，上面說到過，這里我是存放了全局的一些資源文件，功能模塊的我放到了模塊內的Resource文件夾內，個人喜好。

 

9. Pods三方管理

9. CocoaPods是iOS項目的依賴管理工具，開發iOS項目不可避免地要使用第三方開源庫，CocoaPods的出現使得我們可以節省設置和第三方開源庫的時間。

架構圖

 

效果圖

思考：

• 一、面對一個版本迭代頻繁，改版頻率高的項目，如何設計才能避免代碼越改越亂？

• 二、當業務極其復雜時，如果減輕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，類方法的形式調用。

MBProgressHUD

關於其他框架的選擇，其實道理一樣，首先要了解他們的優缺點，本着符合自身且維護及時的宗旨去選擇就沒有錯。

以上內容的源碼都整理在GitHub - UniversalProject框架內，大家可以下載參閱，順便動動小手指點顆?

原文地址：http://www.jianshu.com/p/f09a4f21e0f9

下面對你也許有幫助：

• iOS 團隊編碼規范—— 團隊開發需要共同遵守的代碼規范

• 代碼注釋，教你用快捷鍵+代碼塊實現快速注釋—— 讓注釋不再是負擔，快捷鍵幫你解決

• 通用工具類宏定義—— 進一步提升編碼效率

作者：臭碼農
鏈接：http://www.jianshu.com/p/d553096914ff