你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發基礎 >> 會報編譯器警告的Xcode 6.3新特性:Nullability Annotations

會報編譯器警告的Xcode 6.3新特性:Nullability Annotations

編輯:IOS開發基礎

1433125203835884.jpg

最近在用Xcode 6.3寫代碼,一些涉及到對象的代碼會報如下編譯器警告:

Pointer is missing a nullability type specifier (__nonnull or __nullable)

於是google了一下,發現這是Xcode 6.3的一個新特性,即nullability annotations

Nullability Annotations

我們都知道在swift中,可以使用!和?來表示一個對象是optional的還是non-optional,如view?和view!。而在Objective-C中則沒有這一區分,view即可表示這個對象是optional,也可表示是non-optioanl。這樣就會造成一個問題:在Swift與Objective-C混編時,Swift編譯器並不知道一個Objective-C對象到底是optional還是non-optional,因此這種情況下編譯器會隱式地將Objective-C的對象當成是non-optional。

為了解決這個問題,蘋果在Xcode 6.3引入了一個Objective-C的新特性:nullability annotations。這一新特性的核心是兩個新的類型注釋:__nullable__nonnull。從字面上我們可以猜到,__nullable表示對象可以是NULL或nil,而__nonnull表示對象不應該為空。當我們不遵循這一規則時,編譯器就會給出警告。

我們來看看以下的實例,

@interface TestNullabilityClass ()
@property (nonatomic, copy) NSArray * items;
- (id)itemWithName:(NSString * __nonnull)name;
@end
@implementation TestNullabilityClass
...
- (void)testNullability {
    [self itemWithName:nil];    // 編譯器警告:Null passed to a callee that requires a non-null argument
}
- (id)itemWithName:(NSString * __nonnull)name {
    return nil;
}
@end

不過這只是一個警告,程序還是能編譯通過並運行。

事實上,在任何可以使用const關鍵字的地方都可以使用__nullable和__nonnull,不過這兩個關鍵字僅限於使用在指針類型上。而在方法的聲明中,我們還可以使用不帶下劃線的nullable和nonnull,如下所示:

- (nullable id)itemWithName:(NSString * nonnull)name

在屬性聲明中,也增加了兩個相應的特性,因此上例中的items屬性可以如下聲明:

@property (nonatomic, copy, nonnull) NSArray * items;

當然也可以用以下這種方式:

@property (nonatomic, copy) NSArray * __nonnull items;

推薦使用nonnull這種方式,這樣可以讓屬性聲明看起來更清晰。

Nonnull區域設置(Audited Regions)

如果需要每個屬性或每個方法都去指定nonnull和nullable,是一件非常繁瑣的事。蘋果為了減輕我們的工作量,專門提供了兩個宏:NS_ASSUME_NONNULL_BEGIN和NS_ASSUME_NONNULL_END。在這兩個宏之間的代碼,所有簡單指針對象都被假定為nonnull,因此我們只需要去指定那些nullable的指針。如下代碼所示:

NS_ASSUME_NONNULL_BEGIN
@interface TestNullabilityClass ()
@property (nonatomic, copy) NSArray * items;
- (id)itemWithName:(nullable NSString *)name;
@end
NS_ASSUME_NONNULL_END

在上面的代碼中,items屬性默認是nonnull的,itemWithName:方法的返回值也是nonnull,而參數是指定為nullable的。

不過,為了安全起見,蘋果還制定了幾條規則:

  1. typedef定義的類型的nullability特性通常依賴於上下文,即使是在Audited Regions中,也不能假定它為nonnull。

  2. 復雜的指針類型(如id *)必須顯示去指定是nonnull還是nullable。例如,指定一個指向nullable對象的nonnull指針,可以使用”__nullable id * __nonnull”。

  3. 我們經常使用的NSError **通常是被假定為一個指向nullable NSError對象的nullable指針。

兼容性

因為Nullability Annotations是Xcode 6.3新加入的,所以我們需要考慮之前的老代碼。實際上,蘋果已以幫我們處理好了這種兼容問題,我們可以安全地使用它們:

  1. 老代碼仍然能正常工作,    即使對nonnull對象使用了nil也沒有問題。

  2. 老代碼在需要和swift混編時,在新的swift編譯器下會給出一個警告。

  3. nonnull不會影響性能。事實上,我們仍然可以在運行時去判斷我們的對象是否為nil。

事實上,我們可以將nonnull/nullable與我們的斷言和異常一起看待,其需要處理的問題都是同一個:違反約定是一個程序員的錯誤。特別是,返回值是我們可控的東西,如果返回值是nonnull的,則我們不應該返回nil,除非是為了向後兼容。

參考

  1. Nullability and Objective-C

  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved