架構圖：

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

一欧聘、思考

做好一件事片林，花在思考上的時間應該多于執(zhí)行。

首先根據(jù)產品需求和設計圖怀骤，腦中先建立一個產品架構：

1. 產品的定位是什么费封。

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

2. 技術選型

根據(jù)當前產品的需求以及未來可能有的需求（我怎么知道未來會有什么需求陈莽？可以參照競品渤昌，可以發(fā)揮想象，如果產品說：“我們要做IM文字聊天走搁，只做文字独柑！不做音視頻，以后都不做私植！” 類似這樣的承諾忌栅，你如果信了他的邪……后面的故事就精彩了。曲稼。哈哈哈哈哈哈索绪。。贫悄。瑞驱。所以說這時候你就要考慮到后面會有語音+視頻聊天，在設計的時候不要偷懶窄坦，預留一定空間唤反，當某天產品反悔的時候晰筛，你可以微微一笑，從容應對拴袭。

一把拉回話題读第，接著說技術選型，通常我會選擇一些當下比較熱門拥刻、好用的第三方框架怜瞒，例如：YYKit?，YYKit 是一組龐大般哼、功能豐富的 iOS 組件吴汪，包含Model解析、圖片加載蒸眠、緩存等基礎服務漾橙，都是基于Category設計的，使用方便且性能高于一些老的框架楞卡，用過的都說好霜运。

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

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

二、搭建目錄結構

目錄圖解

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

三蹈丸、封裝基礎類

1.應用入口

1. AppDelegate是應用的代理，應用級的事件都委托它處理呐芥，包含啟動退出逻杖、推送等事件，以及IM思瘟、支付等第三方的回調荸百，這使得AppDelegate內代碼龐大，錯綜復雜滨攻，十分不利于閱讀和維護够话，因此我新增了一個AppDelegate+AppService類別蓝翰，用來處理生命周期之外的業(yè)務，AppDelegate作為事件入口女嘲，具體實現(xiàn)直接調用類別里的方法畜份。

2. 功能模塊

2. Modules包含了應用內的功能模塊，根據(jù)底部Tab欄劃分并關聯(lián)實體文件夾（默認是虛擬的要手動建立實體文件夾拖進來）欣尼，每個模塊內使用的是MVC模式爆雹，有人會問為什么多了Resource和Service文件夾，MVC是一種設計思想愕鼓，并非死套路就仨文件夾钙态，根據(jù)實際需求適當增加，在這我選擇在Service封裝數(shù)據(jù)請求菇晃，VC里調用拿數(shù)據(jù)即可册倒，至于Resource為什么在這，我認為當功能模塊層級較多時磺送，每個大功能模塊都對應許多資源驻子，對應到模塊內用起來方便，當然也可以放到最外層的Resource文件夾里册着，建立對應的模塊名稱拴孤，在這兒我是選擇把公共的放到最外層Resource里，功能相關的放到模塊里的Resource文件夾內甲捏。

3. 管理模塊

3. Manager的定義是全局基礎服務，通常使用類方法或者單例來實現(xiàn)鞭执，主要包含對應用司顿、用戶的管理和服務，例如網絡狀態(tài)監(jiān)聽兄纺，廣告頁應用介紹頁等大溜；用戶快速登錄退出操作以及登錄狀態(tài)的獲取等。

4.工具類

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

5. 基類

5. Base文件夾用來存放項目的基類厌衔，基類作用包含一些定制化的內容，例如頁面樣式捍岳，空數(shù)據(jù)頁面等富寿，使用基類來實現(xiàn)睬隶，可以統(tǒng)一控制，利于維護页徐，減少冗余苏潜，也為更清晰。

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

6. 第三方文件夾放一些第三方的類庫和對第三方封裝变勇，比如第三方登錄恤左、支付、IM等贰锁，現(xiàn)在項目我還沒有添加第三方框架赃梧。

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

UtilsMacros定義的是一些工具宏豌熄，比如獲取屏幕寬高授嘀，系統(tǒng)版本，數(shù)據(jù)類型驗證等锣险；

URLMacros定義服務器接口地址以及環(huán)境開關蹄皱；

FontAndColorMacros定義全局用的色值、字體大小芯肤，這里建議跟設計師共同維護一個設計規(guī)范巷折，例如：定義一個主色調宏 MainColor，色值是 0x333333崖咨，我們全局使用MainColor宏作為背景顏色锻拘，當某天App改版，色值改變击蹲，我們只需要去更改 0x333333即可署拟，其他代碼不需要動，同時也能一定程度約束設計師歌豺，不要隨便增加一種顏色推穷，非常接近的顏色應當使用一個。如果設計師不愿意維護這個規(guī)范类咧，你可以嘗試打一架馒铃，打不過的話，就只能自己維護了痕惋。

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

