2015年Objective-C有哪些新功能？

     雖然6月8日蘋果WWDC大會之后，所有iOS開發(fā)者的眼光都被Swift 2和iOS 9吸引了，而iOS開發(fā)老語言Objective-C的受歡迎度卻大不如從前。

     雖然iOS開發(fā)出了新的swift語言，但是絕大部分老iOS開發(fā)從業(yè)者及新入門者，都沒有放棄對Objective-C語言的使用和學(xué)習(xí)。所以蘋果公司在今天也對Objective-C做了一些升級，以往這門語言的使用“局限”將不復(fù)存在。下面我們就一起來看下，今年Objective-C語言做了升級。

The Setup

iOS開發(fā)人員，對下面的代碼一定再熟悉不過了，我們來重溫一下吧：

@property(strong, nonatomic) NSArray *someViews;

這絕對符合Objective-C完美主義開發(fā)者的標(biāo)準(zhǔn)。對它表示的屬性，不同人有不同觀點。但是，其中仍然存在著一些難以察覺的缺陷。

是否可能返回nil？

除非有現(xiàn)成的文件，或開發(fā)者全程都在一旁，否則光憑看是無法獲取信息的。

除了UIView之外還有什么？

還是那句話——不確定。也許答案是reflection？ 或許問題可以改成：除了UIView，有可能出現(xiàn)UIView子類嗎？

看樣子會出現(xiàn)諸多轉(zhuǎn)換（casting）

因為是一隊列……東西，知道那東西是什么之后，經(jīng)過cast后才能利用。

會弱化Swift代碼和可讀性

很遺憾，Swift語言支持泛型（generics）就意味著（Objective-C ）只會以optional的AnyObject集合的形式出現(xiàn)。如此一來，開發(fā)者要使用該屬性就必須在Swift和Objective-C之間進行轉(zhuǎn)換。

NullabilityAnnotations

僅僅是一個屬性就引發(fā)了這么多的擔(dān)憂，還挺讓人不安的。如果代碼本身引發(fā)很多質(zhì)疑，出現(xiàn)error的可能性就大大增加，更別提在廣為熟知的Objective-C和語言新秀Swift之間相互調(diào)用（interoperability）了?，F(xiàn)在Objective-C有了nullability annotations這個新功能，問題就簡單多了，也可為編程剩下很多麻煩。

intent.

現(xiàn)在談到API，（intent.）可能會，也可能不會返回nil，但不管怎樣，終于不用花費數(shù)小時來排除漏洞了。以下有三個選項：

nullable — ThinkUIView?

nonnull — ThinkUIView

null_unspecified— Think UIView!

再回到實例屬性。假設(shè)在運行時迭代這個屬性來創(chuàng)建某個用戶界面，在相應(yīng)的位置應(yīng)該有UIButton和UIView。

intent.大大提升了Objective-C，而且這個屬性也不會在Swift里滿滿都是optional了。計算機的靜態(tài)檢驗和Swift的可用性都得到了提升，最重要的是實現(xiàn)了API的intent通訊。

泛型

泛型的缺席一直以來是Objective-C開發(fā)者心頭之痛，而在這門語言誕生32年之后，終于也支持泛型了。對于Objective-C來說，支持泛型將帶來諸多改變，而且都是積極的改變。

現(xiàn)在可以定義屬性，下指令給編譯器來顯示所有UIView：

@property(strong, nonatomic, nonnull) NSArray<UIView *> *someViews;

向?qū)傩詮娂?/span>UIView之外的東西時，編譯器會報錯。而且如今不用做大量頭痛的轉(zhuǎn)換（cast）了。

      雖然Objective-C語言和swift語言看起來像iOS開發(fā)平臺兩個對立的語言，但Objective-C支持泛型確實對Swift而言也是好消息。Objective-C上次更新時，讓Swift知道對象不應(yīng)該是optional的，現(xiàn)在Swift還知道它們是UIViews，如此一來含混不清的AnyObject聲明就不需要了。如今的Objective-C可以像C#、C++、Swift等語言一樣通過<>括號來表示類型了。雖然通常是對協(xié)議表示一致性（conformance），但編譯器知道何時、何地以及如何運用它們，且運用是經(jīng)過推理的。

泛型的強大體現(xiàn)在整個Objective-C之中，可以用參數(shù)來表示擴展（extensions）、類別（categories）和類（classes），好處不僅僅體現(xiàn)在集合（collections）上，集合僅僅是結(jié)果而已。舉個例子，看看NSDictionary，開發(fā)者肯定會偷著樂吧：

@interfaceNSDictionary<KeyType, ObjectType> (Lookup)

- (nullableObjectType)objectForKey:(KeyType)aKey;

@end

剛開始知道類型擦除（typeerasure）是為了這個的時候，我有點兒不滿意，但考慮到老舊的Objective-C程序堆積在一起的問題，也就釋懷了。類型擦除（type erasure）不但能實現(xiàn)二進制兼容，而且不改變Objective-C的執(zhí)行時間。

KindOf Types

再次調(diào)用之前定義的屬性，就會顯示UIView。判斷里面包含著views和buttons是再正常不過的事。

這種情況下，添加如下代碼會發(fā)生什么呢？

[self.someViews[0]addTarget:self action:selector(aMethod:)forControlEvents:UIControlEventTouchUpInside];

編譯器警告！

這是因為即便可以在這個屬性里插入一個button，就算可以假設(shè)是個UIView，button也不一定沒有經(jīng)過轉(zhuǎn)換。

新的KindOf特性能夠輕松解決這種始料未及的情況。我們再回到實例屬性上：

@property(strong, nonatomic, nonnull) NSArray<__kindof UIView *> *someViews;

實際上我們已經(jīng)告訴編譯器：屬性及其集合會出現(xiàn)一些UIView。這樣在類型協(xié)議里顯示更多我們之前看不到的信息。其本質(zhì)向下轉(zhuǎn)型（downcasting）。

這意味著上述代碼編譯沒什么問題，因為編譯器知道集合里肯定會出現(xiàn)一個button。

雖然不喜歡Swift的人可能會刻意夸大Objective-C的優(yōu)點，但如今兩種語言實現(xiàn)了互相調(diào)用，這是Objective-C所有提升的最大價值所在。毋庸置疑，Objective-C的確比以往更加強大。

總結(jié)

    雖然swift語言不斷升級、變強，越來越多的iOS開發(fā)者開始使用swift語言了，但是還是有絕大部分的人在使用、學(xué)習(xí)swift的同時，仍在繼續(xù)研究Objective-C語言，也還有很多初學(xué)者正在糾結(jié)到底是學(xué)swift還是Objective-C。相信，隨著Objective-C的不斷升級，將讓大家對這兩門語言的選擇上，更加“欲擺不能”。不過這是好事，既然都好，那就讓自己同時駕馭這兩門語言吧。