好像随着年龄的增长，对时间的感知就变得越来越弱了。总感觉2019年还是一个很新鲜的年份，但它却已经走完了，2020年好像很遥远的样子，但它已经到来了。来个总结吧，2019年，这一年有太多的酸甜苦辣。从工作、生活和规划三个方面展开说吧。

工作

年初原项目组有一位很厉害的开发离职了，当时是我俩共同负责一个项目。他开发经验比我多，而且工作态度和习惯都很好，是我见过的未数不多让我称赞的程序员。曾经一起工作的将近一年多时间里，我都以他为学习榜样。对于他的离职，我纠结了很长一段时间，自认这是对我对公司的一大损失。

后来很长的时间里，一直都没有招到合适的人，我便一个人扛起了项目。很多之前应该是两个人一起商量的问题都需要自己一个人去思考解决方式，渐渐的我不断磨练自己的独立思考能力。大半年下来，突然感觉自己被逼着成长了许多，从一个崇拜别人，向别人学习的角色变成了一个不惧怕任何技术难题，能够帮助别人解决困难的角色。

2019年学会的第一个最重要的道理，很多时候有一个可以依赖的对象，是会减弱自己探索和尝试的动力，而开发很多时候对技能的理解和掌握，乃至个人进步，都是要依靠自己的探索获取的。

写作

2019年共产出27篇博文，27是一个挺大的数量，但令我满意的文章到不是很多。博客内容质量的重要性应该是要远大于数量的，这一点后面注意到了。

对技术博客的写作今年做了一些不同的尝试。

首先对于月报的更新持续到今年7月份，共产出了一共13篇文章，就停更了。月报内容主要由三部分组成：

• 最近一段时间的bug修复经历和开发tip
• 阅读过的优秀博文
• 优秀的github库

第一部分，这个受开发经历的影响，就我个人来说，很多时候没有太好的经验可以写，到最后时感觉内容不好撑起这一个模块。
第二部分，出现过几次前期准备不够，最后一两天才去寻找素材，导致推荐内容很一般。
第三部分，优秀库的推荐，写到第十期时就感觉乏力的。当然我知道这里的内容是接近无限的，但是很多如果我都不了解，不使用，只读一个简介就去推荐，会有种不负责任的感觉。

还有一部分原因是，到后来关注的人越来越少，接到的反馈也越来越少，应该是跟质量下降有关。做这个东西也确实费时间，很多时候我就想如果这些时间去打磨一篇技术博客，可能效果会更好。而且月报给人感觉时效性更强，跟新闻类似，过了这个时间之后好像过时了一样，大家很少会特意翻看之前的内容，而普通的技术博客却不会有这种问题，解题思路，技术干货几乎不存在过时问题。

另外我也一直在观察给我启发的 “老司机iOS周报”，他们只有博文推荐和代码库推荐，由多位联合编辑共同完成，人员、时间、内容质量都不是问题。但就我观察得知，“老司机”的号召力和响应力也在不断减弱。技术类人员对内容聚合类产品的粘性是没有固定知识分享平台高的。一篇周报，十篇左右文章，大致看去，自己感兴趣的可能就两三篇，新窗口打开，导流到别的地方，有时间的话读一读，时间不够就放到收藏夹。一般在周报的停留时间不超过3分钟。

基于这些原因吧，我也就不再更新月报了，而是把时间分配到别的事情上去。

公众号

另外，开始尝试写公众号，名字叫“iOS成长之路”。文章更新不多，其中最主要的原因就是我习惯了写博客，而且博客有一套自己的workflow。一般我是先写博客，然后将文章复制到别的平台。像之前的简书和后来的掘金，都是可以全量复制的。

转到公众号时，虽然可以直接将Markdown转成公众号形式，但对图片却不识别，需要单独导入。我需要把github上的图片下载下来，放到公众号编辑界面。如果图多，就是项很繁琐的流程。而且公众号还限制了每天只能发一篇文章，所以后面更新了几次之后就不再更新了。如果有小伙伴知道解决方案的话，希望能够告知。之后的话，会想把公众号这个事情再推进下。

生活

那些经历

今年基本没有什么活动。

清明节，回家看妈妈，不自觉拍了很多家里，地里的照片，感觉老家哪里都是美的。那个我曾经抵触，一心想逃离的家乡，在这个春天里一下变得可爱，温馨起来。走到路上我想起曾经走在这里发生过的一切，到了家里我回想这个房屋里曾经发生过的一切，那些欢声笑语。记忆一点点展开，如果此时放弃工作，放弃所有，跟爸爸就在老家生活下去，也未尝不可，我这样想着，对未来的规划和期许，已经都不重要了。但是也只能想想，现实还有很多问题需要考虑，需要处理，我已经被社会规则裹挟着由不得自己了，这可能就是长大的无奈吧。

4月份中旬，参加了《天火》的电影宣发，见到了很多明星，但也并没有太多兴奋，就感觉明星跟普通人其实也没有太多不同。12月12号，电影上映，因为宣发时收到了很多到场礼品，就买了票去支持下，女友和我观点一致：电影很烂，昆凌演的一般，剧情太散。配备了近乎完美的制作团队，外加周杰伦的宣传，电影竟然如此扑街，真的很让人匪夷所思。今年娱乐活动极少，一共就去电影院看了两场电影，其中一部还是这种感受。剧情，剧情，剧情，这是电影的灵魂，真的很重要啊。

4月底，参加我们609寝室第一个结婚的室友婚礼，分别两年多了再相聚，大家都基本没变。我们还是曾经的我们，各奔东西，又再次相聚，真好。

4月份报名了半马，但是很遗憾没有中签，直接导致了去年的一项目标没有完成。

5月份没有出门，跟女朋友在家探索了很多美食的做法，每次做好吃的，我都会用手机拍下来，相册里已经有几十张美食照片了。做饭其实是一项很有趣的事情，洗菜，切菜，食材下锅一瞬间的滋滋声，出锅时的香气四溢，都能不断激发自己的食欲，这可比塑料彩盒包装的外卖有灵魂多了。所以这一年不光点外卖次数少了很多，厨艺还增进了不少。

6月份重新拾起了跑步的习惯，每天下午下班之前的半个小时都陪菲姐去园区跑道跑步，这个习惯帮助她减掉了十几斤肉，也帮助我在年度跑步计划中增加了将近200公里的里程。

7月份准备园区的篮球比赛，虽然每次练习都挥汗如雨，各种制定战术，尽心准备，但还是改变不了比赛被别的公司虐的结局。虽然篮球比不过他们，但是我们敲代码比他们厉害啊，这么安慰自己。但老实说，为什么我感觉打球比敲代码还有意思啊。教练，我想打球。

8月份，配父亲去郑州等肾脏配型，当时想的是父亲留在这里，等有手术消息了，我再赶过去，但是医院要求等待期间必须要有家属陪同，那就回不了北京了。跟公司说明情况之后想申请远程办公，当时想的是如果公司不同意就直接离职。最后公司领导商量之后决定同意我的请求，之后就开始了长达45天的在郑州远程办公。

9月份，工作日期间，我将作息时间调整到跟公司一样的点，有时候去附近的咖啡店，有时候就在家办公。这期间最大的挑战就是自律和需求沟通。因为有时候配父亲做检查，或者送饭，耽误一些时间，这个就要想办法从别的地方补上来，还有就是家里的工作氛围比着公司要差一下，注意力的持续状态要短一些。所以这段时间基本周六都会根据情况抽出时间用来补进度。当然远程办公最爽的一点就是时间可以自由安排，可以是忙完一项任务或者通过时间挪移，你就可以在任意时间段做自己能做的事情。

当然因为效率没有在公司高，所以空闲时间相较而言还是更少了。这里的调整就是时间规划和时间管理的内容了，这个在未来我会重点优化下。

10月份，参加我们609第二个结婚的小伙伴婚礼，还顺道去了一趟大学校园。校园里多了好几栋教学楼和宿舍楼，当年的公教没变，宿舍楼变成了女寝？图书馆还是那么霸气，甚至想进去找个地方看会书。多好的环境啊，为什么当初没有好好珍惜，努力学习呢。好像在回忆过往时，我从来都是责备自己不够努力，不够优秀。

但是好像这就是真的，2019年也是，我并没有拼进全力，很多事情都没有做好，我应该更加努力，多逼一逼自己才是。

11月份，一直陪父亲等的肾脏配型终于有了结果，父亲接受手术，我来郑州陪护。这段经历大多数记在博客里面，这期间确实让我成长了不少。后来父亲出院，我回北京的第二天在V站看到一个帖子，一个程序员长时间加班导致身体不适，去医院检查被诊断为CKD4期（慢性肾病4期）。而CKD5期就是尿毒症，就是父亲的那个病。虽然我在医院见过很多病人了，但这个病的魔爪伸到了程序员群体，还是很让我惊讶和担忧的。

不只尿毒症，很多病都在向低龄化发展。健康！健康！健康！这个真的非常重要，作息，饮食，这两个最容易导致身体出问题的环节一定要重视啊。

12月份，在天桥看了一场话剧《黄金百万》，演员均非科班出身，当时还只是第三场演出，所以整体感觉水分很大，甚至一度有中途撤离的冲动。话剧演出结束，演员讲述舞台背后的故事时，却让我得到了些意外收获。他们是由互联网圈，投资圈，主持人圈的几个朋友组建起来的，其中就有为人熟知的张泉灵和于光东。他们都不缺钱，也不指望依靠话剧挣钱，就凭着爱好，组织话剧社，在本职工作之余，挤时间进行排练，很多人都不在北京居住，但他们还是圆满的完成了这次表演。

这让我看到了一种生活态度，工作不应该完全占据生活，生活也不应该只是吃喝玩乐，我们应该发觉自己的爱好，潜力，去做一些能带给自己满足感，更有意义的事情，这样才是精彩的活着。所以2020年，我也会往这方面做一些尝试。

关于理财

