前言
标题为什么要加个问号,因为我自身阅读了很多关于所谓APP架构的文章、博客、资料等等,不论是cocopods组件化、还是用精妙的目录结构、各种设计模式去尝试构架一个低耦合、模块复用性高的APP,似乎都存在诸多疑问,无法解决。没有一个统一的设计原则,那一部分代码改写到哪里,我一直很困惑。
在阅读了泊学的文章后,我觉的,这个困惑似乎有中拨开云雾见太阳的感觉。故而添加了感叹号。
APP的工程结构
在一个APP中,随着长期的维护,以及开发工程师的轮换。项目越来越臃肿,越来越庞大。
怎么样的工程结构,怎么样的代码书写原则是优秀的,是一直以来我思考的问题。
以下的文件分类模式,我觉的给了我答案。
- A - 和APP启动相关的代码,配置以及资源;
- B - 和UI的显示以及交互相关的代码;
- C - 对UIKit的公共扩展;
- D - 存储数据的model
- E - 使用的第三方库
分类确定了以后,选用怎样的方式去搭建项目?
cocopods? Carthage? 或者还有其他的方式?
对于B/C/D这三个部分,由于彼此独立,为了方便同步开发,并且,让C与D的代码可以充分的复用,我们在项目里面采取Framework的形式去进行管理。
其中:
- XXX_iOS 里是和UI的显示以及交互相关的代码;
- XXXUIKit 里面是整个项目中会用到的对UIKit的公共扩展
- XXXDataKit 里面是真个项目的数据存储以及访问接口,可以视作APP的View Model以及Model;
那么对于A的部分:
其实就是AppDelegate、 inforplist、*.strings等文件,当然,包括资源文件。
对于E的部分,说实话,在参考了诸多的文章和博客之后,对于选用cocopods还是选用carthage,我没有任何的偏向,在这里,我选择了不如pod自动化程度高,但入侵性小的carthage方法管理第三方库。
OK,按照以上的原则,我们搞定了之后的项目,截图如下:
2018-11-29-15-33-50.jpg
那么,目前为止,项目的文件目录就搭建好了。
本文参考文章 泊学APP开发系列
如有侵权,请即刻告知。
网友评论