iOS架构之路？iOS架构之路！（一）

前言

标题为什么要加个问号，因为我自身阅读了很多关于所谓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开发系列

如有侵权，请即刻告知。