一个简单优雅的iOS工程目录，可以帮助团队提高开发效率，同时让你心情愉快地码字；相反，杂乱的目录会让人心情烦躁，降低团队开发效率。不知你是否有同感？欢迎大家在评论区写下自己的感受。首先我想说：本文提到的工程架构适用于纯代码开发的团队，也适用于Storyboard开发的团队；本文适用于传统Tabbar+NavigationBar构建的应用，也适用于其他非传统应用；这篇文章特别适合团队新成员了解项目整体结构，快速开发项目和纯OC项目，文件夹和class文件可能需要自己修改，Xcode项目工程目录为如下：项目框架搭建图如上图所示，我将项目分为9个部分，GitHub地址：Models：模型数据类，所有自定义数据模型都要放在这里；views：视图类，需要为功能模块创建一层文件夹，自定义功能模块的所有视图类都要放在给定的文件夹下，除了手动拖入的第三方UI控件外，第三方UI应该放在Vendor文件夹下；Controllers：控制器类，所有的控制器类都放在这个文件夹下，如果有BaseViewController，BaseNavigationController可以放在Base文件夹下（可以在这个目录下新建Base文件夹），对应功能模块的Storyboard是也放在这个目录下。把Storyboard放在这里比放在View里更方便（我们项目开始在Views目录下新建Storyboards文件夹，用来存放所有的Storyboard。这种方式的缺点是对应Storyboard和功能模块的VC距离太远远，操作不便）；Resources：资源文件夹，存放项目需要的音视频，图片（webP格式的图片或者内存大的png只需要用一张背景图片），字体，动画等资源文件放在这里；Util，一些工具文件夹，如Objective-C分类文件夹Category、swift扩展类文件夹Extension、管理单例类文件夹Manager等；vendor，一个手动管理的第三方库，上图中的BookRoom就是我们FCSapp的BookRoom模块，都是封装成framework引入的，所以适合加在这里，还有一些比较轻量级的第三方——可以通过手动拖入代码来添加派对库。比如在我们的项目中，有一个获取适配模型的第三方库Devic。eUtil，对于这种比较轻量级的库，尽量使用手动拖入代码管理。毕竟项目中的framework太多，会影响app的启动时间。这个在WWDC2016Session406——OptimizingAppStartupTime的演讲中有解释；Pods：一个优秀的第三方库管理工具，比如网络请求AFNetworking、图片加载SDWebImage等重度第三方库都可以由Pods自动管理。当然你也可以使用Carthage来管理。不同的人对使用哪一种有不同的看法。网上也有一些。关于这个有很多讨论。我们公司使用的是Pods，所以Pods是主要的Appdelegate和主页：Appdelegate和主页是各个功能模块的入口，所以放在最上面最显眼的位置，（对于传统的Tabbar+NavigationBarApp主页类文件可能在相应的模块下）；Assets.xcassets、info.plist：这部分和Appdelegate在同一个目录下，但是放在最下面。这部分的操作频率不要太多。Assets.xcassets中的图片，可以使用功能模块放置添加（NewFolder，以模块命名）。看到这里，可能有人会想：直接按照功能模块来划分一个项目，然后再按照MVC模型来划分各个功能模块不是很好吗？以下面这个app为例，艺术学院版本的划分如下图所示：将项目框架图按功能模块划分，两种构建项目框架的模式没有区别。只有在具体情况下讨论才有意义。分工模式适合小团队开发（iOS端2-3人以下），让每个人负责开发一个模块，效率很高。如果团队人数较多，更适合采用第一种模式，这样开发效率更高。比如有人负责网络层代码的编写，有人负责UI界面的编写，有人负责日志类的封装和编写。其他一些小建议：文件夹模块要用英文命名，不能用中文命名，正确的英文名不要用拼音；姓名首字母大写；文件夹层数不宜过多，最多三层；快速定位一个类文件位置，光标定位在类文件中，按快捷键command+shift+J定位到其具体位置模块。demo的github地址
