一.CPU与GPU
在屏幕成像的过程中，CPU和GPU起着至关重要的作用
-
CPU（Central Processing Unit，中央处理器）
对象的创建和销毁、对象属性的调整、布局计算、文本的计算和排版、图片的格式转换和解码、图像的绘制（Core Graphics）
-
GPU（Graphics Processing Unit，图形处理器）
纹理的渲染
图1
1.CPU直接处理出来的数据是无法显示到屏幕上的，GPU可以将CPU计算好的数据显示在屏幕上。
2.在iOS中是双缓冲机制，有前帧缓存、后帧缓存。这就表示帧缓存可以有两块缓存区间，能有效提高运行效率。
二.屏幕成像原理
屏幕快照 2020-04-27 下午3.47.11.png
屏幕成像都是由一帧一帧的画面组合形成的。
在要显示一帧画面之前，会先发出一个垂直同步信号VSync，表示即将显示一帧画面。接下来会发出第一个水平同步信号HSync，填充当前屏幕的第一行数据，一直发出n个水平同步信号HSync，填充完当前屏幕，当前帧就填充完毕。接着发出下一个垂直同步信号VSync...... 这样当所有帧的数据连起来展示的时候，就能在屏幕上比较流畅的展示了。
卡顿产生的原因
现在我们了解了图像是怎么显示到屏幕上的了。首先需要CPU把需要显示的数据计算好，再交由GPU渲染到屏幕上，如下图所示：
屏幕快照 2020-04-27 下午4.04.35.png
箭头线段的长短表示CPU与GPU的耗时时长。
1.当第一个垂直同步信号VSync发出时，CPU与GPU刚好把第一帧绘制完，这里不会产生卡顿。
2.当第二个垂直同步信号VSync发出时，CPU与GPU已经把第二帧绘制完，这里不会产生卡顿。
3.当第三个垂直同步信号VSync发出时，GPU耗时过长，第三帧还没绘制完，此时只能显示上一帧的画面，这里产生了卡顿。
4.第三帧未显示出来的画面，只能等到下一个垂直同步信号VSync到来时在展示。
按照60FPS来计算的话，为了不产生卡顿，每16ms就会发出一个垂直同步信号VSync，如果对于每一帧的处理时间，CPU与GPU的耗时时长都能小于16ms，就不会体验到卡顿的现象。
由此可见，卡顿产生的主要原因就是CPU与GPU的耗时时长。
卡顿优化
优化CPU
- 尽量用轻量级的对象，比如用不到事件处理的地方，可以考虑使用CALayer取代UIView
- 不要频繁地调用UIView的相关属性，比如frame、bounds、transform等属性，尽量减少不必要的修改
- 尽量提前计算好布局，在有需要时一次性调整对应的属性，不要多次修改属性
- Autolayout会比直接设置frame消耗更多的CPU资源
- 图片的size最好刚好跟UIImageView的size保持一致
- 控制一下线程的最大并发数量
- 尽量把耗时的操作放到子线程
1.文本处理（尺寸计算、绘制）
2.图片处理（解码、绘制）
优化GPU
- 尽量避免短时间内大量图片的显示，尽可能将多张图片合成一张进行显示
- GPU能处理的最大纹理尺寸是
4096x4096，一旦超过这个尺寸，就会占用CPU资源进行处理，所以纹理尽量不要超过这个尺寸 - 尽量减少视图数量和层次
- 减少透明的视图（alpha<1），不透明的就设置opaque为YES(透明视图需要计算透明区域的色值)
- 尽量避免出现离屏渲染
离屏渲染
在OpenGL中，GPU有2种渲染方式
- On-Screen Rendering
当前屏幕渲染，在当前用于显示的屏幕缓冲区进行渲染操作。GPU会将渲染好的数据显示到帧缓存中，在这个帧缓存中进行的渲染就是当前屏幕渲染。 - Off-Screen Rendering
离屏渲染，在当前屏幕缓冲区以外新开辟一个缓冲区进行渲染操作，这一块的缓冲区的内容并不是直接显示到屏幕上的。
当前帧缓存不够用时，就会去新开辟缓冲区，就会导致离屏渲染。
离屏渲染消耗性能的原因:
- 需要创建新的缓冲区
- 离屏渲染的整个过程，需要多次切换上下文环境，先是从当前屏幕（On-Screen）切换到离屏（Off-Screen）；等到离屏渲染结束以后，将离屏缓冲区的渲染结果显示到屏幕上，又需要将上下文环境从离屏切换到当前屏幕
哪些操作会触发离屏渲染？
- 光栅化，
layer.shouldRasterize = YES - 圆角，同时设置
layer.masksToBounds = YES、layer.cornerRadius>0
解决思路：考虑通过CoreGraphics绘制裁剪圆角，或者叫美工提供圆角图片 - 阴影，
layer.shadowXXX
解决思路：如果设置了layer.shadowPath就不会产生离屏渲染
卡顿检测
通过监控主线程Runloop的状态，来判断是否产生了卡顿。
通过对 RunLoop原理的分析，我们可以看出在整个过程中，loop 的状态包括 6 个，其代码定义如下：
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry , // 进入 loop
kCFRunLoopBeforeTimers , // 触发 Timer 回调
kCFRunLoopBeforeSources , // 触发 Source0 回调
kCFRunLoopBeforeWaiting , // 等待 mach_port 消息
kCFRunLoopAfterWaiting ), // 接收 mach_port 消息
kCFRunLoopExit , // 退出 loop
kCFRunLoopAllActivities // loop 所有状态改变
}
如果 RunLoop 的线程，进入睡眠前方法的执行时间过长而导致无法进入睡眠，或者线程唤醒后接收消息时间过长而无法进入下一步的话，就可以认为是线程受阻了。如果这个线程是主线程的话，表现出来的就是出现了卡顿。所以，如果我们要利用 RunLoop 原理来监控卡顿的话，就是要关注这两个阶段。RunLoop 在进入睡眠之前和唤醒后的两个 loop 状态定义的值，分别是 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting ，也就是要触发 Source0 回调和接收 mach_port 消息两个状态。
要想监听 RunLoop，你就首先需要创建一个 CFRunLoopObserverContext 观察者，代码如下：
CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
runLoopObserver = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES,0,&runLoopObserverCallBack,&context);
将创建好的观察者 runLoopObserver 添加到主线程 RunLoop 的 common 模式下观察。然后，创建一个持续的子线程专门用来监控主线程的 RunLoop 状态。一旦发现进入睡眠前的 kCFRunLoopBeforeSources 状态，或者唤醒后的状态 kCFRunLoopAfterWaiting，在设置的时间阈值内一直没有变化，即可判定为卡顿。接下来，我们就可以打印出堆栈的信息，从而进一步分析出具体是哪个方法的执行时间过长。
开启一个子线程监控的代码如下：
//创建子线程监控
dispatch_async(dispatch_get_global_queue(0, 0), ^{
//子线程开启一个持续的 loop 用来进行监控
while (YES) {
long semaphoreWait = dispatch_semaphore_wait(dispatchSemaphore, dispatch_time(DISPATCH_TIME_NOW, 3 * NSEC_PER_SEC));
if (semaphoreWait != 0) {
if (!runLoopObserver) {
timeoutCount = 0;
dispatchSemaphore = 0;
runLoopActivity = 0;
return;
}
//BeforeSources 和 AfterWaiting 这两个状态能够检测到是否卡顿
if (runLoopActivity == kCFRunLoopBeforeSources || runLoopActivity == kCFRunLoopAfterWaiting) {
//将堆栈信息上报服务器的代码放到这里
} //end activity
}// end semaphore wait
timeoutCount = 0;
}// end while
});
代码中的 NSEC_PER_SEC，代表的是触发卡顿的时间阈值，单位是秒。可以看到，我们把这个阈值设置成了 3 秒。
如果想要获取卡顿的堆栈信息，可以直接调用系统函数，也可以借助第三方。
网友评论