迭代开发中如何处理版本兼容性问题

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！” 

所以并不是说，能编译通过的，就一定能 运行成功 ！还要在 运行时检查 ！简单来说，就是如下图：

宏只在编译时生效！

宏定义只是纯粹的文本替换，只在编译时起作用。如下代码：

#if __IPHONE_OS_VERSION_MIN_REQUIRED >= 70000
    NSLog(@"Tutuge");
#endif

被宏定义包起来的代码是否会执行，在编译时就决定好了，无论你是用什么系统运行，宏定义再也没有什么卵用=。=

编译时检查SDK版本，运行时检查系统版本

这个是最基本的适配手段。

用到的宏如下：

1. __IPHONE_OS_VERSION_MAX_ALLOWED : 值等于Base SDK，即用于检查SDK版本的。
2. __IPHONE_OS_VERSION_MIN_REQUIRED : 值等于Deployment Target，检查支持的最小系统版本。

运行时检查系统版本： 

if ([UIDevice currentDevice].systemVersion.floatValue > 8.0f) {
    // ...
}

假如我们现在想用iOS8新的 UIAlertController 来显示提示框，应该如下判断： 

// 编译时判断：检查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 标示的类，可以如下判断是否可用：

#if __IPHONE_OS_VERSION_MAX_ALLOWED > 80000
    // Weakly Linked判断
    if ([UIAlertController class]) {
        // 使用UIAlertController...
    } else {
        // 使用旧的方案...
    }
#endif

也可以如下判断：

Class class = NSClassFromString (@"UIAlertController");
if (class) {
    // 使用UIAlertController...
} else {
    // 使用旧的方案...
}

对于方法，如下判断:

if ([UITableViewCell instancesRespondToSelector:@selector (setSeparatorInset:)]) {
    // ...
} else {
    // ...
}

至于用哪种方法，统一一下即可。

用Method Swizzling做兼容

有关Runtime、Method Swizzling的资料很多，各位自行阅读哈~

有时候，不同版本之间，同一个类、View控件的默认属性可能都会变化，如UILabel的背景色在iOS6上，默认是白色，而iOS6以后是透明的！如果在每个用到UILabel的地方，都手动设置一次背景色，代价太大。这个时候就需要Runtime的“黑魔法”上场。

就以设置UILabel的默认背景色透明为例，就是在UILabel初始化时，如initWithFrame之前，先设置好透明背景色，简单的示例如下：

// 创建Category
@implementation UILabel (TTGCompatibility)

+ (void)load {

    // 先判断系统版本，尽量减少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。

代码如下：

@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，可以大大减少对现有代码的“干涉”，多种方法相结合才是最好的。