问题杂记:友盟分享 SDK 和 load 加载耗时统计冲突问题

1,288 阅读8分钟

前言

前几天早上,当我准备高高兴兴,投入世界上最为幸福的事情 -- 打码时,收到了测试小姐姐的一个消息。在那一瞬间,我有了一种不妙的预估,打开消息一看,不出所料,果然是你, bug 小怪兽。

问题描述

测试小姐姐说,这个版本,整个 App 的所有分享,突然都不能分享。我收到消息时,是一脸懵逼的,App 的原生分享功能组件从一开始就有了,已经有 n 个版本没有修改过分享的功能组件,怎么就突然就不能分享了呢。测试小姐姐是不是下载错版本了,自己直接跑了下开发版本调试下,嗯,没错,就是测试小姐姐下载错版本了 ........ 然而开发版本也是分享不了的。点击分享微信按钮时,会提示“请先安装微信客户端”。

接下来,就是振奋人心的打倒小怪物环节。

问题查找

分析小怪物的类型,属于哪一个品种的,和人类是否有生殖隔离

首先,根据提示,搜索了下 “请先安装微信客户端”,发现是由于调用友盟的 [UMSocialManager isInstall:] 判断是否安装微信时,友盟相关的接口返回了 false,所以业务判断未安装微信,就弹出了相关的提示。我尝试了下不判断是否安装微信,直接调用友盟的分享接口进行分享,也是无法正常分享的。由于和友盟 SDK 相关,所以进行了一下的问题排查。

  • 打开友盟 SDK 的 Log 打印,查看 SDK 内部的日志情况如下图

image.png

从日志中,可以看到友盟各个分项平台的初始化都失败了,友盟相关的问题文章中,也给出了 2 种检查方案,尝试后都没有解决问题。

  • 查下友盟的相关版本,看是否是版本导致的问题。

出现问题的友盟 SDK 的版本为 6.9.6,而截至到 4月3日,友盟官网上最新的 SDK 的版本是 6.9.8。查了下更新文档,主要解决的是微信进行要求的 Universal Link 的相关配置。虽然感觉应该没有关系,但抱着尝试的态度,还是把 SDK 更新到最新版本 6.9.8。经过测试后,问题还是无法解决。

  • 回滚到上个版本,对比 2 个版本之间的代码差异。

回滚到上个可用版本后,发现友盟的分享功能(SDK 版本是 6.9.6)是可以正常使用的。因此说明是由于最新版本添加的相关代码,导致了友盟 SDK 的分享出错问题。

经过上面 3 个方面检查后,最终确定了是由于最新版本引入的代码,导致友盟分享失败问题。由于最新版本的确没有改动过和友盟相关的代码,所以只能通过二分法来缩小代码访问,最终,确定了是由于最新版本引入的一个内部性能监控库,导致友盟分享功能失效。在详细定位性能监控库中的功能,最后发现,是 性能监控库 中统计 App 启动时所有 +load 方法耗时的代码,导致了友盟分享失效。

根因查找

紧接着,悄咪咪的查找小怪物的弱点,追求一招致胜。这样普通人才会觉得你很帅,毕竟帅是一辈子的事情。

经过缩小代码的修改范围,最终确定了是统计+load 方法耗时的相关代码,导致友盟分享失效。到了这里,其实还是非常的疑惑,因为这 2 部分的代码,基本是没啥关系的,为啥会相互影响呢。询问了之前负责这部分代码的相关同事,了解到统计+load 方法耗时的实现,是参考了计算 +load 方法的耗时 。详细的实现方式可以链接,大概的实现思路如下:

在所有的动态库加载前, hook 所有类的 +load 方法,然后在 +hookLoad 方法的前后,插入相关的时间统计方法。最后将所有 +load 方法的耗时累加得到总时间。

由于是 hook 了项目中所有的 +load 方法,那就只能猜测,是不是友盟 SDK 内部有相关的类也实现了 +load 方法,并且在方法中做了某些处理?。依照这个思路,做了一下的操作。

  • 查看友盟 SDK 是否有实现 +load 方法,是哪个类实现了 +load 方法。

在 hook +load 方法 的相关代码中,将进行 hook 的类都打印出来,由于友盟 SDK 中的类名都是以 UM 作为前缀,所以很好辨认,最终发现了以下相关类实现了 +load 方法

image.png

  • 是否是由于 hook 友盟的 +load 方法,导致原有友盟内部的 +load 方法没有被执行到,最终导致了分享异常

如何判断友盟的原有的 +load 方法有没有被执行呢?以 [UMSocialManager load] 方法为例,在 Xcode 上添加一个相关Symbolic Breakpoint 断点,然后重新运行查看断点的执行情况,结果如下图所示:

image.png

可以发现 [UMSocialManager load] 断点是可以被断点到的,相关的汇编代码也是有被执行的。而且从左边的调用堆栈中,可以发现 [UMSocialManager load] 方法是被我们 hookLoad 方法所调用的。因此可以判断,友盟中原有的 +load 方法,是有被执行的(其他几个类,我也一一校验过了)。

  • 是否是 hook 友盟的 +load 方法,导致原有的 +load 方法中的相关代码执行逻辑出现差异,最终导致友盟分享失败。

