深入讲解iOS从0到1搭建高可用App框架

　　今天和大家一起分享“iOS从0到1搭建高可用app框架”，希望可以在工作或生活中帮助你，有需要的小伙伴，可以参考一下。课课家教育平台提醒各位：本篇文章纯干货~因此大家一定要认真阅读本篇文章哦!

    最近在搭建新项目的iOS框架，一直在思考如何才能搭建出高可用App框架，能否避免后期因为代码质量问题的重构。以前接手过许多“烂代码”，架构松散，底层混乱，缺少规范，导致团队开发时代码风格迥异，清晰的项目结构和良好的代码规范是保证产品质量的关键，下面分享一下我的架构思路。

　　架构图：

　　架构原则：易读性、易维护性、易扩展性。

　　一、思考

　　做好一件事，花在思考上的时间应该多于执行。

　　首先根据产品需求和设计图，脑中先建立一个产品架构：

　　1. 产品的定位是什么。

　　社交?媒体?游戏?运动?音视频?电商……要搞清楚你要做一个什么类型的App，不同类型的产品，技术选型也有所不同，在这我是搭建一个基础App架构，可以在此基础上拓展社交、电商、音视频等!

　　2. 技术选型

　　根据当前产品的需求以及未来可能有的需求(我怎么知道未来会有什么需求?可以参照竞品，可以发挥想象，如果产品说：“我们要做IM文字聊天，只做文字!不做音视频，以后都不做!” 类似这样的承诺，你如果信了他的邪……后面的故事就精彩了。。哈哈哈哈哈哈。。。。所以说这时候你就要考虑到后面会有语音+视频聊天，在设计的时候不要偷懒，预留一定空间，当某天产品反悔的时候，你可以微微一笑，从容应对。

　　一把拉回话题，接着说技术选型，通常我会选择一些当下比较热门、好用的第三方框架，例如： YYKit ，YYKit 是一组庞大、功能丰富的 iOS 组件，包含Model解析、图片加载、缓存等基础服务，都是基于Category设计的，使用方便且性能高于一些老的框架，用过的都说好。

　　其他框架的选择可以根据项目需求，去GitHub上搜索，星星多的每个都看一下，会给你增加一些思路。

　　程序猿长得可以保守，思想一定不能太保守。

　　合适的框架

　　一个合适的框架不是银弹，在我看来框架要解决的问题从来不是：有了框架之后，工程就能无比正确地进行下去。好的框架能够做到的事仅仅只是：降低通用问题的复杂度和减少发生错误的可能性。个人认为一个良好iOS App框架应该是有如下特点：

　　定义清晰的层次结构。

　　展现层(Presentation layer)，负责管理UI和UIViewController

　　逻辑层(Business/Service Layer)，负责逻辑数据的定义和转发，起到承上启下的作用。

　　数据访问层(Data Access Layer)，负责具体API构造，网络请求，数据持久化等。

　　各层根据业务逻辑的复杂性内部又会使用单层或者多层结构。以数据访问层为例，一般又可以细分为网络层，持久化层。而一般而言，展现层(UIView和UIViewController)都是直接使用逻辑层提供的Model进行展现，但是某些场景下往往需要不同的Model有相同的界面展示(如我们的App易信中，会话界面，收藏界面，问一问功能都需要进行图片的展现，但这三个模块下的Model定义并不一致)，这就需要增加额外的ViewModel层用于粘合展现层和逻辑Model。

　　横向上，各模块互相独立，仅通过有限的几个接口进行通讯。最理想的状态是除核心模块外，其他模块都是可拔插。纵向上，各层次间依赖关系清晰，基本不出现逆向依赖的情况。

　　横向模块一般依赖于业务需求，常被定义成各种Service或Manager。一种好的做法是有个统一的Service管理器负责相应Serivce的加载，卸载，监听和分发App级别的通知给相应Service，如前后台切换，收到内存警告等。这样做一方面容易实现上面说的模块的可插拔化，另一方面也保证了公用特性处理的一致性。在这方面微信就做得不错，基本所有的模块都是从MMService继承而来，由MMServiceCenter进行管理。当然从dump出来的头文件也可以发现一些管理上的紊乱，比如一些ViewController都是继承自MMService。

　　纵向的层次划分基本各个App不会有太大区别，一般可以分为三个层次：

　　遵守SOLID原则和慎用各种设计模式。这是个老生常谈的话题了，并不是iOS开发独有，展开讲可以讲上几天几夜，不赘述。

　　定义自己的UI基类：UIView，UIViewController，UITableviewCell。这一点的好处不言而喻，所有的子View，Controller，Cell都能够很方便的继承基类的共有的行为，样式。但也会引进很大的管理风险：组内成员总会经不起诱惑往基类塞各种并不普适的特性，引起基类权责的无限膨胀。大基类不仅增加组内成员对代码的理解难度，同时也增加出现问题时的排查难度。从这方面讲，微信的UIViewController基类设计就极端失败：MMUIViewController。

　　提供方便好用的工具类。一些好用的工具类往往会成为框架重要的有机组成部分，方便快捷地解决局部问题，同时又不引入过多的复杂度。NSTimer的retain cycle是个很容易掉去的坑，那么提供一个基于Block或者weak delegate的NSTimer的封装就是不错的选择。使用KVO容易发生add和remove的不配对调用，那么就引入THObserversAndBinders或者FB的KVOContorller。某些核心模块需要被多个模块依赖时，引入类似XMPP的GCDMulticastDelegate就能够方便地进行解耦。

　　好的范例。在前几年使用C++的那段暗无天日的日子里，我常想的一个问题是：如何在API层面去限制和规避一些错误。比如往线程池里面扔的task必须是堆上分配的对象，那么如何去强制传入的指针指向的是堆地址而不是栈地址呢?这种傻问题大部分情况下是无解的，有时候有解却是个异常别扭的解。而现在我更相信破窗理论所提供的可能性：做好示范，接下来的一切都会水到渠成。

　　二、搭建目录结构

　　如上图，我是这样搭建App目录结构的，从下到上，使用Pods管理第三方框架，将第三方框架进行二次封装，供给顶层使用，尽可能减少各模块之间的耦合度，只为更清晰。

　　三、封装基础类

　　1. AppDelegate是应用的代理，应用级的事件都委托它处理，包含启动退出、推送等事件，以及IM、支付等第三方的回调，这使得AppDelegate内代码庞大，错综复杂，十分不利于阅读和维护，因此我新增了一个AppDelegate+AppService类别，用来处理生命周期之外的业务，AppDelegate作为事件入口，具体实现直接调用类别里的方法，只为更清晰。

　　2. Modules包含了应用内的功能模块，根据底部Tab栏划分并关联实体文件夹(默认是虚拟的要手动建立实体文件夹拖进来)，每个模块内使用的是MVC模式，有人会问为什么多了Resource和Service文件夹，MVC是一种设计思想，并非死套路就仨文件夹，根据实际需求适当增加，在这我选择在Service封装数据请求，VC里调用拿数据即可，至于Resource为什么在这，我认为当功能模块层级较多时，每个大功能模块都对应许多资源，对应到模块内用起来方便，当然也可以放到最外层的Resource文件夹里，建立对应的模块名称，在这儿我是选择把公共的放到最外层Resource里，功能相关的放到模块里的Resource文件夹内，只为更清晰。

　　3. Manager的定义是全局基础服务，通常使用类方法或者单例来实现，主要包含对应用、用户的管理和服务，例如网络状态监听，广告页应用介绍页等;用户快速登录退出操作以及登录状态的获取等。只为更清晰。

　　4. Utils文件夹内主要包含全局通用工具，来源于对三方框架的二次封装，或是自己写的工具类。在这个项目里，我封装了带AES加密网络请求工具，全局Toast提示，广告页等。只为更清晰。

　　5. Base文件夹用来存放项目的基类，基类作用包含一些定制化的内容，例如页面样式，空数据页面等，使用基类来实现，可以统一控制，利于维护，减少冗余，也为更清晰。

　　6. 第三方文件夹放一些第三方的类库和对第三方封装，比如第三方登录、支付、IM等，现在项目我还没有添加第三方框架。

　　7.全局宏顾名思义是定义了一些全局通用宏。我这里定义了四个：

　　UtilsMacros定义的是一些工具宏，比如获取屏幕宽高，系统版本，数据类型验证等;

　　URLMacros定义服务器接口地址以及环境开关;

　　FontAndColorMacros定义全局用的色值、字体大小，这里建议跟设计师共同维护一个设计规范，例如：定义一个主色调宏 MainColor，色值是 0x333333，我们全局使用MainColor宏作为背景颜色，当某天App改版，色值改变，我们只需要去更改 0x333333即可，其他代码不需要动，同时也能一定程度约束设计师，不要随便增加一种颜色，非常接近的颜色应当使用一个。如果设计师不愿意维护这个规范，你可以尝试打一架，打不过的话，就只能自己维护了，只为更清晰。

　　ThirdMacros 包含第三方框架相关的定义，例如keySecret等。只为更清晰。

　　8. 资源文件，上面说到过，这里我是存放了全局的一些资源文件，功能模块的我放到了模块内的Resource文件夹内，个人喜好，只为更清晰。

　　9. CocoaPods是iOS项目的依赖管理工具，开发iOS项目不可避免地要使用第三方开源库，CocoaPods的出现使得我们可以节省设置和第三方开源库的时间。

      看完文章的小伙伴，有什么问题可以提出来，课课随时为你解答。如果还想了解更多关于这方面的只是内容，也可以随时登录课课家教育平台进行浏览哦~这上面有全面的只是内容，还有视频教学哟~随时欢迎你的登录。