看到很多人晒今年收益，50%，甚至120%。因为今年经济整体都是上行，大多数都是赚的，只是赚多赚少而已。像我这种理财小白，只是定投指数基金不动都有将近30%的收益。所以大家对于很多人的收益不要眼红，不要过于乐观。今年大好，明年是好还是坏谁也说不准了。理财的一条金科玉律就是，收益越大风险越大，能承受风险，有一定的专业知识，那就努力达到收益最大化。如果都做不到，那就不要定过高的目标，像我目前定的目标就是跑赢通货膨胀，保证手里的钱不贬值就行。

理财这项技能，可以看到上限还是很高的，以后会花更多的时间在上面做一些研究，补足这方面的能力，努力提高收益。

关于阅读

阅读方面，近几年看的书越来越少了，今年只有：
《软技能：代码之外的生存指南》
《图解TCP/IP》
《重构》
《未来简史》
《老人与海》
《白夜行》
《半小时漫画中国史+世界史》
《如何高效读懂一本书》

这里最推荐的就是《软技能》，它介绍了程序员在编程能力之外还应该具备哪些能力，涵盖职业规划，自我营销，学习方法，理财手段，健身，精神提升等方面。这本书影响了我对自己职业的看法，同时也让我对未来的规划更坚定，更清晰了一些。非常建议大家都读一读。

OKR总结

2019年OKR总结

O1:精进技术栈

总结：实现度较低，很多是因为时间问题，和对制定任务的难度预估不准确导致的。这一年对技术层面的提升总综合性，没有在某一点有所突出，今年需要做一些调整。

O2:攒更多的钱

总结：这几项定的目标都有些含糊了，工资外收入其实更像表达的是，写博客的打赏，和公众号的一些收入。总收入的目标其实没有意义，存款才有意义。

O3:运动健身

总结：跑步里程到是一个合理的目标，半马因为受外界因素影响，所以是一个不太好的KR。

2020年OKR

有些在2019年没有做好的事情，会在新的一年里持续的跟进优化。

O1：精进技术栈

KR1：刷20道经典LeetCode题目，输出2篇解题思路的文章

KR2：学习前端知识，优化博客小站

KR3：输出5篇对计算机知识总结的文章

KR4：维护一个Swift库，用于筛选项目中不用的文件

O2：个人成长

KR1：公众号粉丝达到500

KR2：学习基金知识，分析对比10种基金的数据表现

KR3：全年跑步里程400公里

KR4：阅读15本书

KR5：培养时间规划能力，总结并践行一份时间规划清单

运行环境：Xcode 11.1 Swift5.0
最近在参与一个项目从Objective-C（以下简称OC）转到Swift的过程，期间遇到了很多坑，这是一篇采坑日志。如果你也在经历项目的Swift化，相信会有一定的参考意义。

OC转Swift有一个大前提就是你要对Swift有一定的了解，最好是用Swift开发过一个项目，否则不建议直接做这种转换的尝试。我选择迁移的原因是自己使用Swift开发有一年多了，后来转移到了一个OC的项目组。而这个项目主要是我一个人负责，因为感觉Swift更顺手，才会有了这个项目迁移重构的过程。

自动化工具

有一个比较好的自动化工具Swiftify，可以将OC文件甚至OC工程整个转成Swift，号称排名第一的OC转Swift工具，准确率能达到90%。我试用了免费版中单文件的转化，但感觉效果并不理想，因为没有使用过付费版，所以也不好评价它就是不好。

另外Swiftify还有一个Xcode的插件Swiftify for Xcode，可以实现对选中代码和单文件的转化。这个插件还挺不错，对纯系统代码转化挺精确，对于第三方库的代码识别就不太好了，存在一些识别问题，还需要手动再修改。

虽然工具总是存在一些问题，但是对于某些场景来说比着一点一点改还是要更有效率的。

手动Swift化

项目由OC转Swift的过程本来就不是简单的”翻译“一下就完事了，Swift存在很多独有的特性，在转换工程中我们需要注意。

桥接文件

如果你是在项目中首次使用Swift代码，在添加Swift文件时，Xcode会提示你添加一个.h的桥接文件。如果不小心点了不添加还可以手动导入，就是自己手动生成一个.h文件，然后在Build Settings > Swift Compiler - General > Objective-C Bridging Header中填入该.h文件的路径。

这个桥接文件的作用就是供Swift代码引用OC代码，或者OC的三方库。

1
2

#import "Utility.h"
#import <Masonry/Masonry.h>

系统API

对于UIKit框架中的大部分代码转换可以直接查看系统API文档进行转换，这里就不过多介绍。

property(属性)和方法

Swift没有property，只有一个表示属性是否可变let和var，这个根据需求处理就行了。

注意点一
OC中一个类分.h和.m两个文件，分别表示用于暴露给外接的方法，变量和仅供内部使用的方法变量。迁移到Swift时，应该将.m中的property标为private，即外接无法直接访问，对于.h中的property不做处理，取默认的internal，即同模块可访问。

对于函数的迁移也是相同的。

