Overview

自 WWDC 2015 推出和開源 Swift 2.0 后，大家對 Swift 的熱情又一次高漲起來，在羨慕創(chuàng)業(yè)公司的朋友們大談 Swift 新特性的同時，也有很多像我一樣工作上依然需要堅守著 Objective-C 語言的開發(fā)者們。今年的 WWDC 中介紹了幾個 Objective-C 語言的新特性，還是在“與 Swift 協(xié)同工作”這種 Topic 里講的，越發(fā)凸顯這門語言的邊緣化了，不過有新特性還是極好的，接下來，本文將介紹下面三個主要的新特性：

Nullability

Lightweight Generics *

__kindof

Nullability

然而 Nullability 并不算新特性了，從上一個版本的 llvm 6.1 (Xcode 6.3) 就已經支持。這個簡版的 Optional ，沒有 Swift 中 ? 和 ! 語法糖的支持，在 Objective-C 中就顯得非常啰嗦了：

@property (nonatomic, strong, nonnull) Sark *sark; 
@property (nonatomic, copy, readonly, nullable) NSArray *friends; 
+ (nullable NSString *)friendWithName:(nonnull NSString *)name; 

假如用來修飾一個變量，前面還要加雙下劃線，放到 block 里面就更加詭異，比如一個 Request 的 start 方法可以寫成：

- (void)startWithCompletionBlock:(nullable void (^)(NSError * __nullable error))block; 

除了這倆外，還有個 null_resettable 來表示 setter nullable，但是 getter nonnull，繞死了，最直觀例子就是 UIViewController 中的 view 屬性：

@property (null_resettable, nonatomic, strong) UIView *view; 

它可以被設成 nil，但是調用 getter 時會觸發(fā) -loadView 從而創(chuàng)建并返回一個非 nil 的 view。

從 iOS9 SDK 中可以發(fā)現(xiàn)，頭文件中所有 API 都已經增加了 Nullability 相關修飾符，想了解這個特性的用法，翻幾個系統(tǒng)頭文件就差不離了。接口中 nullable 的是少數(shù)，所以為了防止寫一大堆 nonnull，F(xiàn)oundation 還提供了一對兒宏，包在里面的對象默認加 nonnull 修飾符，只需要把 nullable 的指出來就行，黑話叫 Audited Regions：

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，方便開發(fā)者第一時間發(fā)現(xiàn)潛在問題。不過我想更大的意義在于能夠更加清楚的描述接口，是主調者和被調者間的一個協(xié)議，比多少句文檔描述都來得清晰，打個比方：

+ (nullable instancetype)URLWithString:(NSString *)URLString; 

NSURL 的這個 API 前面加了 nullable 后，更加顯式的指出了這個接口可能因為 URLString 的格式錯誤而創(chuàng)建失敗，使用時自然而然的就考慮到了判空處理。

不僅是屬性和方法中的對象，對于局部的對象、甚至 c 指針都可以用帶雙下劃線的修飾符，可以理解成能用 const 關鍵字的地方都能用 Nullability。

所以 Nullability 總的來說就是，寫著丑B，用著舒服 - -

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 被替換成具體的類型后，令人感動的代碼提示也出來了：

假如向泛型容器中加入錯誤的對象，編譯器會不開心的：

系統(tǒng)中常用的一系列容器類型都增加了泛型支持，甚至連 NSEnumerator 都支持了，這是非常 Nice 的改進。和 Nullability 一樣，我認為最大的意義還是豐富了接口描述信息，對比下面兩種寫法：

@property (readonly) NSArray *imageURLs; 
@property (readonly) NSArray<NSURL *> *imageURLs; 

不用多想就清楚下面的數(shù)組中存的是什么，避免了 NSString 和 NSURL 的混亂。

自定義泛型類

比起使用系統(tǒng)的泛型容器，更好玩的是自定義一個泛型類，目前這里還沒什么文檔，但攔不住我們寫測試代碼，假設我們要自定義一個 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 區(qū)間的作用域有效，可以把它作為入?yún)ⅰ⒊鰠ⅰ⑸踔羶炔?NSArray 屬性的泛型類型，應該說一切都是符合預期的。我們還可以給 ObjectType 增加類型限制，比如：

// 只接受 NSNumber * 的泛型 
@interface Stack<ObjectType: NSNumber *> : NSObject 
// 只接受滿足 NSCopying 協(xié)議的泛型 
@interface Stack<ObjectType: id<NSCopying>> : NSObject 

若什么都不加，表示接受任意類型 ( id )；當類型不滿足時編譯器將產生 error。

實例化一個 Stack，一切工作正常：

對于多參數(shù)的泛型，用逗號隔開，其他都一樣，可以參考 NSDictionary 的頭文件。

協(xié)變性和逆變性

當類支持泛型后，它們的 Type 發(fā)生了變化，比如下面三個對象看上去都是 Stack，但實際上屬于三個 Type：

Stack *stack; // Stack * 
Stack<NSString *> *stringStack; // Stack<NSString *> 
Stack<NSMutableString *> *mutableStringStack; // Stack<NSMutableString *> 

當其中兩種類型做類型轉化時，編譯器需要知道哪些轉化是允許的，哪些是禁止的，比如，默認情況下：

我們可以看到，不指定泛型類型的 Stack 可以和任意泛型類型轉化，但指定了泛型類型后，兩個不同類型間是不可以強轉的，假如你希望主動控制轉化關系，就需要使用泛型的協(xié)變性和逆變性修飾符了：

__covariant - 協(xié)變性，子類型可以強轉到父類型（里氏替換原則）

__contravariant - 逆變性，父類型可以強轉到子類型（WTF?）

協(xié)變：

@interface Stack<__covariant ObjectType> : NSObject 

效果：

逆變：

@interface Stack<__contravariant ObjectType> : NSObject 

效果：

協(xié)變是非常好理解的，像 NSArray 的泛型就用了協(xié)變的修飾符，而逆變我還沒有想到有什么實際的使用場景。

__kindof

__kindof 這修飾符還是很實用的，解決了一個長期以來的小痛點，拿原來的 UITableView 的這個方法來說：

- (id)dequeueReusableCellWithIdentifier:(NSString *)identifier; 

使用時前面基本會使用 UITableViewCell 子類型的指針來接收返回值，所以這個 API 為了讓開發(fā)者不必每次都蛋疼的寫顯式強轉，把返回值定義成了 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; 

Where to go

有了上面介紹的這些新特性以及如 instancetype 這樣的歷史更新，Objective-C 這門古老語言的類型檢測和類型推斷終于有所長進，現(xiàn)在不論是接口還是代碼中的 id 類型都越來越少，更多潛在的類型錯誤可以被編譯器的靜態(tài)檢查發(fā)現(xiàn)。

同時，個人感覺新版的 Xcode 對繼承鏈構造器的檢測也加強了，NS_DESIGNATED_INITIALIZER 這個宏并不是新面孔，可以使用它標志出像 Swift 一樣的指定構造器和便捷構造器。

最后，附上一段用上了所有新特性的代碼，Swift 是發(fā)展趨勢，如果你暫時依然要寫 Objective-C 代碼，把所有新特性都用上，或許能讓你到新語言的遷移更無痛一點。