8. 資源文件

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

9. Pods三方管理

9. CocoaPods是iOS項目的依賴管理工具拉盾，開發(fā)iOS項目不可避免地要使用第三方開源庫贿肩，CocoaPods的出現(xiàn)使得我們可以節(jié)省設置和第三方開源庫的時間替废。

架構圖

效果圖

思考：

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

二、當業(yè)務極其復雜時掸屡，如果減輕VC的壓力封寞，讓代碼更清晰？

三仅财、如何正確選擇第三方框架狈究？都需要考慮哪些因素？

正文：

直面問題盏求，解決問題：

一抖锥、許多創(chuàng)業(yè)項目為了趕時間上線，前期沒有框架設計碎罚，沒有代碼規(guī)范磅废，每個人隨意發(fā)揮，不出幾個月就會出現(xiàn) 產品體驗差荆烈、崩潰率飆升拯勉、開發(fā)進度緩慢等問題，不得不進行重構憔购。在戰(zhàn)略角度上也許是對的谜喊，先占坑再完善，但在架構角度這是不可取的倦始，還是要嚴格遵循“高內聚，低耦合”的理念山卦，確毙兀框架由底層服務到頂層業(yè)務，各模塊分工明確账蓉，各司其職枚碗，相對獨立，模塊間通過接口調用铸本，嚴禁在A里直接使用B肮雨，B里直接使用C，這樣會使得各模塊藕斷絲連難舍難分箱玷，后期只會越來越亂怨规。

很多時候陌宿，現(xiàn)在的問題都是當初偷懶埋下的禍根，合格的程序員基本都是懶人波丰，但摔的多了總要長點記性壳坪。適當克服一下惰性，前期將框子搭起來掰烟，真正的去面向對象編程爽蝴。

二、我曾接手過一款直播App纫骑，光直播間ViewController代碼就5500行蝎亚，里面摻和著接口請求、數(shù)據(jù)轉換先馆、視圖管理发框、業(yè)務邏輯等等，讀起來十分費勁磨隘，Bug定位比較困難缤底，想重構卻無從下手，這種情況的發(fā)生首先是沒有嚴格遵循模塊化的設計理念番捂，各模塊沒有各司其職个唧，其次是過于嚴格的遵循了MVC設計模式，只創(chuàng)建了Model View Controller三個文件夾设预，VC的壓力自然非常大徙歼。

在我理解來看，MVC只是表達了一種模塊化思想鳖枕，并不需要嚴格遵循MVC的目錄格式魄梯。

如上圖，我將每個模塊在MVC的基礎上又抽出了兩層宾符，分別是Logic層和Service層酿秸。Logic文件夾內，存放在每個VC的邏輯處理類魏烫。

咱們的目的是解放VC辣苏，ViewController顧名思義是視圖控制器，不應做太多與其不相關的工作哄褒，將邏輯處理交給對應這個VC的Logic類稀蟋，Logic承擔著邏輯處理和Service的調用拿到數(shù)據(jù)并解析，通過delegate回調給VC呐赡，VC拿到已經處理完畢的數(shù)據(jù)退客，去渲染視圖。

這樣做的話，VC內只剩下與Logic的交互萌狂，還有管理View的代碼档玻，必然清晰很多。

模塊結構

三粥脚、大部分應用為了快速開發(fā)窃肠，都會使用一些第三方框架，但第三方框架如此之多刷允，我們該如何選擇才能夠發(fā)揮它們最大優(yōu)勢冤留？

首先要分析自己的應用，都用得著哪些框架树灶，在同一類型的框架里選擇的宗旨是——符合自身且維護及時纤怒，超過一年沒更新的就要慎重了，下面是我選擇時的一些思考：

1.網絡框架

網絡請求是一款APP必須的天通，大家通常都會選擇AFNetworking作為基礎網絡框架泊窘，但這只是個基礎框架，雖說可以直接調用請求數(shù)據(jù)像寒，但如果有一些其他需求烘豹，例如加密或者加公共參數(shù)等，想要滿足就比較費勁了诺祸，所以大多數(shù)開發(fā)者會對其進行二次封裝携悯，目的為了自定義一些需求，可以自己掌控并處理請求和返回數(shù)據(jù)筷笨，也為將來如果更換網絡框架憔鬼，減少代碼改動量。很多人自己封裝一些簡單的Post Get請求方法胃夏，中小型應用使用起來也足夠轴或。

