2015 Objective-C 三大新特性

Overview

自 WWDC 2015 推出和开源 Swift 2.0 后，你们对 Swift 的热情又一次高涨起来，在羡慕创业公司的朋友们大谈 Swift 新特性的同时，也有不少像我同样工做上依然须要坚守着 Objective-C 语言的开发者们。今年的 WWDC 中介绍了几个 Objective-C 语言的新特性，仍是在“与 Swift 协同工做”这种 Topic 里讲的，愈加凸显这门语言的边缘化了，不过有新特性仍是极好的，接下来，本文将介绍下面三个主要的新特性：

• Nullability

• Lightweight Generics *

• __kindof

Nullability

然而 Nullability 并不算新特性了，从上一个版本的 llvm 6.1 (Xcode 6.3) 就已经支持。这个简版的 Optional ，没有 Swift 中 ? 和 ! 语法糖的支持，在 Objective-C 中就显得很是啰嗦了：

假如用来修饰一个变量，前面还要加双下划线，放到 block 里面就更加诡异，好比一个 Request 的 start 方法能够写成：

除了这俩外，还有个 null_resettable 来表示 setter nullable，可是 getter nonnull，绕死了，最直观例子就是 UIViewController 中的 view 属性：

它能够被设成 nil，可是调用 getter 时会触发 -loadView 从而建立并返回一个非 nil 的 view。

从 iOS9 SDK 中能够发现，头文件中全部 API 都已经增长了 Nullability 相关修饰符，想了解这个特性的用法，翻几个系统头文件就差不离了。接口中 nullable 的是少数，因此为了防止写一大堆 nonnull，Foundation 还提供了一对儿宏，包在里面的对象默认加 nonnull 修饰符，只须要把 nullable 的指出来就行，黑话叫 Audited Regions：

Nullability 在编译器层面提供了空值的类型检查，在类型不符时给出 warning，方便开发者第一时间发现潜在问题。不过我想更大的意义在于可以更加清楚的描述接口，是主调者和被调者间的一个协议，比多少句文档描述都来得清晰，打个比方：

NSURL 的这个 API 前面加了 nullable 后，更加显式的指出了这个接口可能由于 URLString 的格式错误而建立失败，使用时天然而然的就考虑到了判空处理。

不只是属性和方法中的对象，对于局部的对象、甚至 c 指针均可以用带双下划线的修饰符，能够理解成能用 const 关键字的地方都能用 Nullability。

因此 Nullability 总的来讲就是，写着丑B，用着舒服 - -

 

 

Lightweight Generics

Lightweight Generics 轻量级泛型，轻量是由于这是个纯编译器的语法支持（llvm 7.0），和 Nullability 同样，没有借助任何 objc runtime 的升级，也就是说，这个新语法在 Xcode 7 上可使用且彻底向下兼容（更低的 iOS 版本）

带泛型的容器

这无疑是本次最重大的改进，有了泛型后终于能够指定容器类中对象的类型了：

返回值的 id 被替换成具体的类型后，使人感动的代码提示也出来了：

假如向泛型容器中加入错误的对象，编译器会不开心的：

系统中经常使用的一系列容器类型都增长了泛型支持，甚至连 NSEnumerator 都支持了，这是很是 Nice 的改进。和 Nullability 同样，我认为最大的意义仍是丰富了接口描述信息，对比下面两种写法：

不用多想就清楚下面的数组中存的是什么，避免了 NSString 和 NSURL 的混乱。

自定义泛型类

比起使用系统的泛型容器，更好玩的是自定义一个泛型类，目前这里还没什么文档，但拦不住咱们写测试代码，假设咱们要自定义一个 Stack 容器类：

这个 ObjectType 是传入类型的 placeholder，它只能在 @interface 上定义（类声明、类扩展、Category），若是你喜欢用 T 表示也 ok，这个类型在 @interface 和 @end 区间的做用域有效，能够把它做为入参、出参、甚至内部 NSArray 属性的泛型类型，应该说一切都是符合预期的。咱们还能够给 ObjectType 增长类型限制，好比：

若什么都不加，表示接受任意类型 ( id )；当类型不知足时编译器将产生 error。

实例化一个 Stack，一切工做正常：

对于多参数的泛型，用逗号隔开，其余都同样，能够参考 NSDictionary 的头文件。

协变性和逆变性

当类支持泛型后，它们的 Type 发生了变化，好比下面三个对象看上去都是 Stack，但实际上属于三个 Type：

当其中两种类型作类型转化时，编译器须要知道哪些转化是容许的，哪些是禁止的，好比，默认状况下：

咱们能够看到，不指定泛型类型的 Stack 能够和任意泛型类型转化，但指定了泛型类型后，两个不一样类型间是不能够强转的，假如你但愿主动控制转化关系，就须要使用泛型的协变性和逆变性修饰符了：

__covariant - 协变性，子类型能够强转到父类型（里氏替换原则）

__contravariant - 逆变性，父类型能够强转到子类型（WTF?）

协变：

效果：

逆变：

效果：

协变是很是好理解的，像 NSArray 的泛型就用了协变的修饰符，而逆变我尚未想到有什么实际的使用场景。

__kindof

__kindof 这修饰符仍是很实用的，解决了一个长期以来的小痛点，拿原来的 UITableView 的这个方法来讲：

使用时前面基本会使用 UITableViewCell 子类型的指针来接收返回值，因此这个 API 为了让开发者没必要每次都蛋疼的写显式强转，把返回值定义成了 id 类型，而这个 API 实际上的意思是返回一个 UITableViewCell 或 UITableViewCell 子类的实例，因而新的 __kindof 关键字解决了这个问题：

既明确代表了返回值，又让使用者没必要写强转。再举个带泛型的例子，UIView 的 subviews 属性被修改为了：

这样，写下面的代码时就没有任何警告了：

 

 

 

Where to go

有了上面介绍的这些新特性以及如 instancetype 这样的历史更新，Objective-C 这门古老语言的类型检测和类型推断终于有所长进，如今不管是接口仍是代码中的 id 类型都愈来愈少，更多潜在的类型错误能够被编译器的静态检查发现。

同时，我的感受新版的 Xcode 对继承链构造器的检测也增强了，NS_DESIGNATED_INITIALIZER 这个宏并非新面孔，可使用它标志出像 Swift 同样的指定构造器和便捷构造器。

最后，附上一段用上了全部新特性的代码，Swift 是发展趋势，若是你暂时依然要写 Objective-C 代码，把全部新特性都用上，或许能让你到新语言的迁移更无痛一点。