关于iOS废弃的API 宏定义

如你所知,已废弃(Deprecated)的API指的是那些已经过时的并且在将来某个时间最终会被移除掉的方法或类。通常,苹果在引入一个更优秀的API后就会把原来的API给废弃掉。因为,新引入的API通常意味着可以更好的发挥新硬件或操作系统的性能,或者可以使用一些在构建原有API时根本还没有的语言特性(e.g. blocks)。

每当苹果添加新方法的时候,他们都会在方法声明的后面用一个很特殊的宏来标明哪些iOS版本支持它们。例如,在UIViewController中,苹果引入了一个使用block来处理回调的方法用来展示一个模态controller,它的声明是这样的:

-(void)presentViewController:(UIViewController*)viewControllerToPresentanimated:(BOOL)flagcompletion:(void(^)(void))completion  NS_AVAILABLE_IOS(5_0);

注意到NS_AVAILABLE_IOS(5_0)了吗?这就告诉我们这个方法可以在iOS5.0及以后的版本中使用。如果我们在比指定版本更老的版本中调用这个方法,就会引起崩溃。

那被这个方法替换了的那个旧方法又怎么样了呢?同样,它的声明后面也带了一个类似的语法,表示它已经被废弃了:

-(void)presentModalViewController:(UIViewController*)modalViewControlleranimated:(BOOL)animated  NS_DEPRECATED_IOS(2_0,6_0);

NS_DEPRECATED_IOS(2_0, 6_0)这个宏中有两个版本号。前面一个表明了这个方法被引入时的iOS版本,后面一个表明它被废弃时的iOS版本。被废弃并不是指这个方法就不存在了,只是意味着我们应当开始考虑将相关代码迁移到新的API上去了。

还有类似形式的一些宏用在iOS和OS X共用的类上。比如NSArray中的这个方法:

-(void)setObject:(id)objatIndexedSubscript:(NSUInteger)idx  NS_AVAILABLE(10_8,6_0);

这里的NS_AVAILABLE宏告诉我们这方法分别随Mac OS 10.8和iOS 6.0被引入。和NS_DEPRECATED_IOS类似,也有个宏叫NS_DEPRECATED,但它的参数要稍微复杂些:

1-(void)removeObjectsFromIndices:(NSUInteger*)indicesnumIndices:(NSUInteger)cnt  NS_DEPRECATED(10_0,10_6,2_0,4_0);

这里表示这个方法随Mac OS 10.0和iOS 2.0被引入,在Mac OS 10.6和iOS 4.0后被废弃。

Easy Come, Easy Go

 在iOS7和Mac OS 10.9 SDK中被新引入的Base64 API。有趣的是,有一组有相同功能的Base64方法,在被引入的同时也被废弃掉了。为什么苹果在引入一个API的同时又把它废弃掉了?那不是毫无意义的吗?好吧,其实也不是——它在下面这种情况下就非常有意义:

实际上,这些现在已经废弃的Base64方法从iOS4和Mac 0S 10.6开始就一直存在,只是它们是私有的。直到现在苹果才把它们公开,大概是苹果一直对它们的实现不满意,一直都想把它们改写。

果然,在iOS7中,苹果选定了一个他们感到满意的Base64 API,并且将它添加到了NSData的一个公有类别中。但现在,他们知道老方法已经被取代,不会被改写了,因此他们把它公开出来。当开发者的app仍然需要支持iOS6及以前的版本时,就有了一个系统内置的Base64 api可以用。

这就是为什么,如果你查看这些新API的方法声明,可以看到NS_DEPRECATED宏部分中的起始版本是4_0,虽然实际上直到iOS7之前,它从来都没有被作为公有API被引入过:

 -(NSString*)base64Encoding   NS_DEPRECATED(10_6,10_9,4_0,7_0);

这告诉你,基于iOS7 SDK开发的app如果调用了这个方法,它同样可以运行在iOS4+或Mac OS 10.6+的系统上而不会崩溃。很有用的吧?

如何使用已废弃的API

