nullability annotations
在Swift中可以使用!和?来表示一个对象是optional的还是non-optional，如button?和button!。而在Objective-C中则没有这一区分，button即可表示这个对象是optional，也可表示是non-optioanl。这样就会造成一个问题：在Swift与Objective-C混编时，Swift编译器并不知道一个Objective-C对象到底是optional还是non-optional，因此这种情况下编译器会隐式地将Objective-C的对象当成是non-optional。所以在Xcode 6.3之后引入nullability annotations一方面为了让iOS程序员平滑地从Objective-C过渡到Swift，另一方面也促使开发者在编写Objective-C代码时更加规范，减少开发人员之间的沟通成本。
__nullable && ___nonnull
__nullable指代对象可以为NULL或者为NIL
__nonnull指代对象不能为null
当我们不遵循这一规则时，编译器就会给出警告⚠️。
事实上，在任何可以使用const关键字的地方都可以使用__nullable和__nonnull，不过这两个关键字仅限于使用在指针类型上。而在方法的声明中，我们还可以使用不带下划线的nullable和nonnull，如下所示：
- (nullable id)itemWithName:(NSString * nonnull)name;
@property (nonatomic, copy, nonnull) NSArray * items;
@property (nonatomic, copy) NSArray * __nonnull items;
Nonnull区域设置(Audited Regions)
如果需要每个属性或每个方法都去指定nonnull和nullable，是一件非常繁琐的事。苹果用NS_ASSUME_NONNULL_BEGIN，NS_ASSUME_NONNULL_END这两个宏来统一给属性和方法参数和返回值加上nonnull修饰，NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END之间，定义的所有对象属性和方法默认都是nonnull，我们只需要去指定那些nullable的指针就可以了，大大节省开发时间。
null_resettable作用: get:不能返回为空, set可以为空
// 书写方式:
@property (nonatomic, strong, null_resettable) NSString *name;
// 注意;如果使用null_resettable,必须 重写get方法或者set方法,处理传递的值为空的情况
如果没有处理，编译器会给出警告⚠️：
null_unspecified:不确定是否为空,使用方式有三种
//书写方式只有这种
//方式一
@property (nonatomic, copy) NSString *_Null_unspecified _Null_name;
//方式二
@property (nonatomic, copy) NSString *__null_unspecified __null_Name;
//方式三
@property(nonatomic, copy, null_unspecified) NSNumber * null_name;
Lightweight Generics 轻量级泛型
Lightweight Generics 轻量级泛型，轻量是因为这是个纯编译器的语法支持（llvm 7.0），和 Nullability 一样，没有借助任何 objc runtime 的升级，也就是说，这个新语法在 Xcode 7 上可以使用且完全向下兼容（更低的 iOS 版本）
带泛型的容器
这无疑是本次最重大的改进，有了泛型后终于可以指定容器类中对象的类型了：
NSArray<NSString *> *strings = @[@"sun", @"yuan"];
NSDictionary<NSString *, NSNumber *> *mapping = @{@"a": @1, @"b": @2};
返回值的 id 被替换成具体的类型后，令人感动的代码提示也出来了：
假如向泛型容器中加入错误的对象，编译器会给出警告⚠️的：
系统中常用的一系列容器类型都增加了泛型支持，甚至连 NSEnumerator 也支持了。对比下面两种写法：
@property (readonly) NSArray *imageURLs;
@property (readonly) NSArray<NSURL *> *imageURLs;
不用多想就清楚下面的数组中存的是什么，避免了 NSString 和 NSURL 的混乱。
自定义泛型类
比起使用系统的泛型容器，更好玩的是自定义一个泛型类，目前这里还没什么文档，但拦不住我们写测试代码，假设我们要自定义一个 Stack 容器类：
@interface Stack<ObjectType> : NSObject
- (void)pushObject:(ObjectType)object;
- (ObjectType)popObject;
@property (nonatomic, readonly) NSArray<ObjectType> *allObjects;
@end
这个 ObjectType 是传入类型的 placeholder，它只能在 @interface 上定义（类声明、类扩展、Category），如果你喜欢用 T 表示也 ok，这个类型在 @interface 和 @end 区间的作用域有效，可以把它作为入参、出参、甚至内部 NSArray 属性的泛型类型，应该说一切都是符合预期的。我们还可以给 ObjectType 增加类型限制，比如：
// 只接受 NSNumber * 的泛型
@interface Stack<ObjectType: NSNumber *> : NSObject
// 只接受满足 NSCopying 协议的泛型
@interface Stack<ObjectType: id<NSCopying>> : NSObject
若什么都不加，表示接受任意类型 ( id )；当类型不满足时编译器将产生 error。
实例化一个 Stack，一切工作正常：
对于多参数的泛型，用逗号隔开，其他都一样，可以参考 NSDictionary 的头文件:
@interface NSDictionary<__covariant KeyType, __covariant ObjectType> : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration>
@property (readonly) NSUInteger count;
- (nullable ObjectType)objectForKey:(KeyType)aKey;
- (NSEnumerator<KeyType> *)keyEnumerator;
- (instancetype)init NS_DESIGNATED_INITIALIZER;
#if TARGET_OS_WIN32
- (instancetype)initWithObjects:(const ObjectType _Nonnull [_Nullable])objects forKeys:(const KeyType _Nonnull [_Nullable])keys count:(NSUInteger)cnt;
#else
- (instancetype)initWithObjects:(const ObjectType _Nonnull [_Nullable])objects forKeys:(const KeyType <NSCopying> _Nonnull [_Nullable])keys count:(NSUInteger)cnt NS_DESIGNATED_INITIALIZER;
#endif
- (nullable instancetype)initWithCoder:(NSCoder *)aDecoder NS_DESIGNATED_INITIALIZER;
@end
协变性和逆变性
在阅读苹果的API时会遇到一些奇怪的关键字：
协变和逆变都是术语，前者指能够使用比原始指定的派生类型的派生程度更大（更具体的）的类型，
后者指能够使用比原始指定的派生类型的派生程度更小（不太具体的）的类型。通俗来讲,协变就是从小到大,逆变则是从大到小。
当类支持泛型后，它们的 Type 发生了变化，比如下面三个对象看上去都是 Stack，但实际上属于三个 Type：
Stack *stack; // Stack *
Stack<NSString *> *stringStack; // Stack<NSString *>
Stack<NSMutableString *> *mutableStringStack; // Stack<NSMutableString *>
当其中两种类型做类型转化时，编译器需要知道哪些转化是允许的，哪些是禁止的，比如，默认情况下：
我们可以看到，不指定泛型类型的 Stack 可以和任意泛型类型转化，但指定了泛型类型后，两个不同类型间是不可以强转的，假如你希望主动控制转化关系，就需要使用泛型的协变性和逆变性修饰符了：
__covariant - 协变性，子类型可以强转到父类型
__contravariant - 逆变性，父类型可以强转到子类型
协变：
@interface Stack<__covariant ObjectType> : NSObject
效果：
逆变：
@interface Stack<__contravariant ObjectType> : NSObject
效果：
协变是非常好理解的，像 NSArray 的泛型就用了协变的修饰符，而逆变我还没有想到有什么实际的使用场景。
__kindof
__kindof 这修饰符还是很实用的，解决了一个长期以来的小痛点，拿原来的 UITableView 的这个方法来说：
- (id)dequeueReusableCellWithIdentifier:(NSString *)identifier;
使用时前面基本会使用 UITableViewCell 子类型的指针来接收返回值，所以这个 API 为了让开发者不必每次都蛋疼的写显式强转，把返回值定义成了 id 类型，而这个 API 实际上的意思是返回一个 UITableViewCell 或 UITableViewCell 子类的实例，于是新的 __kindof 关键字解决了这个问题：
- (__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier;
既明确表明了返回值，又让使用者不必写强转。再举个带泛型的例子，UIView 的 subviews 属性被修改成了：
@property (nonatomic, readonly, copy) NSArray<__kindof UIView *> *subviews;
这样，写下面的代码时就没有任何警告了：
UIButton *button = view.subviews.lastObject;