注意点二
有一种特殊情况是在OC项目中，某些属性在内部（.m）可变，外部（.h）只读。这种情况可以这么处理：

1

private(set) var value: String

就是只对value的set方法就行private标记。

注意点三
Swift中针对空类型有个专门的符号?，对应OC中的nil。OC中没有这个符号，但是可以通过在nullable和nonnull表示该种属性，方法参数或者返回值是否可以空。

如果OC中没有声明一个属性是否可以为空，那就去默认值nonnull。

如果我们想让一个类的所有属性，函数返回值都是nonnull，除了手动一个个添加之外还有一个宏命令。

1
2
3

NS_ASSUME_NONNULL_BEGIN

NS_ASSUME_NONNULL_END

懒加载

OC代码：

1
2
3
4
5
6

- (MTObject *)object {
    if (!_object) {
        _object = [MTObject new];
    }
    return _object;
}

Swift代码：

1
2
3
4

lazy var object: MTObject = {
    let object = MTObject()
    return imagobjecteView
}()

闭包

OC代码：

1

typedef void (^DownloadStateBlock)(BOOL isComplete);

Swift代码：

1

typealias DownloadStateBlock = ((_ isComplete: Bool) -> Void)

单例

OC代码：

1
2
3
4
5
6
7

+ (MTDownloadManager *)shareInstance {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        instance = [[self alloc] init];
    });
    return instance;
}

Swift代码：

1

static let shared = MTDownloadManager()

id类型

初始化方法和函数销毁

OC先调用父类的初始化方法，然后初始自己的成员变量。
Swift先初始化自己的成员变量，然后在调用父类的初始化方法。
OC代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/// 初始化方法 - (instancetype)init:(NSString *)title { self = [super init]; if (self) { MTModel *model = [MTModel new]; model.isSelected = NO; self.array = @[model]; self.title = title; } return self; } /// 函数销毁方法 - (void)dealloc { //dealloc }

Swift代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

/// 初始化方法
override init(title: String) {
		// 注意该属性赋值在父类方法之前
		self.title = title
		super.init()
    let model = MTModel()
    model.isSelected = false
    self.array = [model]
}
/// 函数销毁方法
deinit {
    //deinit
}

NSNotification(通知)

delegate(代理)

1
2
3
4

@protocol MTDownloadDelegate <NSObject>
- (void)downloadFileFailed:(NSError *)error;
- (void)downloadFileComplete;
@end

1
2
3
4

@objc protocol MTDownloadDelegate {
    func downloadFailFailed(error: Error)
    func downloadFileComplete()
}

作者：Bohdan Orlov
原文地址：https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

在iOS开发过程中你是否对MVC的使用感觉很别扭？你是否对转向MVVM有疑惑？你听说过VIPER，但不清楚这个东西是否值得一试。

接着读下去，你会找到上面这些问题的答案。如果读完仍不能解惑，欢迎到评论区捶我。

接下来你将在iOS环境下构建关于架构模式的知识体系。我们将简要构建一些经典的例子，并在理论和实践上进行比较他们的不同。如果你需要更多关于任何一个特定的细节，请关注我。

掌握设计模式容易让人上瘾，所以要注意：阅读本文之前要问自己几个问题：

谁应该持有网络请求：Model还是Controller?

如何在一个新的View中向ViewModel传递Model

谁创建了一个新的VIPER模块：Router还是Presenter

为什么应该关心选用何种架构

因为如果你不这么做的话，总有一天，等这个类庞大到同时处理十几种事务，你会发现你根本无法从中找到对应代码并修改bug。当然，将这整个类了然于心是很难的，你会常常忘记一些重要的细节。如果你的程序已经处于这种状态了，那它很可能具有下面这些特征：

• 这个类是UIViewController的子类
• 你的数据直接在UIViewController中进行存储
• 你的UIView基本什么都没做
• 你的Model只是一个单纯的数据结构
• 你的单元测试没有覆盖任何代码

即使你认为自己遵守了苹果的指导，并按照苹果推荐的MVC设计规范进行开发，但还是遇到了这些问题。不要担心，这是因为苹果的MVC本身就存在一些问题，我们稍后会再来讨论它。

让我们定义一下好的架构应该具备的特点：
1、平衡的分配实体和具体角色的职责
2、把可测试性放在第一位（通过合适的架构，这将很容易实现）
3、易用性和低维护成本

为什么要分配职责

职责的分配能让我们在尝试搞清楚事情如何运作这一过程中保持一个正常的负荷。你可能会认为你投入的精力越多你的大脑越能适应更加复杂的东西，这没错。但是这个能力是非线性的，而且会很快达到临界点。所以降低复杂性的最好的方式是，根据职责单一原则将它的功能（职责）分配到多个实体中。

为什么要可测试性

对于那些已经添加了单元测试的项目来说，当他们增加一个新的功能或者重构一个复杂的类时会由单元测试告知失败与否，这多让人很放心啊。同时这也意味着这些测试项将在运行时帮助开发者找到问题，而如果这些问题发生在用户设备上的，解决他们通常会花费一周。

