iOS13卡顿问题分析（三）曲径归真

从之前我们的分析历程（iOS13卡顿问题分析（一）CPU on instruments、iOS13卡顿问题分析（二）避免竞争）来看，可以将各种三方SDK排除到退到后台处理瞬间以外了。但是上线后的数据来看，下降的不是特别多，大盘数据下降不到0.5%。

因此，我们接下来又将视点，集中到了以下两点：

1. iOS13和iOS13以前，在后台挂起策略上，究竟有什么差异？？？除了iOS13本身用户占比大，为什么iOS13退到后台的卡顿上报这么多？？？

2. 卡顿的堆栈中，究竟触发了哪些操作？这些操作和什么有关？如果是和我们的业务相关，和哪些业务操作相关？？？

于是，分别从这两个问题出发，我们进行了以下的实验以及分析。

一、后台处理策略在iOS13上发生了哪些变化

分别在iOS12和iOS13上运行同一个App，然后在Instruments下观察其退到后台后的运行情况。

可以明显看出，在iOS12上，在程序处理900ms左右以后，程序会被立即挂起，程序内没来得及执行的方法会停止执行，以及在后台继续运行的定时器，则会被暂停。最长有1.5s的预留处理时间。

而在iOS13上，定时器会继续运行，我们尝试hook延迟运行的那些方法也不会被强制停止，一切和在前台时差别不大。

但是无论在iOS12还是iOS13，退到后台后的系统方法处理时间均在900ms左右。

可想而知，我们退到后台后如果继续运行我们的某些程序，如果和系统函数冲突了，则可能会产生卡顿。

二、上报的卡顿堆栈中，究竟触发了什么？

Image

目前我们Top1的堆栈表现如图。

可以看出，全部都是退到后台后触发的系统函数，并且根据Xcode断点情况，这些函数也几乎都是必经之路。

然后，为什么会触发这样的堆栈，而不是别的堆栈，其原因肯定在于我们的某些操作，影响了此条路径上的某一个地方。

从图中可以看出，最后卡顿在了QuartzCore库的CABackingStoreCollectBlocking函数上。

那么，什么是QuartzCore？

从其头文件可以看出

#ifndef QUARTZCORE_H#define QUARTZCORE_H#include #endif /* QUARTZCORE_H */

其只引入了CoreAnimation库，实际上，其就是CoreAnimation，负责动画的库。

那么，CABackingStoreCollectBlocking什么时候会触发？

从资料中，没有办法获取到，但是我们可以通过在Xcode中打断点，去列举情况。

已经知道其在CoreAnimation中，所以肯定和动画相关。（从它的函数名前缀CA也可以看出）

在Xcode中打断点实验的情况下，我们首先确定了，其和UITableView以及UICollectionView的reloadData相关。

实际上，此函数作用为，等待动画以及渲染结束，回收资源。

我们在Webkit中查到了相关函数：

> Source/WebCore/platform/mac/WebCoreSystemInterface.mm:195> +void(*wkCABackingStoreCollectBlocking)(void);

以此出发，我写了单独的Demo来还原堆栈。

经过Demo测试发现，在重页面，或者数据量较多的UITableView和UICollectionView中，退到后台一瞬间reloadData，或者先reloadData瞬间再退到后台时，都会产生同样的卡顿堆栈。

三、和我们哪些页面或者业务相关？

在经过以上测试复现之后，我们反观我们的工程代码，需要找出到底和哪里有关。

所以，我们选择hook了bugly的抓取堆栈函数，来进行卡顿收集一瞬间的页面收集，看看到底发生在哪些页面。

#import "Bugly+YG.h"#import "NSObjectSafe.h"#import "YGSDKMannager.h"#import "YGLuaFixManage.h"@implementation Bugly(YG)@end@interface BLYMainRunloopMonitorManager : NSObject@end@implementation BLYMainRunloopMonitorManager(YG)+ (void)initialize {    static dispatch_once_t onceToken;    dispatch_once(&onceToken, ^{        #ifndef DEBUG        if (@available(iOS 13.0, *)){            if([[YGLuaFixManage share]isOpenCollectBuglyLog]){                [self swizzleInstanceMethod:@selector(packageModelFromCrashReport:) withMethod:@selector(hookpackageModelFromCrashReport:)];                [self swizzleInstanceMethod:@selector(setRunloopTimeoutThreshold:) withMethod:@selector(hooksetRunloopTimeoutThreshold:)];            }        }        #else        //开发环境        if([[YGLuaFixManage share]isOpenCollectBuglyLog]){            [self swizzleInstanceMethod:@selector(packageModelFromCrashReport:) withMethod:@selector(hookpackageModelFromCrashReport:)];            [self swizzleInstanceMethod:@selector(setRunloopTimeoutThreshold:) withMethod:@selector(hooksetRunloopTimeoutThreshold:)];        }        #endif                    });}- (id)hookpackageModelFromCrashReport:(id)obj{    [[YGLuaFixManage share] uploadDetailLogic];    id ygvalue = [self hookpackageModelFromCrashReport:obj];    return ygvalue;}-(void)hooksetRunloopTimeoutThreshold:(id)obj{    [[YGLuaFixManage share] uploadDetailLogicDesc];    [self hooksetRunloopTimeoutThreshold:obj];}@end

我们进行了页面的收集，得到了以下页面：

1. 练习完成推荐页面

2. 首页

3. 练习完成反馈页面

4. 本地视频播放页面

结合神策和Kibana的数据收集，和用户路径是一致的。可以看出，这些页面也基本上属于数据量较大，以及页面层级较重的。

四、总结

基于以上的结论。我们后续的工作安排如下：

1. 首先拿出一个页面，重点做优化：

2. 减少UI层级

3. 可以使用layer构图的使用layer

4. 减少不必要的动画，包括系统自带动画，和隐式动画

5. 确认优化有效的情况下，进行系统的页面上报，根据影响人数或者次数排出页面顺序，逐个击破。

6. 后续形成范式，在书写UI时直接进行优化。