那么,如果我们有一个app需要同时支持iOS6和iOS7,想用内置的Base64方法,我们该怎么做呢?事实上,这相当简单,你只需要调用这些废弃的API就可以了。

那样编译器不是会产生警告吗?不会——只有你的deployment target版本号设置成大于或等于方法被弃用的版本号的时候才会收到编译器警告。只要你仍然在支持那些还没有废弃这个方法的iOS版本,都不会收到警告。

那么,如果苹果决定在iOS8中移除已弃用的Base64方法,你的应用程序会发生情况?简单来说,它肯定会崩溃,但是不要让这把你吓跑了:苹果不可能只在几个iOS版本后就将已废弃的API给移除(绝大多数已废弃的API在任何的iOS版本中都还没有被移除),除非你决定不再更新你的app,否则在你放弃支持iOS6之前有很多机会都可以更新到新的API。

但是如果假定我们在最坏的情况下(例如:我们不更新我们的app了,而苹果突然宣布了一个零容忍的不再向下兼容的政策),怎样让我们的代码保持永不过时并且仍然能够支持旧的系统版本呢?

这其实很简单,我们只需要做一些运行时的方法检测。使用NSObject的respondsToSelector:方法,我们可以检测,如果新的API存在,我们就调用它。否则,我们退回到已废弃的API。很简单:

 NSData*someData=...

NSString*base64String=nil;

// Check if new API is available

if([someData  respondsToSelector:@selector(base64EncodedDataWithOptions:)])

{// It exists, so let's call it

base64String=[someData  base64EncodedDataWithOptions:0];

}

else{// Use the old API

base64String=[someDatabase64Encoding];

}

此代码在iOS4及以上版本中有效,并且如果苹果在未来的iOS版本中移除base64Encoding方法后,同样可以正常工作。

为其他开发者编码的时候

如果你是在写一个app,这一切都很好,但是如果你是在编写一个给其他人使用的代码库呢?如果project的target是iOS4或iOS6的时候,上面的代码会工作的很好。但是如果deployment target是iOS 7+的时候,你就会收到编译器警告,说你使用了已废弃的base64Encoding方法。

该代码实际上永远都可以正常工作,因为那个方法在运行时永远都不会被调用(因为respondsToSelector:那个检查在iOS7上总是会返回YES)。但是可惜的是,编译器还不是足够的聪明能发现这点。而且,比如像我,你不会想用那些会产生编译器警告的第三方库,你肯定也不想自己的库中产生任何警告。 

那么,我们如何改写我们的代码,以便它可以用于任何deployment target,而不会产生警告?幸好,有一个编译器宏指令可以基于不同的deployment target做不同的代码分支。取决于app是为哪个最小的iOS版本编译的,我们可以用__IPHONE_OS_VERSION_MIN_REQUIRED这个宏来生成不同的代码。

下面的代码可以工作在任何的iOS版本上(不管是过去的还是将来的),而且不会产生任何警告:

#if __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_7_0

// Check if new API is not available

if(![someData  respondsToSelector:@selector(base64EncodedDataWithOptions:)])

{// Use the old API

base64String=[someData  base64Encoding];

}else

#endif

{// Use the new API

base64String=[someData  base64EncodedDataWithOptions:0];

}

看清楚我们在这里做了什么吗?我们变换了respondsToSelector:的用法:我们用它来测试是否新的API不可用,然后将整段代码放到一个条件代码块中,这样它就只会在deployment target比iOS7低的情况下才会被编译。如果app是为iOS6编译的,它就会先检查新的API是否存在,如果不存在就调用旧的API。如果app是为iOS7编译的,那一整块逻辑代码都会被跳过,直接调用新的API。


补充阅读

苹果有一个关于废弃API用法的实例和相关的编译器警告的简单文档,如果感兴趣可以看看。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,258评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,335评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,225评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,126评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,140评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,098评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,018评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,857评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,298评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,518评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,678评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,400评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,993评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,638评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,801评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,661评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,558评论 2 352

推荐阅读更多精彩内容