为什么要易用性

这并不需要答案，但值得一提的是，最好的代码是那些从未写过的代码。所以，代码越少，bug就越少。这意味着，编写更少代码的愿望不应该仅仅由开发人员的懒惰来解释，而且你不应该为了采用更好的解决方案，而对其维护成本视而不见。

MV(X)的要素

如今我们又很多可选的架构方案：

• MVC
• MVP
• MVVM
• VIPER
  前三项方案是把应用程序的实体分为三类：
• Modes – 负责数据域和操作数据的数据访问层，例如’Person’类, ‘PersonDataProvider‘类。
• Views – 负责展示层（GUI），对于iOS环境就是指所有已‘UI’开头的类。
• Controller/Presenter/ViewModel – 是Model和View的中介，通常的职责是通过响应用户在View的操作改变Model，然后根据Model的变化更新View。

这些实体的分割帮助我们：

• 更好的理解他们
• 重用他们（通常是View和Model）
• 单独测试他们

让我们开始讲解MV(X)模式，随后是VIPER

MVC

它原本是什么样的

在讨论苹果的MVC版本之前，让我们看一下传统的MVC模式：

这个模式下，View是无状态的。它只是简单的被Controller渲染当Model变化的时候。想一下Web页面，当你点一个链接尝试跳转时，整个页面都会重新渲染。尽管可以在iOS应用程序中实现传统的MVC，但由于架构问题，这并没有多大意义—— 所有三个实体都是紧密耦合的，每个实体都知道其他两个。这正好降低了他们的重用性，而这又是你在程序中不想看到的。因为这个原因，我们将跳过编写传统MVC代码的示例。

传统的MVC似乎不适合现代的iOS开发

苹果的MVC

预期效果

Controller是View和Model的中介，因此它俩互相不知道对方。可重用性最差的就是Controller，因为我们必须为复杂的业务逻辑提供一个位置，Model又不适合。

理论上，这看起来很简单，但是你总感觉有什么地方不对，是吧？你甚至听到人们解读MVC为Massive View Controller。也因此，视图控制器的简化成了iOS开发一个重要的课题。苹果只是采用传统的MVC并对其进行一些改进，为什么会出现这种情况呢?

现实情况

Cocoa MVC鼓励你编写大量的视图控制器，因为它们是视图生命周期的一部分，很难说它们是独立的。尽管你有能力转移一些业务逻辑和数据转换工作到Model中，当需要转移工作到View时你仍然没有太多选择，因为大多数情况View的职责就是发送行为到Controller。视图控制器最终将成为一个所有东西的委托、数据源、负责调度和取消网络请求，等等。

这种代码，你肯定见过很多少次了：

1
2

var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell
userCell.configureWithUser(user)

这个cell是View，直接通过Model进行配置，这明显违反了MVC的要求，但这种事情却经常发生，而且认为还不认为这是错的。如果你严格按照MVC的 做法，你应该在Controller里面配置cell，而不是将Model直接传递给View，但这样就会增加Controller的大小。

Cocoa MVC 被称为 Massive View Controller是多么合理啊。

这个问题还不是那么明显，直到提到单元测试（希望它存在于你的项目）。因为你的视图控制器跟View是紧耦合的，这将使得测试非常困难。所以你应该让你的业务逻辑和视图布局代码尽可能分割开来。

让我们看一个简单的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import UIKit

struct Person { // Model
    let firstName: String
    let lastName: String
}

class GreetingViewController : UIViewController { // View + Controller
    var person: Person!
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)
    }
    
    func didTapButton(button: UIButton) {
        let greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName
        self.greetingLabel.text = greeting
        
    }
    // layout code goes here
}
// Assembling of MVC
let model = Person(firstName: "David", lastName: "Blaine")
let view = GreetingViewController()

这样根本没法测试，对吧？我们可以把greeting的赋值移到一个新的类GreetingModel中，然后分开测试它。但是我们无法在不直接调用UIView相关方法（viewDidLoad, didTapButton）的情况下测试任何外在的逻辑，而如果这样做，这些方法就导致所有view的刷新，所以这本身就是一个不好的单元测试。

事实上，在一个模拟器上加载和测试UIViews表现正常，不代表它在别的设备依然这样。所以我建议测试时移除单元测试对“宿主程序”的依赖，而直接测试代码。

View和Controller之间的交互行为无法通过Unit Tests进行。

根据上面的说法，Cocoa MVC是一个相当不好的架构方案。让我们再来根据文章开头定义的好架构应有的特性来评价下它：

• 职责分离 – View和Model是分离的，但View和Controller是紧耦合关系。
• 可测试性 – 由于不好的职责分离特性，只有Model层是可以测试的。
• 易用性 – 这几种架构模式中它的代码量是最少的。每个人都很熟悉这种模式，即使是一个经验有限的开发者也可以很容易的维护这份代码。

如果你不打算投入很多事情在架构上，或者你感觉对于你们的小项目来说不值得投入过多维护成本，那你应该选择Cocoa MVC。

Cocoa MVC 是开发速度最快的一种架构。

