iOS13卡顿问题分析曲径归真
Posted 拖地先生
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS13卡顿问题分析曲径归真相关的知识,希望对你有一定的参考价值。
从之前我们的分析历程(、)来看,可以将各种三方SDK排除到退到后台处理瞬间以外了。但是上线后的数据来看,下降的不是特别多,大盘数据下降不到0.5%。
因此,我们接下来又将视点,集中到了以下两点:
ios13和iOS13以前,在后台挂起策略上,究竟有什么差异???除了iOS13本身用户占比大,为什么iOS13退到后台的卡顿上报这么多???
卡顿的堆栈中,究竟触发了哪些操作?这些操作和什么有关?如果是和我们的业务相关,和哪些业务操作相关???
于是,分别从这两个问题出发,我们进行了以下的实验以及分析。
一、后台处理策略在iOS13上发生了哪些变化
分别在iOS12和iOS13上运行同一个App,然后在Instruments下观察其退到后台后的运行情况。
可以明显看出,在iOS12上,在程序处理900ms左右以后,程序会被立即挂起,程序内没来得及执行的方法会停止执行,以及在后台继续运行的定时器,则会被暂停。最长有1.5s的预留处理时间。
而在iOS13上,定时器会继续运行,我们尝试hook延迟运行的那些方法也不会被强制停止,一切和在前台时差别不大。
但是无论在iOS12还是iOS13,退到后台后的系统方法处理时间均在900ms左右。
可想而知,我们退到后台后如果继续运行我们的某些程序,如果和系统函数冲突了,则可能会产生卡顿。
二、上报的卡顿堆栈中,究竟触发了什么?
目前我们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时直接进行优化。
拖地先生,从事互联网技术工作,在这里每周两篇文章,聊聊日常的实践和心得。往期推荐:
如果对你有帮助,让大家也看看呗~
以上是关于iOS13卡顿问题分析曲径归真的主要内容,如果未能解决你的问题,请参考以下文章