美文网首页
不同iOS系统的兼容性

不同iOS系统的兼容性

作者: 哈布福禄克 | 来源:发表于2019-09-26 18:15 被阅读0次

    本文总结了一些常规的,和“非常规”的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!”

    所以并不是说,能编译通过的,就一定能运行成功 !还要在运行时检查 

    宏只在编译时生效!

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

    #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,检查支持的最小系统版本。

    运行时检查系统版本:

    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做兼容

    有时候,不同版本之间,同一个类、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,可以大大减少对现有代码的“干涉”,多种方法相结合才是最好的。


    相关文章

      网友评论

          本文标题:不同iOS系统的兼容性

          本文链接:https://www.haomeiwen.com/subject/ybdiyctx.html