MVP

这是不是更苹果的MVC非常像？确实是这样的，它的名字叫做MVP。等一下，这是不是意味着苹果的MVC事实上就是MVP？不。你可以再观察下这个结构，View和Controller是紧耦合关系，作为MVP的中介者 – Presenter并没有管理视图控制器的生命周期，它里面也不含有布局代码，它的职责是根据数据的状态变化更新View，所以呢，View这一层就可以很简单的抽出来。

我会告诉你，UIViewController也是View

在MVP模式下，UIViewController的子类实际上是Views而不是Presenters。这种区别提供了极好的可测试性，但这是以开发速度为代价的，因为你必须手动绑定数据和时间，就像这个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

import UIKit

struct Person { // Model
    let firstName: String
    let lastName: String
}

protocol GreetingView: class {
    func setGreeting(greeting: String)
}

protocol GreetingViewPresenter {
    init(view: GreetingView, person: Person)
    func showGreeting()
}

class GreetingPresenter : GreetingViewPresenter {
    unowned let view: GreetingView
    let person: Person
    required init(view: GreetingView, person: Person) {
        self.view = view
        self.person = person
    }
    func showGreeting() {
        let greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName
        self.view.setGreeting(greeting)
    }
}

class GreetingViewController : UIViewController, GreetingView {
    var presenter: GreetingViewPresenter!
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)
    }
    
    func didTapButton(button: UIButton) {
        self.presenter.showGreeting()
    }
    
    func setGreeting(greeting: String) {
        self.greetingLabel.text = greeting
    }
    
    // layout code goes here
}

关于装配（assembly）的重要说明

MVP是第一个揭露三层模型装配问题的模式。我们不想让View和Model互通，因为在试图控制器（View）中执行装配操作是明显不对的，所以我们只能换个地方放装配的代码。例如，我们可以做一个应用范围的Router服务，它负责装配工作和View到View的展示。这个问题的出现不仅要在MVP中解决，在以下的几个模式中也都要解决。

我们看下MVP的特性：

• 职责分离 – 我们将大部分职责分配给了Presenter和Model，而视图则什么都不需要做（上面的Model也是什么都不用做）
• 可测试性 – 非常好，我们可以通过静态的View测试大多数逻辑。
• 易用性 – 在我们上个简单示例中，代码量是MVC的两倍，但是它的逻辑是很清晰的。

在iOS中MVP模式意味着良好的可测试性和大量代码。

MVP

这是另一个MVP的样式 – 由视同控制器担当管理的MVP。这个变体中，View和Model是直接绑定的，Presenter(担当管理的控制器)仍然处理着来自View的操作，并且能够改变View。

但是通过上面的学习我们已经知道了，将View和Model紧耦合处理，这种不明确的职责分离是很糟糕的。这与Cocoa桌面开发中的工作原理类似。

跟传统MVC一样，我找不到要为这个有缺陷的架构写示例的理由。

MVVM

最新而且是最好的一个MV(X)类型

MVVM是最新的MV(X)类型，希望它能解决我们之前讨论过的问题。

MVVM理论上看起来是很好的，View和Model我们已经很熟悉了，它俩之间的中介者由View Model表示。

这和MVP很像：

• MVVM也是把视图控制器当做View
• 在View和Model之间没有紧耦合关系

此外它的绑定逻辑很像MVP的监管版本；但是这次不是View和Model，而是View和View Model之间的绑定。

所以iOS当中的View Model到底是什么呢？它是UIKit独立于视图及其状态的表示。View Model调用Model执行更改，然后根据Model的更新再更新自己，因为我们绑定了View和View Model，第一个模型将相应的更新。

绑定

我在MVP部分明确提到过绑定，这次让我们再来讨论一下。绑定出自于MacOS开发，在iOS中是没有的。我们虽然可以通过KVO和通知完成这一过程，但是这样的绑定方式并不方便。

如果我们不想自己实现的话，有两个选项可供参考：

• 一个是基于KVO的绑定库像RZDataBinding,SwiftBond
• 完整的函数式编程工具，像ReactiveCocoa, RxSwift, PromiseKit。

如今当你听到“MVVM”，就应该想到ReactiveCocoa。因为它可以让你用很简单的绑定方式构建MVVM，几乎涵盖所有MVVM中的逻辑。

但是使用响应式框架会面临一个不好的现实：能力越大责任越大。使用reactive很容易将事情复杂化。也就是说，如果发生了一处错误，你需要花费很多时间去调试问题，可以简单看下响应式的调用堆栈。

在我们的示例中，响应式框架甚至KVO都是多余的，我们将使用showGreeting方法显式地要求View Model更新，并使用greetingDidChange回调函数的简单属性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

import UIKit

struct Person { // Model
    let firstName: String
    let lastName: String
}

protocol GreetingViewModelProtocol: class {
    var greeting: String? { get }
    var greetingDidChange: ((GreetingViewModelProtocol) -> ())? { get set } // function to call when greeting did change
    init(person: Person)
    func showGreeting()
}

