iOS-万能的Runtime(2):基于Runtime机制解决线上崩溃bug的一种思路

万能的Runtime(1):《iOS-浅谈NSUserDefaults保存数据的缺点以及改进方案:UDUserDefaultsModel》。

众所周知,安卓是基于Java进行开发,Java是有一个try catch机制的,我跟安卓的同事聊天时得知他们经常用。iOS实际上也可以用,但是当你打开调用@try时是无法关联剩余的@catch的,可见苹果对于这个也是不推荐的。同样的,我们应该也看不到任何人使用过@try @catch,我之前来自阿里的主管也不赞成使用这个。

    @try {
        NSLog(@"@try");
    } @catch (NSException *exception) {
        NSLog(@"%@",exception);
    } @finally {
        NSLog(@"@finally");
    }

既然我们很少用@try @catch去捕捉异常,再加上App Store有严格的审核发布流程,并非像安卓App那样可以随便上,这个样子就导致了iOS开发有一个尴尬的情况:上线之后产生了崩溃只能再加急上一个版本,这就基本上要耗时几天,这期间会造成用户的流失。

比如,在之前我们在做项目的时候碰到这样一种情况:后台应当给我返回一个String,但是后台的某一个函数报了异常,返回了NSNumber,然后使用NSUserDefaults储存,当使用的时候还是当做String,结果就崩溃(后台是PHP写的,真不愧是第一语言)。测试代码如下:

 NSString *string = (NSString *)[NSNumber numberWithInt:100];
    NSLog(@"length = %lu", (unsigned long)string.length);

运行报错日志如下:

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[__NSCFNumber length]: unrecognized selector sent to instance

出现这种情况呢,我只能说:这不是我iOS的锅。即使是后台再上线一次,我们App内的缓存数据也是没法修改的,只能还是崩溃。

这个时候,如果要是在启动App的时候,后台告诉我哪一个类的哪一个方法出了问题,经过程序猿的逻辑与测试之后将这个方法替换成一个空的function也没问题的话,那就可以暂时过渡了,然后趁着这段时间iOS赶紧发一个版本。

这个时候我们就用到了Runtime这个偏底层的机制。在Runtime中有一个method_exchangeImplementations,直译就是交换实现方法。思路就是:在知道某一个方法崩溃,同时被替换成一个空方法之后,对于App的功能影响不大,那么就可以使用

为此,我这里生命了两个类,CCModel1:

@interface CCModel1 : NSObject
@end

+ (void)classMethod1 {
    NSLog(@"CCModel1 -> classMethod1");
}

- (void)objectMethod1 {
    NSLog(@"CCModel1 -> objectMethod1");
}

- (instancetype)init {
    if (self = [super init]) {
        // 调用方法
        [[self class] classMethod1];
        [self objectMethod1];
    }
    
    return self;
}

CCModel2:

@interface CCModel2 : NSObject

@end

@implementation CCModel2

+ (void)classMethod2 {
    NSLog(@"CCModel2 -> classMethod2");
}

- (void)objectMethod2 {
    NSLog(@"CCModel2 -> objectMethod2");
}

@end

我们假设:CCModel1里面的classMethod1objectMethod1的方法是有问题的,我们把它替换成CCModel2的classMethod2objectMethod2(就假设CCModel2的两个方法是不执行任何操作的空方法吧!),流程如下:
1.声明一个专门用来执行method_exchangeImplementations的类,姑且叫他CCRuntime。
2.在CCRuntime类里找到出现问题的类与方法,以及被替换掉的类与方法,同时执行exchange操作。
代码如下

@interface CCRuntime : NSObject

@end

@implementation CCRuntime

+ (void)load {
    // 出现问题的类与方法
    // 获取指定的类
    Class cls1 = NSClassFromString(@"CCModel1");        // 出现问题的类
    Class cls2 = NSClassFromString(@"CCModel2");        // 一个包含有空方法的类
    
    // 交换指定的类方法
    Method classMethod1 = class_getClassMethod(cls1, NSSelectorFromString(@"classMethod1"));
    Method classMethod2 = class_getClassMethod(cls2, NSSelectorFromString(@"classMethod2"));
    method_exchangeImplementations(classMethod1, classMethod2);

    // 交换指定的对象方法
    Method objectMethod1 = class_getInstanceMethod(cls1, NSSelectorFromString(@"objectMethod1"));
    Method objectMethod2 = class_getInstanceMethod(cls2, NSSelectorFromString(@"objectMethod2"));
    method_exchangeImplementations(objectMethod1, objectMethod2);

在这里就要说说"+(void)load"这个方法了,以下是官方文档的解释:

Invoked whenever a class or category is added to the Objective-C runtime; implement this method to perform class-specific behavior upon loading.

从官方文档上来看:此方法是在加入runtime时才会调用,基于runtime相关知识可以了解到load方法会在main函数执行之前调用,如此就可以替换掉出现问题的方法。

这个时候还有一个难题:如何获取出现问题的类以及方法!为此我认为只有在App内集成Fabric和Bugly一类的第三方,然后在启动App时申请一个接口,获取到指定类与方法并保存下来,并且指定一个有效时间,下次启动App的时候进行替换。

这个是我想到的十分low的方法,我还看过相关的文档说lua和js可以实现抛出异常的meghod,奈何自己不太懂。

Github链接:Runtime。

Runtime学习课程

你可能感兴趣的:(iOS-万能的Runtime(2):基于Runtime机制解决线上崩溃bug的一种思路)