一個簡潔優雅的iOS工程目錄，能夠幫助團隊提升開發效率，同時也令自己進行心情愉悅的編碼;反之，雜亂無章的目錄則會使人心情煩躁，降低團隊開發效率。

不知你是否也有同感?歡迎你在評論區寫下的感受。

首先，我想說：

• 本文說的工程架構適用于純代碼開發的團隊，也適用于使用Storyboard開發的團隊;
• 本文適用于傳統的Tabbar+NavigationBar搭建的app，也適用于其他非傳統的app;
• 本文特別適用于讓團隊的新進成員了解項目的整體構架，并且進行快速開發

本文以公司的FCS app為例，界面如下：

主界面

公司的項目屬于Objective-C和Swift混編的項目，對于純swift的項目和純OC的項目，可能文件夾和類文需要自行修改，Xcode項目工程目錄如下：

工程框架搭建圖

正如上圖所示，我將項目劃分為9大部分，GitHub地址：

Models：模型數據類，所有自定義的數據模型應該放在此處;

Views：視圖類，以功能模塊還需要再建一層文件夾，所有自定義的功能模塊的視圖類都應該放在給自的文件夾下此處，，手動拖入的第三方UI控件除外，第三方的UI應該放入Vendor文件夾里;

Controllers：控制器類，所有控制器類放在此文件夾里面，如果有BaseViewController、BaseNavigationController可以放在Base文件夾下(可以在此目錄下新建的一個Base文件夾)，同時相應功能模塊的Storyboard也放在此目錄下，Storyboard放在此處相比于放在View里面更加方便(我們項目最開始在Views目錄下新建Storyboards文件夾來存放所有的Storyboard，這樣的做法弊端是去相應的Storyboard和功能模塊的VC太遠，操作不便);

Resouces：資源文件夾，存放項目需要用到的音頻、視頻、圖片(webP格式的圖片或者內存比較大png只需要用到一份的背景圖片)、字體、動畫等等資源文件都放在此處;

Util，一些工具類的文件夾，比如Objective-C的分類文件夾Category、swift擴展類的文件夾Extension，管理單例類文件夾Manager等等;

Vendor，手動管理的第三方庫，上圖的BookRoom是我們FCS app的BookRoom模塊都是封裝為framework的形式引入的，所以就適合在此處添加，還有一些比較輕的第三方庫就可以手動拖入代碼添加進來，比如我們的項目中有一個獲取適配型號的第三方庫DeviceUtil，對于這類比較輕的庫盡量使用手動拖入代碼管理，畢竟項目中的framework多了，會影響app的啟動時間，這個在WWDC 2016 Session 406 - Optimizing App Startup Time的演講中有講原理;

Pods ：優秀的第三方庫管理工具，比如網絡請求AFNetworking，圖片加載SDWebImage等等比較重的第三方庫就可以使用Pods自動管理，當然你也可以使用Carthage來管理，具體使用哪個見仁見智，網絡上也有很多關于這個的討論。我們公司使用的是Pods，所以就是以Pods為主了

Appdelegate和首頁：Appdelegate和首頁是各個功能模塊的入口，所以放在頂部最顯眼的位置，(對于傳統Tabbar+NavigationBar App的首頁類文件可能會在對應的模塊下);

Assets.xcassets、info.plist：這部分相對Appdelegate在同一目錄下，但是放在最下面，這部分的操作頻率不是太多，Assets.xcassets里面的圖片，可以使用功能模塊放置添加(New Folder，以模塊命名)。

看到這里，有的人會想：一個項目直接按照功能模塊劃分不也挺好的么，每個功能模塊里面再按照MVC的模式劃分，以下面這個app為例

藝學機構版

劃分如下所示如下圖所示：

以功能模塊劃分工程框架圖

這兩種搭建項目框架的模式沒有孰優孰劣之分，只有得放到具體情境下面討論才有意義，不過很明顯，第二種以功能模塊劃分的模式適用于以小團隊開發(iOS端2-3人以下)，這樣每個人負責開發一個模塊，效率非常高。如果團隊人員比較多，則更適合采用***種模式，這樣開發效率更高，比如有人專門負責，網絡層代碼的編寫，有人專門負責UI界面的編寫，有人負責日志類的封裝編寫。

一些其他的小建議：

文件夾模塊使用英文而不要使用中文命名，并且使用正確的英文名不要使用拼音;

1. 名稱首字母大寫;
2. 文件夾層數不要太多，最多三層;
3. 快速定位某一個類文件的位置，光標在定位在類文件里面，按快捷鍵command+shift+J并可定位他的具體位置模塊。

demo的GitHub地址