class GreetingViewModel : GreetingViewModelProtocol {
    let person: Person
    var greeting: String? {
        didSet {
            self.greetingDidChange?(self)
        }
    }
    var greetingDidChange: ((GreetingViewModelProtocol) -> ())?
    required init(person: Person) {
        self.person = person
    }
    func showGreeting() {
        self.greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName
    }
}

class GreetingViewController : UIViewController {
    var viewModel: GreetingViewModelProtocol! {
        didSet {
            self.viewModel.greetingDidChange = { [unowned self] viewModel in
                self.greetingLabel.text = viewModel.greeting
            }
        }
    }
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self.viewModel, action: "showGreeting", forControlEvents: .TouchUpInside)
    }
    // layout code goes here
}
// Assembling of MVVM

再次回来用这三个特征验证一下：

• 职责分离 – 这在我们的小示例还无法体现，但是MVVM的View比着MVP的View有着更多的职责。因为前者通过View Model建立绑定更新它的状态，后者仅仅是把所有事件都交给Presenter，不更新自己。
• 可测试性 – View Model是不知道View的，这可以让我们很容易的对它进行测试。View可能也需要测试，但因为它依赖UIKit，你可能想跳过它。
• 易用性 – 它有河MVP模式相同的代码量，但是实际项目中，你不得不把所有事件通过View传给Presenter，然后还要手动更新View，比较而言，MVVM使用绑定将更加简洁。

MVVM是很有吸引力的，因为它包含了前面提到的优点，此外通过View层的绑定，也不需要额外的代码处理View更新。测试性也还不错。

VIPER

把乐高的搭建流程应用到iOS设计模式

VIPER是我们最后一个候选模式，有趣的一点是它不属于MV(X)类型。

目前为止，你必须同意职责的粒度是很重要的。VIPER在划分职责层面又做了一次迭代，它将项目划分成5层。

• Interactor– 包含跟数据（Entities）和网络相关的业务逻辑，像是创建新的实例对象后者从服务器拉取数据。出于这些目的，你也可以使用Services和Mananger类完成功能，但这就不属于VIPER模块，而是外部依赖类。
• Presenter – 包含UI相关的业务逻辑，调用Interactor中的方法。
• Entities – 普通的数据对象，不是数据访问层，因为这是Interactor的责任。
• Router – 负责VIPER模块之间的切换。

基本上，VIPER模块可以是一整屏内容，也可以是你应用中完整的用户行为 – 想一下授权行为，它可以在一个或者几个相关联的界面。“乐高”方块应该多小呢？这取决于你。

如果我们将它和MV(X)类比，会发现一些在职责划分上的区别：

• Model(数据交互)逻辑转移到了包含Entities数据结构的Interactor中。
• 只有Controller/Presenter/ViewModel这种UI表示层的职责转移到了Presenter中，不包含数据。
• VIPER是第一个明确导航职责的模式，并通过Router解决这个问题。

在iOS应用中用一个优雅的方式处理跳转问题确实是一个挑战，MV(X)模式没有处理这个问题。

该示例不涉及模块之间的路由或交互，因为MV(X)模式根本不涉及这些主题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

import UIKit

struct Person { // Entity (usually more complex e.g. NSManagedObject)
    let firstName: String
    let lastName: String
}

struct GreetingData { // Transport data structure (not Entity)
    let greeting: String
    let subject: String
}

protocol GreetingProvider {
    func provideGreetingData()
}

protocol GreetingOutput: class {
    func receiveGreetingData(greetingData: GreetingData)
}

class GreetingInteractor : GreetingProvider {
    weak var output: GreetingOutput!
    
    func provideGreetingData() {
        let person = Person(firstName: "David", lastName: "Blaine") // usually comes from data access layer
        let subject = person.firstName + " " + person.lastName
        let greeting = GreetingData(greeting: "Hello", subject: subject)
        self.output.receiveGreetingData(greeting)
    }
}

protocol GreetingViewEventHandler {
    func didTapShowGreetingButton()
}

protocol GreetingView: class {
    func setGreeting(greeting: String)
}

class GreetingPresenter : GreetingOutput, GreetingViewEventHandler {
    weak var view: GreetingView!
    var greetingProvider: GreetingProvider!
    
    func didTapShowGreetingButton() {
        self.greetingProvider.provideGreetingData()
    }
    
    func receiveGreetingData(greetingData: GreetingData) {
        let greeting = greetingData.greeting + " " + greetingData.subject
        self.view.setGreeting(greeting)
    }
}

class GreetingViewController : UIViewController, GreetingView {
    var eventHandler: GreetingViewEventHandler!
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)
    }
    
    func didTapButton(button: UIButton) {
        self.eventHandler.didTapShowGreetingButton()
    }
    
    func setGreeting(greeting: String) {
        self.greetingLabel.text = greeting
    }
    
    // layout code goes here
}

// Assembling of VIPER module, without Router
let view = GreetingViewController()
let presenter = GreetingPresenter()
let interactor = GreetingInteractor()
view.eventHandler = presenter
presenter.view = view
presenter.greetingProvider = interactor

