Objective—C语言的新魅力
一、引言
在Xcode7中，iOS9的SDK已经全面兼容了Objective-C的一些新特性和新功能。这些功能都只作用于编译期，对程序的运行并没有影响，因此，它可以很好的向下进行兼容，无缝的衔接低版本的iOS系统，那么这些特性有什么样的用处呢，作为开发者，我保证你一定会爱上他们，如果你可以将这些新特性都应用于你的开发，你的开发效率和代码质量，相比之前，会有一个很大的提升。
二、Nullability检测的支持
在swift语言中，通过!和?可以将对象声明成Optional，用于在开发中标记这个对象是否可以为空。在OC中，以前是没有这样的功能的，因此我们在开发中会经常遇到因为某个函数应该返回实例而返回了空导致的崩溃。Nullability的主要用武之地，就是在这里，它可以起到提示开发者做是否为空得判断的提示。
打开Xcode7，系统的框架中已经支持了Nullability，如下：
@property (nullable, nonatomic, readonly) ObjectType firstObject;
@property (nullable, nonatomic, readonly) ObjectType lastObject;
这是NSArray中的两个属性，其中nullable关键字说明了这里可能返回空的值。
如果仅仅是在返回值中给开发者一些提示，你可能觉得应用并不大，是的，对开发者最大的帮助是这一特性可以用于函数的参数中，这样我们在调用函数时起到的提示作用，将是非常重要的，越是多人合作的项目，作用也越大。
例如：
-(void)setValue:(NSNumber * _Nonnull )number{
}
我们在调用函数时，如果传入了空值，编译器会给我们警告：
注意：
这一特性在Xcode6.3中就已经支持，但在Xcode7中又做了一些写法上的小改动，例如，在Xcode6.3中这样写：
-(void)setValue:( nonnull NSNumber * )number{
}
而在Xcode7中提倡我们使用第一种写法。
与之相关的几个关键字如下：
修饰参数
nonnull：不可为空
nullable: 可以为空
null_unspecified:不确定是否可以为空(极少情况)
在属性的声明中，还会有如下一个修饰符：
null_resettable:set方法可以为nil，get方法不可返回nil
一点提示：
你可以发现，iOS9的SDK中已经完全兼容使用了这些特性，并且nonnull的使用会比nullable广泛的多，因此，系统提供了这样一对宏：
#define NS_ASSUME_NONNULL_BEGIN _Pragma("clang assume_nonnull begin")
#define NS_ASSUME_NONNULL_END _Pragma("clang assume_nonnull end")
我们在这对宏之间定义的变量都会加上nonnull的修饰符，只有我们特殊声明nullable的才需要手动写。
三、泛型集合的支持
这一特性和Nullability一样，只作用于编译期，是为我们开发者服务的另一重要特性。还记得，在Xcode7之前，依然是为了方便多人开发，我经常会在框架中写这样的一个空得宏：
在开发时如下使用，做到提示伙伴我这个数组中是什么东西的作用：
@interface ViewController ()
{
NSArray __TYPE__FIT_TO__CLASS(NSString) * array;
}
@end
当然，所有这些都是我自己的自导自演，编译器并不会鸟我，我在这个数组中加其他的东西，它也不会介意，所有这些只是我和我的伙伴们约定的一种一厢情愿。所以，当我看到Xcode7中的集合类型时，我着实兴奋了一下。
1、有类型约定的集合
在Xcode7中，我们可以给集合类型添加一个泛型的约定，如下：
NSMutableArray<NSString *> *array = [[NSMutableArray alloc]init];
声明了这样一个数组后，就好比我告诉了编译器，这个数组中的数据类型都是NSString*类型的，现在非常好，如果我这个数组中元素的方法，会出现如下的提示：
激动吧，使用点语法可以访问到数组中泛型的方法了，还有更加诱人的：
在我们向这个数组中追加元素的时候，编译器将元素的类型提示了出来，并且将FromArray方法中需要的元素类型也提示了出来。
同样，如果我们向这个数组中追加类型不匹配的元素，如下：
NSMutableArray<NSString *> *array = [[NSMutableArray alloc]init];
[array addObject:@1];
编译器会给我们一个这样的警告：