上一步验证友盟的 +load 方法是否已经被执行时,已经初略的浏览了各个方法的实现,涉及到的相关汇编命令都不多,比较好阅读。通过断点一步步调试,对比 hook 前后 +load 方法执行的逻辑,最终发现了不一致的地方。如下图所示:

image.png
image.png

从上面的 2 张图片,我们可以很轻易的看了差别。那么,为什么寄存器 x19 的值会前后不一致呢?寄存器 x0 和 x19 中的值分别代表了什么?我们分析 <+40> cmp x0, x19 之前的指令,就可以很容易的就得出结论:

  1. 寄存器 x19 里面存储的是一个self,在 <+16>: mov x19, x0 时被赋值
  2. 寄存器 x0 里面存储的是 [UMSocialHandler class] 方法的返回结果,相关的汇编指令是 <+24> <+32> <+36>

因此可以判断出,这里要执行的逻辑是判断 self == [UMSocialHandler class],那么,为什么 hook 前 self 指向的值是 UMSocialQQHandler 而 hook 后指向的确是 UMSocialHandler。通过左边的调用堆栈,我们可以发现此时的 [UMSocialHandler load] 并不是系统默认的调用行为而执行,而是子类 UMSocialQQHandler 通过 [super load] 调用而执行。如下图所示:

image.png

由于是通过 super 进行调用,所以在父类的 +load 方法中,self 指向的是 UMSocialQQHandler 而不是 UMSocialHandler,具体细节可以参考iOS:关于super 关键字(使用runtime分析)。那为啥 hook +load 方法后,self 指向的是UMSocialHandler呢,这就得详细查看了下相关代码,如下所示:


static void swizzleLoadMethod(Class cls, Method method, LMLoadInfo *info) {
retry:
    do {
        SEL hookSel = getRandomLoadSelector();
        Class metaCls = object_getClass(cls);
        IMP hookImp = imp_implementationWithBlock(^(){
            info->_start = CFAbsoluteTimeGetCurrent();
            ((void (*)(Class, SEL))objc_msgSend)(cls, hookSel);
            info->_end = CFAbsoluteTimeGetCurrent();
            if (!--LMAllLoadNumber) printLoadInfoWappers();
        });
        
        BOOL didAddMethod = class_addMethod(metaCls, hookSel, hookImp, method_getTypeEncoding(method));
        if (!didAddMethod) goto retry;
        
        info->_nSEL = hookSel;
        Method hookMethod = class_getInstanceMethod(metaCls, hookSel);
        method_exchangeImplementations(method, hookMethod);
    } while(0);
}

关键代码是 imp_implementationWithBlock 参数中的 ((void (*)(Class, SEL))objc_msgSend)(cls, hookSel);,可以看到 objc_msgSend 的第一参数,也就是最终在 +load 方法中获取到的 self 的值,是被写死成了被 hook 的类。举个例子,在 hook UMSocialHandler+load 方法时,cls 指向的是 UMSocialHandler,而 cls 被赋值给了 objc_msgSend 的第一个参数,所以在 UMSocialHandler 中的 self 永远都是指向 UMSocialHandler。这也是导致分享失效的根本原因,由于 self 永远都是指向 UMSocialHandler,所以导致了 UMSocialHandler+load 中的一部分逻辑永远不会被执行到,最终导致了分享平台初始化失败,也就是盟友日志打印的相关错误提示。

解决方案

最后,拿出我珍藏多年的宝剑,轻轻一捅。事了拂衣去,不带走一片云彩。

找到问题,解决方案就不难想出。问题的根因,是由于 hook 导致的 self 指向错误。因此,只要将原有的self重新赋值回去就可以解决了,相关代码如下:

static void swizzleLoadMethod(Class cls, Method method, LMLoadInfo *info) {
retry:
    do {
        SEL hookSel = getRandomLoadSelector();
        Class metaCls = object_getClass(cls);
        IMP hookImp = imp_implementationWithBlock(^(id originSelf){
            info->_start = CFAbsoluteTimeGetCurrent();
            ((void (*)(Class, SEL))objc_msgSend)(originSelf, hookSel);
            info->_end = CFAbsoluteTimeGetCurrent();
            if (!--LMAllLoadNumber) printLoadInfoWappers()`;
        });
        
        BOOL didAddMethod = class_addMethod(metaCls, hookSel, hookImp, method_getTypeEncoding(method));
        if (!didAddMethod) goto retry;
        
        info->_nSEL = hookSel;
        Method hookMethod = class_getInstanceMethod(metaCls, hookSel);
        method_exchangeImplementations(method, hookMethod);
    } while(0);
}

可以看到,修改的内容真的非常的少,就是取出 hookBlock 的第一个参数,然后赋值给 objc_msgSend的第一个参数,就可以完美解决。

参考资料

计算 +load 方法的耗时iOS:关于super 关键字(使用runtime分析)