iOS 从0到1搭建高可用App框架（二）

架构图：

架构图

效果图

思考：

一、面对一个版本迭代频繁，改版频率高的项目，如何设计才能避免代码越改越乱？

二、当业务极其复杂时，如果减轻VC的压力，让代码更清晰？

三、如何正确选择第三方框架？都需要考虑哪些因素？

正文：

直面问题，解决问题：

一、许多创业项目为了赶时间上线，前期没有框架设计，没有代码规范，每个人随意发挥，不出几个月就会出现 产品体验差、崩溃率飙升、开发进度缓慢等问题，不得不进行重构。在战略角度上也许是对的，先占坑再完善，但在架构角度这是不可取的，还是要严格遵循“高内聚，低耦合”的理念，确保框架由底层服务到顶层业务，各模块分工明确，各司其职，相对独立，模块间通过接口调用，严禁在A里直接使用B，B里直接使用C，这样会使得各模块藕断丝连难舍难分，后期只会越来越乱。

很多时候，现在的问题都是当初偷懒埋下的祸根，合格的程序员基本都是懒人，但摔的多了总要长点记性。适当克服一下惰性，前期将框子搭起来，真正的去面向对象编程。

二、我曾接手过一款直播App，光直播间ViewController代码就5500行，里面掺和着接口请求、数据转换、视图管理、业务逻辑等等，读起来十分费劲，Bug定位比较困难，想重构却无从下手，这种情况的发生首先是没有严格遵循模块化的设计理念，各模块没有各司其职，其次是过于严格的遵循了MVC设计模式，只创建了Model View Controller三个文件夹，VC的压力自然非常大。

在我理解来看，MVC只是表达了一种模块化思想，并不需要严格遵循MVC的目录格式。

如上图，我将每个模块在MVC的基础上又抽出了两层，分别是Logic层和Service层。Logic文件夹内，存放在每个VC的逻辑处理类。

咱们的目的是解放VC，ViewController顾名思义是视图控制器，不应做太多与其不相关的工作，将逻辑处理交给对应这个VC的Logic类，Logic承担着逻辑处理和Service的调用拿到数据并解析，通过delegate回调给VC，VC拿到已经处理完毕的数据，去渲染视图。

这样做的话，VC内只剩下与Logic的交互，还有管理View的代码，必然清晰很多。

模块结构

三、大部分应用为了快速开发，都会使用一些第三方框架，但第三方框架如此之多，我们该如何选择才能够发挥它们最大优势？

首先要分析自己的应用，都用得着哪些框架，在同一类型的框架里选择的宗旨是——符合自身且维护及时，超过一年没更新的就要慎重了，下面是我选择时的一些思考：

1.网络框架

网络请求是一款APP必须的，大家通常都会选择AFNetworking作为基础网络框架，但这只是个基础框架，虽说可以直接调用请求数据，但如果有一些其他需求，例如加密或者加公共参数等，想要满足就比较费劲了，所以大多数开发者会对其进行二次封装，目的为了自定义一些需求，可以自己掌控并处理请求和返回数据，也为将来如果更换网络框架，减少代码改动量。很多人自己封装一些简单的Post Get请求方法，中小型应用使用起来也足够。

当前框架中我最开始选择的是PPNetworkHelper，原因是比较简单易用，其中还包含了缓存机制。后来看了猿题库的网络库YTKNetwork，引入使用了一下，发现使用方法跟PPNetworkHelper完全不同，YTKNetwork的思想是抽象每个接口为一个对象，实例化接口对象去发起网络请求，从而可以针对每个请求定制化，还有一些其他的功能，灵活性比较强，适合稍微复杂一些的项目，框架中两种我都保留了，大家可根据项目实际情况进行选择，但建议都了解一下，特别是后者。

YTKNetwork 实现数据请求

2. 基础组件库

之前就提到过的，功能强大，性能优秀的——YYKit

它包含了解析数据，缓存，图像处理，文本处理，异步绘制等组件，当然也有些瑕疵下面说

YYModel— 高性能的 iOS JSON 模型框架。

YYCache— 高性能的 iOS 缓存框架。

YYImage— 功能强大的 iOS 图像框架。

YYWebImage— 高性能的 iOS 异步图像加载框架。

YYText— 功能强大的 iOS 富文本框架。

YYKeyboardManager— iOS 键盘监听管理工具。

YYDispatchQueuePool— iOS 全局并发队列管理工具。

YYAsyncLayer— iOS 异步绘制与显示的工具。

YYCategories— 功能丰富的 Category 类型工具库。

选择这个框架的原因是功能和性能都比较强大，用一个框架就可以做很多事，而且YYKit的设计思想是category，几乎没有入侵性，使用起来也非常方便。

但是同事发现YYWebImage— 这个高性能异步图像加载框架可能有点过时，因为其使用的是NSURLConnection请求，而SDWebImage已替换成了URLSession。所以图像异步加载上，我还是选择更加专业的SDWebImage。

YYKit

3. 布局框架

这里想必最大的分歧不是框架，而是布局方式，我了解的开发者通常有三种布局方式，分别是：代码计算frame、Masonry代码约束，SB/xib直拖约束。

我认为三种方式各有优缺点，不做评价，免得被骂，我个人是灵活运用，没有瞧不起任何一个，在不同的场景下，使用最合适的方式，才能达到最佳效果，举个栗子：“关于我们”，一个简单展示的页面，这时候通过xib拖出来这个页面，应该不超过5分钟，手写代码计算frame也许得10分钟，而且！代码写的东西不够直观，其他同事不能直接的看到你这个页面是什么样子。所以无论哪种方式都不是绝对的不好，也没有绝对的好，看场景，选姿势。

4.上下拉刷新框架

大部分应用都会有TableView或CollectionView，上下拉刷新是比较常用的，MJRefresh提供的功能比较强大，支持自定义，提供样式齐全，更新及时，所以，我选它！

MJRefresh

5. Toast提示

比较主流的两款Toast提示框架可供选择，分别是 MBProgressHUD 和 SVProgressHUD，二者更新都比较及时，功能也都类似，根据个人习惯了，选择哪个不重要，重要的是要对其二次封装，让它变得更好用，框架中我封装了一个MBProgressHUD+XY的category，类方法的形式调用。

MBProgressHUD

关于其他框架的选择，其实道理一样，首先要了解他们的优缺点，本着符合自身且维护及时的宗旨去选择就没有错。

以上内容的源码都整理在GitHub – UniversalProject框架内，大家可以下载参阅，顺便动动小手指点颗✨