runtime的实际运用
避免nsnull崩溃
问题背景:在项目开发中,由于各种各样的原因,服务器接口常常会返回null,而在Objective-C中,向null 发送消息会引发 unrecognized selector的异常,引起app崩溃,产品体验非常不好。
解决方案:一种解决方案是获得服务器接口返回的数据后,进行判断,如果是null,则赋值一个空字符串,或者进行相应的处理,避免崩溃。但是一个完整项目里面使用的接口是非常多的,而且一个接口返回的字段也是非常多的,倘若对每个接口的每个字段都进行判断,一方面会写大量的重复代码,另一方面也破坏了代码的美观,且没有从根本上解决问题,属于治标不治本。
另一种方法是使用runtime解决。在Objective-C中,向nil发送消息是不会发生崩溃的。因此如果向null 发送了消息,可以通过消息转发,把消息最终的接收者设置为nil即可避免崩溃。通过上面的介绍,可以在最后一步,也就是 forwardingInvocation 中将消息的接收者设置为nil,不过 forwardingInvocation 需要配合 methodSignatureForSelector 方法使用。在 methodSignatureForSelector 方法中返回方法签名类,然后在 forwardingInvocation 进行消息转发即可。示例代码如下:
- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector
{
@synchronized([self class])
{
//look up method signature
NSMethodSignature *signature = [super methodSignatureForSelector:selector];
if (!signature)
{
//not supported by NSNull, search other classes
// 在这里构造NSMethodSignature
}
return signature;
}
}
- (void)forwardInvocation:(NSInvocation *)invocation
{
invocation.target = nil;
[invocation invoke];
}
避免数组越界崩溃
日常开发中,经常会碰到数组越界的情况,不幸的是,数组越界同样会直接引发崩溃,造成非常不好的体验。解决数组越界的方法很多,可以在使用的时候提前判断,比如说 在使用 [array objectAtIndex: i] 之前,先进行下面类似的判断
可以预见的是,项目中用到数组的地方会非常多,若每次使用之前都判断一下,会写大量重复冗余的代码。
另一种方法是写NSArray、NSMutableArray 的 category,在分类方法中判断一次就可以。这种方法的一个缺点是需要在项目中所有的调用都需要调用分类中的方法,这点需要和项目中的同事约定好,否则仍然避免不了数组越界引起崩溃的问题。
使用 Method Swizzling 可以解决数组越界的问题。Objective-C是动态语言,支持在运行时交换两个方法的实现。利用这一特性,可以写一个新的方法,如 hookObjectAtIndex 替换 objectAtIndex 方法,在hookObjectAtIndex 方法中判断数组越界的情况。这样,在项目中还是使用NSArray 的 objectAtIndex,但是实际执行的是 hookObjectAtIndex方法。示例代码如下:
+ (void)load
{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
/* 数组有内容obj类型才是__NSArrayI ,NSArray在runtime中对应的是__NSArrayI */
NSArray* obj = [[NSArray alloc] initWithObjects:@0, @1, nil];
[obj swizzleInstanceMethod:@selector(objectAtIndex:) withMethod:@selector(hookObjectAtIndex:)];
[obj release];
});
}
两个注意点:
1. Method Swizzling应该写在 + load 方法中,原因:+ load 方法在类加载时就会被执行;
2. Method Swizzling 应该总是在 dispatch_once 中执行,原因: Method Swizzling 的修改是影响全局的,因此只需要执行一次就可以了,dispatch_once 可以保证这一点。
PS:Method Swizzling 的功能非常强大,解决NSArray 越界崩溃只是一方面应用。
字典转模型
在项目开发中,服务器会返回json类型数据,这就需要我们在程序中将字典转为模型以方便使用。字典转模型通常有两种方法:
1. 自己写字典转模型的过程。示例代码如下:
- (instancetype)initWithDict:(NSDictionary *)dict
{
if(self = [super init]){
self.url = dict[@"url"];
self.width = dict[@"width"];
self.height = dict[@"height"];
}
return self;
}
这种方法的缺点是:倘若属性比较多,需要写较多的代码,我们项目中有接口返回将近20个字段,解析起来非常麻烦;如果模型增加了新的属性,需要增加相应的代码。
2. 另一种方法是使用一些第三方库,如YYModel、MJExtension等,可以帮助我们自动的将字典转为模型,省去了我们自己将属性和字典值对应的过程,以及增加属性时,不需要写新的代码。这些第三方库的实现原理使用到了runtime的知识。
通过上面的介绍知道,在Class的数据结构中有变量列表(struct objc_ivar_list *ivars),可以通过runtime获取到对象所属类的变量列表,然后将属性和字典中的值对应即可转成模型。示例代码如下:
-(instancetype)initWithDict:(NSDictionary *)dict {
if (self = [self init]) {
//(1)获取类的属性及属性对应的类型
NSMutableArray * keys = [NSMutableArray array];
NSMutableArray * attributes = [NSMutableArray array];
/*
* 例子
* name = value3 attribute = T@"NSString",C,N,V_value3
* name = value4 attribute = T^i,N,V_value4
*/
unsigned int outCount;
objc_property_t * properties = class_copyPropertyList([self class], &outCount);
for (int i = 0; i < outCount; i ++) {
objc_property_t property = properties[i];
//通过property_getName函数获得属性的名字
NSString * propertyName = [NSString stringWithCString:property_getName(property) encoding:NSUTF8StringEncoding];
[keys addObject:propertyName];
//通过property_getAttributes函数可以获得属性的名字和@encode编码
NSString * propertyAttribute = [NSString stringWithCString:property_getAttributes(property) encoding:NSUTF8StringEncoding];
[attributes addObject:propertyAttribute];
}
//立即释放properties指向的内存
free(properties);
//(2)根据类型给属性赋值
for (NSString * key in keys) {
if ([dict valueForKey:key] == nil) continue;
[self setValue:[dict valueForKey:key] forKey:key];
}
}
return self;
}
KVO的实现
KVO是Objective-C对观察者模式的一种实现,通过KVO,当被观察者对象的某个属性发生改变时,观察者就会收到通知,并做相应的处理。KVO的实现依赖于runtime。
苹果通过 isa-swizzling 的方式实现KVO。通过上面的介绍,我们知道在Object 对象的定义中有一个 isa 指针,指向的是该对象所属的类,KVO就是通过修改 isa 指针的指向实现的。具体过程:
当观察一个对象A时,假设该对象所属的类是TestA,KVO机制动态的创建了一个新的类,名称为NSKVONotifying_TestA,在新的类中重写了所观察属性的 setter 方法。新的setter方法会在调用原setter方法之前和之后通知观察者,观察者会做出相应的处理。在新建完NSKVONotifying_TestA类后,KVO机制会修改对象的 isa 指针,指向 NSKVONotifying_TestA 类,这样在调用 setter方法时,会调用 NSKVONotifying_TestA 的setter方法。新setter方法的实现大致如下:
- (void)setNow:(NSDate *)aDate {
[self willChangeValueForKey:@"now"];
[super setValue:aDate forKey:@"now"];
[self didChangeValueForKey:@"now"];
}
问题一:解决接口属性隐藏问题
问题描述:在编写SDK的时候,经常发现一些接口文件中,有部分属性不需要暴露给用户,但是在SDK内部其他文件中又需要使用该属性,最开始碰到这种问题最傻的解决办法就是拆分为两个不相关的文件。以下提供两个我在项目中使用过的方法(依次演进):
方案1:
在主类的实现文件(比如ClassA.m)中申明需要隐藏的属性(对外部不可见),然后在类别(ClassA + Private.h)中添加对应的属性,这样就可以处理不需要公开给SDK外部使用,而且对内部透明的属性和方法:
在SDK的头文件中不暴露ClassA + Private.h,然后SDK内部其他类中,如果要使用相关的属性和方法,可以直接引入ClassA + Private.h头文件,就可以顺利使用。目前这种方式只是在ClassA + Private.m中会有相应的警告,但目前未发现其他问题。
方案2:
ClassA.m中不添加属性,只在类别中ClassA + Private.h中添加属性,通过Runtime中的objc_getAssociatedObject()和objc_setAssociatedObject()两个方法实现动态添加属性。
问题二:解决检查页面创建释放问题 (检查项目中的页面推出时dealloc是否调用)
问题描述:在优化一个旧项目的时候,有时候需要知道每个页面是否正常及时释放,但是由于之前编码人员未给每个页面都写了dealloc方法或者未在dealloc中输出打印,现在为了在每个页面释放的时候,打印一些信息。解决这个问题,主要方案如下(依次演进):
方案1:
最傻的方法,每个要验证的页面添加dealloc打印,然后运行查看 。缺点:工作量太大;
方案2:
增加一个上帝类,在这个类中实现dealloc打印功能,然后让其他页面继承自这个页面。缺点:无法解决多继承,而且对于新人需要指导这个用法;
方案3:
为UIViewController建一个Category,然后重写dealloc方法覆盖页面本身的dealloc方法。缺点:本来的dealloc中其他的释放工作丢失;
方案4:
用Runtime方式解决这个问题,先给UIViewController增加一个类别,通过runtime中的class_addMethod()方法动态给UIViewController添加dealloc方法,用method_exchangeImplementations()方法,将UIViewController中的dealloc与自己的一个打印方法交换,无需要改其他代码,实现所有页面的释放的打印。方案4代码截图(主要是不知道怎么添加代码)如下:
写在最后
虽然看过很多大神写的Runtime文章,目前就只在项目中使用了这两种情况。欢迎大家在评论区提供更好的解决方案或者想法,第一次用Markdown写博客,表示还不会用。。。