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

前言

本文是继《iOS 从0到1搭建高可用App框架》之后，通过项目实践以及同行交流思考总结出来的一些新的架构思想，但初心仍不变，目的为搭建高可用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框架内，大家可以下载参阅，顺便动动小手指点颗

原文地址：

http://www.jianshu.com/p/f09a4f21e0f9

下面对你也许有帮助：

• iOS 团队编码规范—— 团队开发需要共同遵守的代码规范

• 代码注释，教你用快捷键+代码块实现快速注释—— 让注释不再是负担，快捷键帮你解决

• 通用工具类宏定义—— 进一步提升编码效率

• 以上属于臭码农原创，若有雷同属巧合，如有错误望指正，转载请标明来源和作者。

• iOS开发整理发布，转载请联系作者授权

↙点击“阅读原文”，加入 

『程序员大咖』