解决iOS项目的版本兼容问题-结合宏、Category和Runtime
来源:互联网 发布:淘宝花钱推广有用吗 编辑:程序博客网 时间:2024/04/29 22:23
前言
最近,在做项目时,因为某种原因,突然要“适配”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
NSLog(@"Tutuge");
被宏定义包起来的代码是否会执行,在编译时就决定好了,无论你是用什么系统运行,宏定义再也没有什么卵用=。=
编译时检查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 ([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];
}
// ...
总的来说就是编译时、运行时的判断均不能少。
Weakly Linked - 运行时检查类、方法是否可用
除了用宏、系统版本检测,还可以用Weakly Linked特性做运行时的检查。
对于iOS4.2以上的,有NS_CLASS_AVAILABLE标示的类,可以如下判断是否可用:
1
2
3
4
5
6
7
8
// Weakly Linked判断
if ([UIAlertController class]) {
// 使用UIAlertController...
} else {
// 使用旧的方案...
}
也可以如下判断:
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 ([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));
}
}
// setSeparatorInset: 的Dummy方法
- (void)compatible_setSeparatorInset:(UIEdgeInsets) inset {
// 空方法都可以,只是为了接收setSeparatorInset:消息。
}
总结
在适配旧版本时,除了基本的宏定义、[UIDevice currentDevice].systemVersion判断,适当的用Runtime,可以大大减少对现有代码的“干涉”,多种方法相结合才是最好的。
嗯,还在用iOS6的用户,升个级呗=。=
- 解决iOS项目的版本兼容问题-结合宏、Category和Runtime
- 解决iOS项目的版本兼容问题-结合宏、Category和Runtime
- iOS学习笔记2(结合项目)--Category和Extension的区别
- runtime结合category和block动态增加方法以及属性
- 解决Android Studio版本兼容问题(低版本的AS打不开高版本的项目)
- 解决hbase和hdfs的hadoop版本不兼容问题
- 解决多版本SDk的兼容问题
- 解决多版本SDk的兼容问题
- 解决SQLserver不同版本的兼容问题
- iOS的category和protocol
- iOS的category和protocol
- 如何导入别人的android studio项目,解决gradle版本不兼容问题
- 解决IE版本兼容问题
- ios版本兼容问题
- 比较iOS类别Category和扩展Extension以及runtime的associative(关联)机制(容我水一发)
- IOS通过runtime给category添加属性
- iOS (Category)runtime动态添加属性
- 结合 category 工作原理分析 OC2.0 中的 runtime
- 第三十一讲项目1.2-求1到m的平方和
- Android广播BroadcastReceiver最简单使用示例
- LeetCode学习篇二十三——Path Sum
- 二维码制作带图片(图片包裹二维码)
- Mysql分库分表方案
- 解决iOS项目的版本兼容问题-结合宏、Category和Runtime
- spark集群配置
- 从无到有系列之Hive-内建操作符及函数开发hive04
- nginx中配置跨域支持功能
- SpringMVC4+thymeleaf3的一个简单实例(篇五:页面和MySql的数据交互-展示以及存储)
- 如何解决程序/C++Dll的兼容性问题
- SRM 551 Div1
- 进程与线程的关系和区别
- 学习笔记之JavaSE(29)--JavaAPI详解4