iOS13卡顿问题分析曲径归真

Posted 拖地先生

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS13卡顿问题分析曲径归真相关的知识,希望对你有一定的参考价值。

从之前我们的分析历程(、)来看,可以将各种三方SDK排除到退到后台处理瞬间以外了。但是上线后的数据来看,下降的不是特别多,大盘数据下降不到0.5%。

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

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


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

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

一、后台处理策略在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

我们进行了页面的收集,得到了以下页面:

  1. 练习完成推荐页面

  2. 首页

  3. 练习完成反馈页面

  4. 本地视频播放页面

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

四、总结

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

  1. 首先拿出一个页面,重点做优化:

    1. 减少UI层级

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

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

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

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



拖地先生,从事互联网技术工作,在这里每周两篇文章,聊聊日常的实践和心得。往期推荐:


如果对你有帮助,让大家也看看呗~

以上是关于iOS13卡顿问题分析曲径归真的主要内容,如果未能解决你的问题,请参考以下文章

在ios上滑动静态页面卡顿怎么解决

RunLoop总结:RunLoop的应用场景

返璞归真 - Oracle 9i的RBO执行计划案例

屏幕卡顿 及 iOS中OpenGL渲染架构分析

深入分析Android“卡顿掉帧”问题

overflow: scroll在iOS上滑动卡顿的问题