iOSAPP開發項目搭建

標籤：text   最大   音視頻   更改   需求   關於我   anti   靈活運用   macro   

架構圖：

架構原則：易讀性、易維護性、易擴充性。一、思考

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

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

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

iOSAPP開發項目搭建