iOS-APP性能优化-卡顿优化

2020-04-27  本文已影响0人  sun_glory

一.CPU与GPU

在屏幕成像的过程中，CPU和GPU起着至关重要的作用

图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
优化GPU

离屏渲染

在OpenGL中，GPU有2种渲染方式

当前帧缓存不够用时，就会去新开辟缓冲区，就会导致离屏渲染。
离屏渲染消耗性能的原因:

哪些操作会触发离屏渲染？

卡顿检测

通过监控主线程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 秒。

如果想要获取卡顿的堆栈信息，可以直接调用系统函数，也可以借助第三方。

上一篇 下一篇

猜你喜欢

热点阅读