从之前我们的分析历程（iOS13卡顿问题分析（一）CPU on instruments、iOS13卡顿问题分析（二）避免竞争）来看，可以将各种三方SDK排除到退到后台处理瞬间以外了。但是上线后的数据来看，下降的不是特别多，大盘数据下降不到0.5%。
因此，我们接下来又将视点，集中到了以下两点：
-
iOS13和iOS13以前，在后台挂起策略上，究竟有什么差异？？？除了iOS13本身用户占比大，为什么iOS13退到后台的卡顿上报这么多？？？
-
卡顿的堆栈中，究竟触发了哪些操作？这些操作和什么有关？如果是和我们的业务相关，和哪些业务操作相关？？？
于是，分别从这两个问题出发，我们进行了以下的实验以及分析。
一、后台处理策略在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 <QuartzCore/CoreAnimation.h>#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
我们进行了页面的收集，得到了以下页面：
- 练习完成推荐页面
- 首页
- 练习完成反馈页面
- 本地视频播放页面
结合神策和Kibana的数据收集，和用户路径是一致的。可以看出，这些页面也基本上属于数据量较大，以及页面层级较重的。
四、总结
基于以上的结论。我们后续的工作安排如下：
-
首先拿出一个页面，重点做优化：
-
减少UI层级
-
可以使用layer构图的使用layer
-
减少不必要的动画，包括系统自带动画，和隐式动画
-
确认优化有效的情况下，进行系统的页面上报，根据影响人数或者次数排出页面顺序，逐个击破。
-
后续形成范式，在书写UI时直接进行优化。
网友评论