一个简洁优雅的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界面的编写，有人负责日志类的封装编写。
一些其他的小建议：
- 文件夹模块使用英文而不要使用中文命名，并且使用正确的英文名不要使用拼音；
- 名称首字母大写；
- 文件夹层数不要太多，最多三层；
- 快速定位某一个类文件的位置，光标在定位在类文件里面，按快捷键command+shift+J并可定位他的具体位置模块。
