iOS开发工程架构设计

妖狐艹你老母 2022-08-09 10:58 2阅读 0赞

## 转载请标明出处，尊重原创。http://blog.csdn.net/wrathli/article/details/49282349 ##

作者：WrathLi

## 开篇 ##

搞了几年的iOS开发，经历各种血的教训。替乱成一坨翔的系统做过重构，也从头设计新的系统架构，总结出不少经验和观点。至于观点好不好就见仁见智吧，时间宝贵，废话少说，凭着良心直接上干货。待续…

## 工程架构图 ##

![Center][]

## 开发工具库 ##

之前有发现不少人喜欢做一套开发框架来开发APP，当然这些开发框架里面有不少技术很牛B滴。不过我觉得用开发框架来开发app是很不好的方法。首先，APP开发创意的成分占的比例很大，没有任何一个框架可以适合所有的app，基于框架来开发app就是对创意的最大束缚。第二点，开发者的技术水平参差不齐，框架设计者的技术很牛，整个框架都很熟悉，有哪些功能，哪些代码怎么写一清二楚，但你不能保证每个使用框架的人都很牛，都能看懂你的代码吧，尤其是在注释不够具体详细的情况下，熟悉整个开发框架比摸清老板身上有几根毛还难。如果有人说“有不需要你熟悉整个框架，只要了解你要用的部分就行了”，那我就告诉你这个人纯粹在扯淡，一个大的开发框架不是一个人能够维护的了的，多人一起维护，不管代码格式约定得多规范，都避免不了代码混乱，一不小心写错了一个地方，编译一下一大排红点就出来了，还找不到出错的地方。最极端的情况，要是框架的设计者集体离职了怎么办。第三点尤为重要，使用框架来开发app不可避免的会导致代码量过多，一个hello world的app打包处理的ipa就有几十MB那不是蛋疼吗。

其实，苹果公司的做法我认为是目前最好的。基于最简单的MVC框架，各个工具以framework、dylib或者静态库的方式封装起来，要用的时候再导入工程使用，如<Foundation.framework>、<UIKit.framework>等。所以我认为将开发工具按照功能模块单独建立工程打包封装成工具库是最好的办法，维护的时候将各个工具工程分给多人单独维护，每个人负责的部分比较单一，代码也比较易懂。就算出现问题也可以将影响范围控制在最小。工具库以framework的形式封装是最好的，比较易于使用，拷贝复制，导入工程就和系统的framework类似。

### 自定义开发工具库 ###

自己做一些便于开发的工具库来缩短开发周期，苹果公司提供的一些工具为了适合所有人开发做得比较基础底层，我们自己使用的时候可以再做一层封装，提供一些好用的宏定义，系统参数的获取，识别，判断等。本人之前也做过一系列的开发工具，系统配置系统方法的扩展、数据库管理，网络请求，自定义UI控件等工具库，用起来还是很方便好用的。

### 第三方工具库 ###

这个就没什么好说的了，很多人都知道。像微信分享SDK、支付宝SDK等。这些工具库主要是要做好管理，及时更新。

## 具体项目 ##

之前所讲的都是所有项目共用的工具，与具体项目无关，这里开始讲具体项目的结构规划。不过在讲之前我要重点说明一下使用纯代码开发app的重要性。

Storyboard,还有之前的xib都是苹果公司提供的用来快速开发app的工具，不过这适用于个人开发小app时使用，如果工程规模大需要多人协同开发的话，你就会发现这些工具会带来很多的问题，首先由于这些工具将界面代码都封装了，阅读代码的时候就很不直观，维护起来很麻烦，其次如果是多工程的架构的话，这些文件要用bundle打包，使用的时候还有再去bundle中获取，也是件很烦的事情，所有强烈建议使用纯代码来开发。

讲完纯代码的重要性就来讲讲具体项目的架构。系统架构要考虑app未来的发展，功能的新增，一旦项目庞大起来，不可避免的就会出现很多的插件。所以绝对不能做只有一个工程的架构。如果所有代码都写在一个工程里面，又把第三方的库都直接拖到工程里面，到了最后需要做插件化的时候你就会发现这绝对是一个噩梦，每个插件都要另外重写逻辑，主工程引用插件工程又会出现一大堆的重复定义，一定会让你崩溃。所以在一开始开发项目的时候就要想好工程的架构，为app未来的发展留出空间。不要贪图省事，认为一个小小的app还要搞那么复杂的架构有啥卵用。懒癌绝对是致命的，应该要抱着自己的app一定会发展壮大的心态去开发才行。

### 总逻辑工程 ###

顾名思义，这个工程是这个项目的核心，也是这个项目的顶层工程。这个工程里面应该只做逻辑部分的开发。必须是系统最核心，最公用的，比如图片、文字等资源的读取方法，网络请求的基类，各种模型对象的基类等等。总之就是最底层的代码，写完就很少修改的方法。这样可以避免插件工程里面重复做不必要的工作。

### 主工程 ###

主工程就不用细说了，就是实现app主要的功能，实现界面开发等等。因为是经常修改的工程，可以直接在主工程里建立target进行打包。也可以将主工程编译成静态库，再另外新建demo工程来建立多个target打包不同的版本。

### 插件工程 ###

当app的功能相当庞大的时候，就不能把所有的代码都写在主工程里面，主工程里面需要可以配置也可删除的功能，为了尽量减少对主工程的影响，就需要将功能插件化，这个时候就要建立插件工程来实现插件功能，最后编译插件工程，让主工程使用插件工程的SDK，建议SDK用静态库的形式来编译，因为就算是插件工程，改动也是比较频繁的。编译的结果应该在工程配置里面设置编译路径，再写个Aggregate脚本来编译不同的版本。最后在主工程里面设置SDK的引用路径，不要直接将SDK拖到主工程里面。这样插件工程也可以有自己单独的demo工程来做专项测试。

最后提醒，插件工程绝对不能引用主工程，否则会造成循环引用无法编译。

[Center]: /images/20220731/d10f43cd7e8b4f3cbd2485c3e5c31c04.png