2015 Objective-C 三大新特性
原文地址：http://www.cocoachina.com/ios/20150617/12148.html
Overview
自 WWDC 2015 推出和开源 Swift 2.0 后，大家对 Swift 的热情又一次高涨起来，在羡慕创业公司的朋友们大谈 Swift 新特性的同时，也有很多像我一样工作上依然需要坚守着 Objective-C 语言的开发者们。今年的 WWDC 中介绍了几个 Objective-C 语言的新特性，还是在“与 Swift 协同工作”这种 Topic 里讲的，越发凸显这门语言的边缘化了，不过有新特性还是极好的，接下来，本文将介绍下面三个主要的新特性：
-
Nullability
-
Lightweight Generics *
-
__kindof
说明：在Xcode7中，iOS9的SDK已经全面兼容了Objective-C的一些新特性和新功能。这些功能都只作用于编译期，对程序的运行并没有影响，因此，它可以很好的向下进行兼容，无缝的衔接低版本的iOS系统。
Nullability
在swift语言中，通过!和?可以将对象声明成Optional，用于在开发中标记这个对象是否可以为空。在OC中，以前是没有这样的功能的，因此我们在开发中会经常遇到因为某个函数应该返回实例而返回了空导致的崩溃。Nullability的主要用武之地，就是在这里，它可以起到提示开发者做是否为空得判断的提示。
打开Xcode7，系统的框架中已经支持了Nullability，如下：
|
1
2
3
|
@property (nonatomic, strong, nonnull) Sark *sark;
@property (nonatomic, copy, readonly, nullable) NSArray *friends;
+ (nullable NSString *)friendWithName:(nonnull NSString *)name;
|
这是NSArray中的两个属性，其中nullable关键字说明了这里可以返回nil。
Nullability不仅仅可以修饰属性，在返回值中给开发者一些提示，而且可以用于函数的参数中，这样我们在调用函数时起到的提示作用，将是非常重要的，越是多人合作的项目，作用也越大。
例如：
-(void)setValue:(NSNumber * _Nonnull )number{
}
我们在调用函数时，如果传入了空值，编译器会给我们警告：
Nullability还可以用来修饰一个变量，前面还要加双下划线，例如在 block 里面使用：
|
1
|
- (void)startWithCompletionBlock:(nullable void (^)(NSError * __nullable error))block;
|
此外，还有一个修饰符：null_resettable:set方法可以为nil，get方法不可返回nil，最直观例子就是 UIViewController 中的 view 属性：
|
1
|
@property (null_resettable, nonatomic, strong) UIView *view;
|
它可以被设成 nil，但是调用 getter 时会触发 -loadView 从而创建并返回一个非 nil 的 view。
从 iOS9 SDK 中可以发现，头文件中所有 API 都已经增加了 Nullability 相关修饰符，想了解这个特性的用法，翻几个系统头文件就差不离了。接口中 nullable 的是少数，所以为了防止写一大堆 nonnull，Foundation 还提供了一对儿宏，包在里面的对象默认加 nonnull 修饰符，只需要把 nullable 的指出来就行，黑话叫 Audited Regions：
|
1
2
3
4
5
6
7
|
NS_ASSUME_NONNULL_BEGIN
@interface Sark : NSObject
@property (nonatomic, copy, nullable) NSString *workingCompany;
@property (nonatomic, copy) NSArray *friends;
- (nullable NSString *)gayFriend;
@end
NS_ASSUME_NONNULL_END
|
Nullability 在编译器层面提供了空值的类型检查，在类型不符时给出 warning，方便开发者第一时间发现潜在问题。不过我想更大的意义在于能够更加清楚的描述接口，是主调者和被调者间的一个协议，比多少句文档描述都来得清晰，打个比方：
|
1
|
+ (nullable instancetype)URLWithString:(NSString *)URLString;
|
NSURL 的这个 API 前面加了 nullable 后，更加显式的指出了这个接口可能因为 URLString 的格式错误而创建失败，使用时自然而然的就考虑到了判空处理。
不仅是属性和方法中的对象，对于局部的对象、甚至 c 指针都可以用带双下划线的修饰符，可以理解成能用 const 关键字的地方都能用 Nullability。
所以 Nullability 总的来说就是，写着丑B，用着舒服 - -
Lightweight Generics
带泛型的容器
这无疑是本次最重大的改进，有了泛型后终于可以指定容器类中对象的类型了，如下：
|
1
|
NSMutableArray<NSString *> *array = [[NSMutableArray alloc]init];
|
声明了这样一个数组后，就好比我告诉了编译器，这个数组中的数据类型都是NSString*类型的，如果想用这个数组中元素的方法，会出现如下的提示：
在我们向这个数组中追加元素的时候，编译器将元素的类型提示了出来，并且将FromArray方法中需要的元素类型也提示了出来：
同样，如果我们向这个数组中追加类型不匹配的元素，如下：
|
1
2
|
NSMutableArray<NSString *> *array = [[NSMutableArray alloc]init];
[array addObject:@1];
|
编译器会给我们一个这样的警告：
自定义泛型类
观察Xcode7中系统的类，会发现ObjectType这个单词，它是一个类型通配符，具体怎么写并不重要，也可以写成xxx，只是系统中都约定使用了ObjectType，你也可以在自己的类中按自己的喜好来命名。ObjectType是传入类型的 placeholder，它只能在 @interface 上定义（类声明、类扩展、Category），如果你喜欢用 T 表示也 ok，这个类型在 @interface 和 @end 区间的作用域有效，可以把它作为入参、出参、甚至内部 NSArray 属性的泛型类型，应该说一切都是符合预期的。：
创建一个类，继承于NSObject，我取名叫MyArray：
|
1
2
3
4
5
6
|
//这个类型通配符只能在interfave里使用，作用域为@interface到@end之间
//这里我使用Type来做这个通配符
@interface MyArray<Type> : NSObject
@property(nonatomic,strong,nonnull)NSMutableArray<Type> *array;
-(
void
)addObject:(nonnull Type)obj;
@end
|
实现如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
- (instancetype)init
{
self = [super init];
if
(self) {
_array = [[NSMutableArray alloc]init];
}
return
self;
}
-(
void
)addObject:(id)obj{
[_array addObject:obj];
}
-(NSString *)description{
NSMutableString * str = [[NSMutableString alloc]init];
for
(
int
i=0; i<_array.count; i++) {
[str appendString:[NSString stringWithFormat:@
"%@\n"
,_array[i]]];
}
return
str;
}
|
我们在使用这个自定义的集合类型时，就会有和系统集合类有一样的效果了，即我们成功的自定义了一个泛型类：
多参数的泛型集合
多参数的泛型集合，有一个非常好的例子，就是NSDictionary，在Xcode7中我们可以这样写字典：
可以看到，字典键值的类型编译器为我们提示了出来，结合上面类型通配符的使用，对于多参的集合，将参数类型用“,”隔开即可。
协变性和逆变性
当类支持泛型后，其中两种类型做类型转化时，编译器需要知道哪些转化是允许的，哪些是禁止的，比如，默认情况下：
我们可以看到，不指定泛型类型的 Stack 可以和任意泛型类型转化，但指定了泛型类型后，两个不同类型间是不可以强转的，假如你希望主动控制转化关系，就需要使用泛型的协变性和逆变性修饰符了：
__covariant - 协变性，子类型可以强转到父类型（里氏替换原则）
__contravariant - 逆变性，父类型可以强转到子类型（WTF?）
协变：
|
1
|
interface Stack<__covariant Type> : NSObject |
效果：
逆变：
|
1
|
@interface Stack : NSObject
|
效果：
协变是非常好理解的，像 NSArray 的泛型就用了协变的修饰符，而逆变我还没有想到有什么实际的使用场景。
__kindof
__kindof 这修饰符还是很实用的，解决了一个长期以来的小痛点，拿原来的 UITableView 的这个方法来说：
|
1
|
- (id)dequeueReusableCellWithIdentifier:(NSString *)identifier;
|
使用时前面基本会使用 UITableViewCell 子类型的指针来接收返回值，所以这个 API 为了让开发者不必每次都蛋疼的写显式强转，把返回值定义成了 id 类型，而这个 API 实际上的意思是返回一个 UITableViewCell 或 UITableViewCell 子类的实例，于是新的 __kindof 关键字解决了这个问题：
|
1
|
- (__kindof id)dequeueReusableCellWithIdentifier:(NSString *)identifier;
|
既明确表明了返回值，又让使用者不必写强转。再举个带泛型的例子，UIView 的 subviews 属性被修改成了：
|
1
|
@property (nonatomic, readonly, copy) NSArray<__kindof UIView *> *subviews;
|
这样，写下面的代码时就没有任何警告了：
|
1
|
UIButton *button = view.subviews.lastObject;
|
Where to go
有了上面介绍的这些新特性以及如 instancetype 这样的历史更新，Objective-C 这门古老语言的类型检测和类型推断终于有所长进，现在不论是接口还是代码中的 id 类型都越来越少，更多潜在的类型错误可以被编译器的静态检查发现。
同时，个人感觉新版的 Xcode 对继承链构造器的检测也加强了，NS_DESIGNATED_INITIALIZER 这个宏并不是新面孔，可以使用它标志出像 Swift 一样的指定构造器和便捷构造器。
最后，附上一段用上了所有新特性的代码，Swift 是发展趋势，如果你暂时依然要写 Objective-C 代码，把所有新特性都用上，或许能让你到新语言的迁移更无痛一点。
References
-
https://msdn.microsoft.com/zh-cn/library/dd799517.aspx
-
https://gist.github.com/jtbandes/881f07a955ff2eadd1a0