category 是 OC 2.0后添加的新特性，主要作用是给已经存在的类添加方法，当然秉着类的单一职责原则和接口隔离原则我们通常会将不同功能的类扩展分别写在不同的文件中，这样不仅减少了单个文件的体积，同时可以对 category 进行按需加载。

category 的定义

所有的 OC 类和对象在 runtime 层其实都是 strcut，比如 objc_class、objc_object， 甚至 block(__block_impl) 还定义有自己的 isa 指针，category 也是如此。

1
2
3
4
5
6
7
8

typedef struct category_t {
    const char *name;
    classref_t cls;
    struct method_list_t *instanceMethods;
    struct method_list_t *classMethods;
    struct protocol_list_t *protocols;
    struct property_list_t *instanceProperties;
} category_t;

这段时间可能所有的开发 iOS 的公司都在做应用的 HTTPS 适配，因为在 WWDC 16 中，Apple 表示从 2017 年 1 月 1 日起，所有的新提交 app 默认是不允许使用 NSAllowsArbitraryLoads 来绕过 ATS 限制的，也就是说，我们最好保证 app 的所有网络请求都是 HTTPS 加密的，否则可能会在应用审核时遇到麻烦。

由于 Apple 在这之前预留了足够的时间让我们来进行网络适配，所以在这之前我们大部分情况下将 NSAllowsArbitraryLoads 设置为 YES，这样网络请求不受 ATS 的限制了。

关于 TCP 流与包的概念

首先需要明确一个概念，TCP 是以二进制流式传送数据的，既发送端与接收端成功建立连接下即可以不停的发送数据包，不同数据包间并没有明确的边界定义；而 UDP 发送数据的时候是按照一个一个的数据包去发送的。所以 TCP 发送数据是一个二进制流，而管道内的数据是一个个封装好的数据包。另外很重要的一点是，无论是发送端发送数据，还是接收端接收数据，都存在一个数据的缓冲区，而当发送端等待缓冲区满才发送数据，就会造成缓冲区有多个数据包，数据包可能会在开启 Nagle 算法的情况下进行合并发送；而接收端不及时处理缓冲区的数据包时，既同样造成缓冲区存在多个数据包，应用层可能会一次 read 完多个数据包。所以在发送端，我们需要对数据按照事先约定好的协议进行合理的封装，在接收端，我们需要按照协议对数据进行拆分。

难得好好休息的小两个月，先与基友们相聚大连，紧接着一家人自驾跑了一趟九寨沟和四川，后独自深港行，转机跟首席去了西东马，最后去了潜水圣地 Sipadan ，圆满！

大连

对于一个开发者来说, MVC 设计模式被广泛应用于各种语言的开发中，这在 iOS 开发中体现的尤为多，比如我们的控制器 Controller，视图 View，模型 Model，从名称中就可以体现出各自的作用及分工，Apple 也是推荐我们使用 MVC 模式进行程序设计及开发。其实绝大部分时候 MVC 模式基本是可以满足我们的业务需求的，可是随着业务的膨胀，开发人员变动等因素，MVC 模式也暴露了其弊端，当控制器层变得越来越臃肿的时候，业务过于集中到控制器层，就会为为接下来的开发带来不便及代码的可维护性变低。

所以这时候为了解决刚才的问题，MVVM 模式就“应孕而生”了，它不仅仅可以对原有 MVC 模式进行代码上的优化瘦身，更重要的一点是兼容 MVC 模式，我们可以对原有项目必要的地方进行 MVVM 模式的升级。

整理了开发中一些特定场景下使用 RAC 的便利之处，关于一些常用的 API 的使用网上的资源还是很多的，就不做举例了。

• 比如登录页面当用户输入的账号、密码长度合法的情况下才可以点击登录按钮，否则按钮不可点击，这里条件比较简单，即账号密码长度都大于5，其实还可以使用一些正则匹配账号格式是否正确等。combineLatest 就是合并多个信号，且每个信号至少发送过一次 sendNext，才会触发合并信号。

1
2
3

RAC(self.loginBT, enabled) = [RACSignal combineLatest:@[self.accountTF.rac_textSignal, self.passWordTF.rac_textSignal] reduce:^(NSString *usernameValid, NSString *passwordValid) {
        return @(usernameValid.length > 5 && passwordValid.length > 5);
}];

ReactiveCocoa 是一个 iOS 中的函数式响应式编程框架，现在已经发展到了 v4.x，开始支持 Swift 了。如果我们的项目还是 Objective-C 开发的话建议使用 v2.5，也是一个很稳定的版本。当然每当我们学习一个新的框架前，除了了解简单的 api 接口使用外，另外很重要的一点就是要思考作者所表现的编程思想。

首先 ReactiveCocoa 是一个响应式编程范式，既 FRP(Functional Reactive Programming)，简单讲在程序开发中：a ＝ b ＋ c，传统的命令式编程中赋值之后 b 或者 c 的值变化后，a 的值不会跟着变化，而在响应式编程中，a 的值会随着 b 或者 c 的值变化而变化。

另一方面 ReactiveCocoa 作者大量了使用了链式编程和函数式编程，使用过 Masonry 框架的应该都会有所体会，这样会使代码的可读性大大增强，代码更紧凑。

PhotoKit 中相关类介绍

• PHAsset：代表一个照片库中的一个资源，如一个照片/一个视频
• PHFetchResult：PHAsset 的集合，对应照片应用中的一个相册
• PHFetchOptions：可以通过配置对资源进行排序，如时间
• PHImageManager：用于从 PHFetchResult 中获取 PHAsset，可以设置相关参数，获取视频/图片/或者将一个PHAsset转化为NSData
• PHImageRequestOptions：获取 PHAsset 资源时的相关设置，获取资源的方式(同步/异步)，资源的质量等。