[HMLY]7.iOS MVVM+RAC 从框架到实战

Posted 2020-08-28

1.MVVM浅析

MVC是构建ios App的标准模式，是苹果推荐的一个用来组织代码的权威范式，市面上大部分App都是这样构建的，具体组织模式不细说，iOS入门者都比较了解（虽然不一定能完全去遵守），但其几个不能避免的问题却是很严重困扰开发者，比如厚重的ViewControlller、遗失的网络逻辑（没有属于它的位置）、较差的可测试性等。因此也就会有维护性很强、耦合性很低的一种新架构MVVM（MVC引申出的最新架构）的流行。

MVVM虽然来自微软，但是不应该反对它，它正式规范了视图和控制器紧耦合的性质，如下图：

　　　　　　　　　　　　　　　　　　　　MVVM图示

ViewModel:相比较于MVC新引入的视图模型。是视图显示逻辑，验证逻辑、网络请求等存放的地方，唯一要注意的是，任何视图本身的引用都不应该放在VM中，换句话说，就是VM中不要引入UIKit.h（对于Image这个，也有人将其看做数据来处理，这就看个人想法了，并不影响整体的架构）。

这样，首先解决了VC臃肿的问题，将逻辑代码、网络请求等都写入了VM中，然后又由于VM中包含了所有的展示逻辑而且不会引用V，所以它是可以通过编程充分测试的。

ReactiveCocoa是结合了函数式编程和响应式编程的框架，也可以称为函数响应式编程（FRP）框架，强调一点，RAC虽然最大的优点是提供了一个单一的，统一的方法去处理异步的行为，包括delegate方法，blocks回调，target-action机制，notifications和KVO.但是不要简单的只是单纯的认为他仅仅是减少代码复杂度，更好的配合MVVM而已。

它最大的与众不同是提供了一种新的写代码的思维，由于RAC将cocoa中KVO、UIKitEvent，delegate，selector等都增加了RAC支持，所以都不用去做很多跨函数的事。

如果全工程都使用RAC来实现，对已同一个业务逻辑终于可以在同一块代码里完成了，将UI事件，逻辑处理，文件或数据库操作，异步网络请求，UI结果显示，这一大套统统用函数式编程的思路嵌套起来，进入页面时搭建好这所有的关系，用户点击后妥妥的等待这一套联系一个个的按期望的逻辑和次序触发，最后显示给用户。

3.本篇对两者的理解运用

在此次介绍中，会使用MVVM+RAC结合的方式，搞定一个添加上拉加载及下拉刷新的列表，所以更多的诠释MVVM思想，而不是RAC的逻辑链式操作（这一点用登陆界面来写更能体现），RAC在此扮演的更大一部分的角色是更好的解耦，减少代码复杂度，使代码层次分明、逻辑清晰便于维护升级。

二、框架部分

1、框架目录详解

首先介绍一下本框架的目录结构，如下图：

1、Frameworks

存放系统库的虚拟文件夹，目前搭建框架的时候需要手动添加一个名称为Frameworks的虚拟文件夹，这样你在Build phases中添加的系统库会自动归入此文件夹，不会直接在外部显示以至于打乱目录结构。系统库添加流程如下:

细心的会发现此目录中有两个相同的Frameworks，这是为什么？最上面的那个frameworks是在自己搭框架自己添加的，当时项目还很单纯，问题是出在下面那个Pods Target上，添加它之后就会自动给你生成一个旭牛的frameworks的文件夹，那又该问了，为啥不直接用下面那个呢？（两者之间并没有冲突）

2、cocoapods

当开发iOS应用时，会经常用到很多第三方开源类库，比如JSONKIT，AFNetworking等等。可能某个类库又用到其他类库，所以要使用它，必须得下载其他类库，而其他类库又用到其他类库，”子子孙孙无穷尽也“，反正在早期程序员是会体验到这种痛苦，心酸，手动一个个去下载所需类库是十分麻烦的。

 

还有另外一种情况，项目中用到的类库有更新，必须得重新下载新版本，重新加入到项目中，十分麻烦。

CocoaPods就是帮你解决上面问题的，话说这玩意应该是iOS最常用最有名的类库管理工具了，作为iOS程序员的我们，掌握cocoapods的使用是必不可少的基本技能了。

 

3、AppDelegate

这个目录下放的是APPDelegate.h(.m)文件，是整个应用的入口文件，所以单独拿出来。一会儿告诉你如何写一个简洁的AppDelegate，会在这个文件夹里添加一些类，所以将其放入一个文件夹内还是很有必要的。

4、Class

工程主体类，日常大部分开发代码均在这里，又细分了好多次级目录。

通用类

·General:通用类（文件夹项目移植过程中都不需要更改，就能直接使用的）

　　。Base:基类（整个框架的基类）

　　。Categories:公共扩展类（就是一些常用的类别，比如分享啊什么的）

　　。Core:公共核心类（一般存放个人信息，接口API等）

　　。Models：公共Model(公用的一些数据模型)

　　。Views:公共View(封装的一些常用的View)

工具类

　　·Helpers:工程的相关辅助类（比如类似数据请求、表单上传、网络监测等工具类）

宏定义类

　　·Macro : 宏定义类（就是整个应用会用到的宏定义）

　　　　。AppMacro.h app项目的相关宏定义

　　　　。NotificationMacro.h 通知相关的宏定义

　　　　。VendorMacro.h 第三方相关的宏定义

　　　　。UtilsMacro.h 为简化代码的宏定义

　　　　。.......等等

APP具体模块代码类

　　·Sections ： 各模块的文件夹（一般而言，我们以人为单位）

　　　　。LWSections 老王的文件夹

　　　　。......等等

每个成员的文件夹下是其所负责模块的文件夹，比如苍老师负责php界面模块，如下

·PHP ：模块名，也可以是首页（HomePage）...等等

　　。ViewControllers 界面控制器存放处（这是文件夹名）

　　。ViewModels 打杂的(MVVM的核心、解耦合、处理逻辑等)

　　。View 界面相关View存放处（界面相关子View）

　　。Models 数据模型存放处（各种单纯的数据模型，一点都不胖，是标准的瘦Model）

这就是标准的MVVM了

 

第三方类库

　　·Vendors ： 第三方类库/SDK,如UMeng、WeiboSDK、WeixinSDK等等。

刚才的cocoapods确实管理着大部分的第三方库，这里建立第三方库目录原因有两个：其一，并不是所有的你需要的第三方库都支持pods，所以还是需要手动添加一些类库。其二，一些第三方库虽然支持pods，但是需要我们去更改甚至自定义这个第三方，此时也需要放入这里，也防止使用pods一不小心更新掉自定义。

 

5、Resource

 

这里放置的是工程所需的一切资源，如下

·Fonts 字体

·Image 图片（当然你可以添加至Assets.xcassets）

·Sounds 声音

·Videos 视频

 

2、基类详解

这里着重讲解一下VC、V、VM的基类，其他的模式与View类似所以略过，其中TableViewCell的基类稍微特殊所以也提一下。

目前的基类如下图：

曾经笔者感觉基类不顺眼，曾经尝试将基类全部干掉，然后遇到了一些麻烦。