优雅快速的搭建iOS工程框架搭建的探讨

674 阅读4分钟

一个简洁优雅的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. 文件夹层数不要太多,最多三层;
  4. 快速定位某一个类文件的位置,光标在定位在类文件里面,按快捷键command+shift+J并可定位他的具体位置模块。

demo的GitHub地址