让我们再一次对比那几个特征：

• 职责分离 – 毫无疑问，VIPER是职责分离做的最好的。
• 可测试性 – 职责分离越好，可测试性当然也会更好
• 易用性 – 你可能已经猜到了，上面两项意味着维护成本的提升。你必须写很多处理各个类之间交互的代码。

所有这个乐高模式到底怎么样呢？

当使用VIPER时，如果你感觉就像是通过乐高方块搭建帝国大厦，这就意味着出现了问题。不应该过早在你的应用中使用VIPER，你需要考虑简便性。有些人不注意简便性，直接使用VIPER，会有点大材小用。我猜测很多人是这么想的，他们的应用迟早都会发展到适用VIPER的复杂程度，所以早晚都会做的事，即使现在维护成本高也应该继续做下去。如果你就是这么想的，我推荐你试一下Generamba – 一个生成VIPER组件的工具。虽然对我个人来说，这感觉就像使用自动瞄准系统而不是简单的弹射。

总结

我们已经讲解了几个架构模式，希望你能解答曾经困扰你的问题。我敢肯定你也意识到了架构模式的选择没有最好这一说，它取决于你在特定环境下权衡利弊之后做的选择。

所以，在一个应用中出现混合一种混合的架构模式也是很常见的。例如，你一开始使用MVC，然后你发现有一个界面的逻辑变得很复杂，然后你转向了MVVM，但也是仅限于这个界面。你不必重构别的使用MVC的界面，因为它原本就是工作的好好的，而且这两个架构模式是很容易兼容的。

事情应该力求简单，不过不能过于简单 – 阿尔伯特·爱因斯坦

好消息

开始水滴筹之后，父亲治病的消息大家就都知道了，期间收到了很多来自亲友的支持和帮助。先告诉大家好消息，父亲手术完了，并且身体恢复一切正常，已于11月8号中午从重症监护室转到无菌病房，还需要在里面待够五天才转到普通病房。关于看病所需要的筹款，也得到了解决。今天晚上7点左右，我已经终止了这次筹款。

看病资金问题能快速解决，除了来自水滴筹的筹款，还有就是公司的大力支持。三位老板帮助了2万元，还破格提前给我发了年终奖，算上水滴筹中的63588元，一直到出院应该是没什么问题了。

很多朋友因为我的原因关注并参与到水滴筹中，有些小伙伴因为担心水滴筹有手续费用就直接把钱打给我。为了打消大家的顾虑，我花了些时间理解水滴筹背后的一些事情。

看了父亲的病历，再结合之前了解的一些情况，我试着分析一下为什么会得尿毒症。

一些医学知识

关于肾脏：

肾脏有很重要的代谢排毒功能，可以清除体内经由食物消化所残留的尿素、尿素氮、肌酸酐等，也会排出水分，维持体内的电解质平衡，甚至是控制血压高低起伏、活化维生素 D 的重要器官。此外，肾脏与肝脏一样，也是体内清除药物的重要器官，这也是为何肾功能不好时，就容易发生药物过量或中毒后遗症的原因。可见肾脏是何等的重要！等到肾脏的功能持续恶化到只剩下不到正常的 10% 时，才较容易出现包括恶心、水肿、高血压、倦怠无力、抽筋等症状，一旦造成更严重的尿毒症时，只能透析治疗。

手术完成就是渡过了最大的难关，其他时间爸爸都是在重症监护室由专门护工照顾的。实际也不需要那么多人手，先后送走了三姨姨父，弟弟，还有两位叔叔，就我自己留在医院。平常需要买什么吃的，里面护士直接给我打电话，我买好送过来。

订饭

五点半起床。医生嘱咐手术完第二天需要喝米油（小米粥虑掉小米），还有喝萝卜水。一般来说术后6小时宜服用一些排气类食物，如萝卜汤，帮助因麻醉而停止蠕动的胃肠道保持运作，以肠道排气作为可以进食的标志。

抵达郑州

二号中午我爸打电话来医院这边配型成功，让三号早上来做手术。我得知这个消息有些开心也有些担忧，开心是因为盼了八个多月的肾源终于有了消息，担忧是紧接着将是一场大手术，不管医院怎么保证手术成功率，肾移植手术本身都是一项大手术。

我和弟弟是二号晚上9点半的火车，因为当天才进行买票，只有硬座了，三号早上5点45到的郑州。爸爸于前一天晚上在三姨和姨父的陪同下到的医院。见到爸爸，看他精神状态挺不错，我安心不少。他说需要做的检查都已经做了，身体条件一切正常，就等医生上班安排手术时间了。

工具篇

效率神器Alfred

可以从Alfred官网下载，免费版没有workflow功能，付费购买Powerpack可以使用。建议大家购买正版，如果想找破解版，网上也有很多，自行搜索。

这有一篇比较详细的Alfred的使用教程，大部分都被涵盖进去了。这里主要介绍几种对开发帮助比较大的workflow插件，官方workflows地址在这里，可以根据需要选择自己喜欢的插件使用。