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

前言

前几天早上，当我准备高高兴兴，投入世界上最为幸福的事情 -- 打码时，收到了测试小姐姐的一个消息。在那一瞬间，我有了一种不妙的预估，打开消息一看，不出所料，果然是你， 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分析)