當前框架中我最開始選擇的是PPNetworkHelper，原因是比較簡單易用仰禀，其中還包含了緩存機制照雁。后來看了猿題庫的網絡庫YTKNetwork，引入使用了一下答恶，發(fā)現(xiàn)使用方法跟PPNetworkHelper完全不同囊榜，YTKNetwork的思想是抽象每個接口為一個對象，實例化接口對象去發(fā)起網絡請求亥宿，從而可以針對每個請求定制化，還有一些其他的功能砂沛，靈活性比較強烫扼，適合稍微復雜一些的項目，框架中兩種我都保留了碍庵，大家可根據(jù)項目實際情況進行選擇映企，但建議都了解一下悟狱，特別是后者。

YTKNetwork實現(xiàn)數(shù)據(jù)請求

2. 基礎組件庫

之前就提到過的堰氓，功能強大挤渐，性能優(yōu)秀的——YYKit ?

它包含了解析數(shù)據(jù)，緩存双絮，圖像處理浴麻，文本處理，異步繪制等組件囤攀，當然也有些瑕疵下面說

YYModel— 高性能的 iOS JSON 模型框架软免。

YYCache— 高性能的 iOS 緩存框架。

YYImage— 功能強大的 iOS 圖像框架焚挠。

YYWebImage— 高性能的 iOS 異步圖像加載框架膏萧。

YYText— 功能強大的 iOS 富文本框架。

YYKeyboardManager— iOS 鍵盤監(jiān)聽管理工具蝌衔。

YYDispatchQueuePool— iOS 全局并發(fā)隊列管理工具榛泛。

YYAsyncLayer— iOS 異步繪制與顯示的工具。

YYCategories— 功能豐富的 Category 類型工具庫

選擇這個框架的原因是功能和性能都比較強大噩斟，用一個框架就可以做很多事曹锨，而且YYKit的設計思想是category，幾乎沒有入侵性亩冬，使用起來也非常方便艘希。

但是同事發(fā)現(xiàn)YYWebImage— 這個高性能異步圖像加載框架可能有點過時，因為其使用的是NSURLConnection請求硅急，而SDWebImage已替換成了URLSession覆享。所以圖像異步加載上，我還是選擇更加專業(yè)的SDWebImage营袜。

YYKit

3. 布局框架

這里想必最大的分歧不是框架撒顿，而是布局方式，我了解的開發(fā)者通常有三種布局方式荚板，分別是：代碼計算frame凤壁、Masonry代碼約束，SB/xib直拖約束跪另。

我認為三種方式各有優(yōu)缺點拧抖，不做評價，免得被罵免绿，我個人是靈活運用唧席，沒有瞧不起任何一個，在不同的場景下，使用最合適的方式淌哟，才能達到最佳效果迹卢，舉個栗子：“關于我們”，一個簡單展示的頁面徒仓，這時候通過xib拖出來這個頁面腐碱，應該不超過5分鐘，手寫代碼計算frame也許得10分鐘掉弛，而且症见！代碼寫的東西不夠直觀，其他同事不能直接的看到你這個頁面是什么樣子狰晚。所以無論哪種方式都不是絕對的不好筒饰，也沒有絕對的好，看場景壁晒，選姿勢瓷们。

4.上下拉刷新框架

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

MJRefresh

5. Toast提示

比較主流的兩款Toast提示框架可供選擇不撑，分別是?MBProgressHUD和?SVProgressHUD，二者更新都比較及時晤斩，功能也都類似焕檬，根據(jù)個人習慣了，選擇哪個不重要澳泵，重要的是要對其二次封裝实愚，讓它變得更好用，框架中我封裝了一個MBProgressHUD+XY的category兔辅，類方法的形式調用腊敲。

MBProgressHUD

關于其他框架的選擇，其實道理一樣维苔，首先要了解他們的優(yōu)缺點碰辅，本著符合自身且維護及時的宗旨去選擇就沒有錯。

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

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

下面對你也許有幫助：

iOS 團隊編碼規(guī)范—— 團隊開發(fā)需要共同遵守的代碼規(guī)范

代碼注釋忍法，教你用快捷鍵+代碼塊實現(xiàn)快速注釋—— 讓注釋不再是負擔，快捷鍵幫你解決

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

作者：臭碼農

鏈接：http://www.reibang.com/p/d553096914ff