本文共 6302 字，大约阅读时间需要 21 分钟。
转自:
更新
2015-11-16
感谢微博好友@zyyy_000的评论，补充了为什么要在+ (void)load方法里面做Method Swizzling。
前言
最近，在做项目时，因为某种原因，突然要“适配”iOS6（也是醉了。。。），保证极少数的iOS6用户可以“用上”新的版本。哪怕界面上有瑕疵，只要功能正常就行。于是就只好花几天时间对iOS6进行紧急适配（心中一万头驼羊奔跑而过。。。）
本文总结了一些常规的，和“非常规”的iOS项目向老版本兼容的办法，结合了宏定义、Category和Runtime，大家看着消遣一下就好哈~
重点概念
首先强调一些概念。
Deployment Target 和 Base SDK
Deployment Target
指的是你的APP能支持的最低系统版本，如要支持iOS6以上，就设置成iOS6即可。
Base SDK
指的是用来编译APP的SDK（Software Development Kit）的版本，一般保持当前XCode支持的最新的就好，如iOS8.4。SDK其实就是包含了所有的你要用到的头文件、链接库的集合，你的APP里面用的各种类、函数，能编译、链接成最后的安装包，就要靠它，苹果每次升级系统，新推出的各种API，也是在SDK里面。所以一般Base SDK肯定是大于等于Deployment Target的版本。
区分
既然Base SDK的版本大于等于Deployment Target的版本，那么就要小心了，因为“只要用到的类、方法，在当前的Base SDK版本里面存在，就可以编译通过！但是一旦运行APP的手机的系统版本低于这些类、方法的最低版本要求，APP就会Crash！”
所以并不是说，能编译通过的，就一定能运行成功！还要在运行时检查！简单来说，就是如下图：
宏只在编译时生效！
宏定义只是纯粹的文本替换，只在编译时起作用。如下代码：
1 2 3 | #if __IPHONE_OS_VERSION_MIN_REQUIRED >= 70000 NSLog(@"Tutuge"); #endif |
被宏定义包起来的代码是否会执行，在编译时就决定好了，无论你是用什么系统运行，宏定义再也没有什么卵用=。=
编译时检查SDK版本，运行时检查系统版本
这个是最基本的适配手段。
用到的宏如下：
- __IPHONE_OS_VERSION_MAX_ALLOWED: 值等于Base SDK，即用于检查SDK版本的。
- __IPHONE_OS_VERSION_MIN_REQUIRED: 值等于Deployment Target，检查支持的最小系统版本。
运行时检查系统版本：
1 2 3 | if ([UIDevice currentDevice].systemVersion.floatValue > 8.0f) { // ... } |
假如我们现在想用iOS8新的UIAlertController来显示提示框，应该如下判断：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | // 编译时判断：检查SDK版本 #if __IPHONE_OS_VERSION_MAX_ALLOWED > 80000 // 运行时判断：检查当前系统版本 if ([UIDevice currentDevice].systemVersion.floatValue > 8.0f) { UIAlertController *alertController = [UIAlertController alertControllerWithTitle:@"Tutuge" message:@"Compatibility" preferredStyle:UIAlertControllerStyleAlert]; [alertController addAction:[UIAlertAction actionWithTitle:@"Cancel" style:UIAlertActionStyleCancel handler:^(UIAlertAction *action) { NSLog(@"Cancel"); }]]; [self presentViewController:alertController animated:YES completion:nil]; } else { // 用旧的代替 UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Tutuge" message:@"Compatibility" delegate:nil cancelButtonTitle:@"Cancel" otherButtonTitles:nil]; [alertView show]; } #else // ... #endif |
总的来说就是编译时、运行时的判断均不能少。
Weakly Linked - 运行时检查类、方法是否可用
除了用宏、系统版本检测，还可以用Weakly Linked特性做运行时的检查。
对于iOS4.2以上的，有NS_CLASS_AVAILABLE标示的类，可以如下判断是否可用：
1 2 3 4 5 6 7 8 | #if __IPHONE_OS_VERSION_MAX_ALLOWED > 80000 // Weakly Linked判断 if ([UIAlertController class]) { // 使用UIAlertController... } else { // 使用旧的方案... } #endif |
也可以如下判断：
1 2 3 4 5 6 | Class class = NSClassFromString (@"UIAlertController"); if (class) { // 使用UIAlertController... } else { // 使用旧的方案... } |
对于方法，如下判断:
1 2 3 4 5 | if ([UITableViewCell instancesRespondToSelector:@selector (setSeparatorInset:)]) { // ... } else { // ... } |
至于用哪种方法，统一一下即可。
用Method Swizzling做兼容
有关Runtime、Method Swizzling的资料很多，各位自行阅读哈~
在+ (void)load方法里面做替换
这里提一下为什么要在+ (void)load方法里面做Method Swizzling。
在Objective-C中，运行时会自动调用每个类的两个方法。+ (void)load会在类、Category初始加载时调用，+ (void)initialize会在第一次调用类的类方法或实例方法之前被调用。
但是需要注意的是，+ (void)initialize是可以被Category覆盖重写的，并且有多个Category都重写了+ (void)initialize方法时，只会运行其中一个，所以在+ (void)initialize里面做Method Swizzling显然是不行的。
而+ (void)load方法只要实现了，就一定会调用。具体为什么大家可以自行阅读Runtime的源码，或者查阅相关文章。
用dispatch_once保证只运行一次
因为Method Swizzling的影响是全局的，而且一旦多次调用，会出错，所以这个时候用dispatch_once就再合适不过了~
实例
下面就是利用Method Swizzling做兼容的一个例子。
有时候，不同版本之间，同一个类、View控件的默认属性可能都会变化，如UILabel的背景色在iOS6上，默认是白色，而iOS6以后是透明的！如果在每个用到UILabel的地方，都手动设置一次背景色，代价太大。这个时候就需要Runtime的“黑魔法”上场。
就以设置UILabel的默认背景色透明为例，就是在UILabel初始化时，如initWithFrame之前，先设置好透明背景色，简单的示例如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | // 创建Category @implementation UILabel (TTGCompatibility) + (void)load { static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ // 先判断系统版本，尽量减少Runtime的作用范围 if ([UIDevice currentDevice].systemVersion.floatValue < 7.0f) { // Method Swizzling // initWithFrame Method oriMethod = class_getInstanceMethod(self, @selector(initWithFrame:)); Method newMethod = class_getInstanceMethod(self, @selector(compatible_initWithFrame:)); method_exchangeImplementations(oriMethod, newMethod); // initWithCoder... } }); } // initWithFrame - (id)compatible_initWithFrame:(CGRect)frame { id newSelf = [self compatible_initWithFrame:frame]; // 设置透明背景色 ((UILabel *)newSelf).backgroundColor = [UIColor clearColor]; return newSelf; } // initWithCoder... |
运行时添加“Dummy”方法，减少代码改动
Dummy，意思是“假的、假动作、假人”，在这里指的是为旧版本不存在的方法提供一个“假的”替代方法，防止因新API找不到而导致的Crash。
以UITableViewCell的“setSeparatorInset:”方法为例，在iOS6中，压根就不存在separatorInset，但是现有的代码里面大量的调用了这个方法，怎么办？难道一个一个的去加上判断条件？代价太大。
这个时候就可以用Runtime的手段，在运行时添加一个Dummy方法，去“代替接收”setSeparatorInset消息，防止在iOS6上的Crash。
代码如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | @implementation UITableViewCell (TTGCompatibility) + (void)load { // 编译时判断SDK #if __IPHONE_OS_VERSION_MAX_ALLOWED > __IPHONE_7_0 // 运行时判断系统版本 if ([UIDevice currentDevice].systemVersion.floatValue < 7.0f) { Method newMethod = class_getInstanceMethod(self, @selector(compatible_setSeparatorInset:)); // 增加Dummy方法 class_addMethod( self, @selector(setSeparatorInset:), method_getImplementation(newMethod), method_getTypeEncoding(newMethod)); } #endif } // setSeparatorInset: 的Dummy方法 - (void)compatible_setSeparatorInset:(UIEdgeInsets) inset { // 空方法都可以，只是为了接收setSeparatorInset:消息。 } |
总结
在适配旧版本时，除了基本的宏定义、[UIDevice currentDevice].systemVersion判断，适当的用Runtime，可以大大减少对现有代码的“干涉”，多种方法相结合才是最好的。
嗯，还在用iOS6的用户，升个级呗=。=
参考
转载地址：http://ptvsi.baihongyu.com/