Open GL 渲染存在的问题和解决方案-2

屏幕卡顿

屏幕卡顿是指图形图像的在显示时出现了撕裂（即图片错位显示）、掉帧（重复显示同一帧数据）等问题，导致用户能直观的从屏幕上看到的一种异常现象
为什么会出现这种情况呢？下面就来详细解说下屏幕卡顿

屏幕卡顿原因

主要以下三种原因

• CPU和GPU在渲染的流水线中耗时过长，导致从缓存区获取位图显示时，下一帧的数据还没有准备好，获取的仍是上一帧的数据，产生掉帧现象，掉帧就会导致屏幕卡顿
• 苹果官方针对屏幕撕裂问题，目前一直使用的方案是垂直同步+双缓存区，可以从根本上防止和解决屏幕撕裂，但是同时也导致了新的问题掉帧。虽然我们采用了双缓存区，但是我们并不能解决CPU和GPU处理图形图像的速度问题，导致屏幕在接收到垂直信号时，数据尚未准备好，缓存区仍是上一帧的数据，因此导致掉帧
• 在垂直同步+双缓存区的方案上，再次进行优化，将双缓存区，改为三缓存区，这样其实也并不能从根本上解决掉帧的问题，只是比双缓存区掉帧的概率小了很多，仍有掉帧的可能性，对于用户而言，可能是无感知的。
  详解解释一下屏幕撕裂问题
  我们看一下下面这张图是典型的撕裂问题造成的

image.png

在讲屏幕撕裂之前，首先说说屏幕是如何成像的，主要的流程是什么
屏幕成像过程
请看下面这张图，详细说明了屏幕成像的一个流程

image.png

• 将需要显示的图像，经由GPU渲染
• 将渲染后的结果，存储到帧缓存区，帧缓存区中存储的格式是位图
• 由视频控制器从帧缓存区中读取位图，交由显示器，从左上角逐行扫描进行显示
  屏幕撕裂原因
• 在屏幕显示图形图像的过程中，是不断从帧缓存区获取一帧一帧数据进行显示的，然后在渲染的过程中，帧缓存区中仍是旧的数据，屏幕拿到旧的数据去进行显示，在旧的数据没有读取完时 ，新的一帧数据处理好了，放入了缓存区，这时就会导致屏幕另一部分的显示是获取的新数据，从而导致屏幕上呈现图片不匹配，人物、景象等错位显示的情况。
  本人一开始对帧的概念不是很理解，下面对帧和帧缓存做一下解释

  • 在放映电影的过程中，画面被一幅幅地放映在银幕上。画幅移开时，光线就被遮住，幕上便出现短暂的黑暗；每放映一个画幅后，幕上就黑暗一次。但这一次次极短暂的黑暗，被人的视觉生理现象“视觉暂留”所弥补。人眼在观察景物时，光信号传入大脑神经需经过一段短暂时间，光的作用结束时，视觉也不立即消失。视觉的这一现象称为“视觉暂留”。当电影画面换幅频率达到每秒15幅~30幅时，观众便见不到黑暗的间隔了，这时人“看到”的就是运动的事物，这就是电影的基本原理。这里的一幅画面就是电影的一帧，实际上就是电影胶片中的一格。

  • 帧——就是影像动画中最小单位的单幅影像画面。 一帧就是一副静止的画面，连续的帧就形成动画，如电视图象等。 通常说帧数，简单地说，就是在1秒钟时间里传输的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次，通常用FPS（Frames Per Second）表示。每一帧都是静止的图象，快速连续地显示帧便形成了运动的假象。高的帧率可以得到更流畅、更逼真的动画。每秒钟帧数 (fps) 越多，所显示的动作就会越流畅。

  • 帧缓冲存储器(Frame Buffer)：简称帧缓存或显存，它是屏幕所显示画面的一个直接映象，又称为位映射图(Bit Map)或光栅。帧缓存的每一存储单元对应屏幕上的一个像素，整个帧缓存对应一帧图像。
    

    image.png

苹果官方解决撕裂问题方案

苹果官方针对屏幕撕裂现象，目前一直采用的是垂直同步+双缓存，该方案是强制要求同步，且是以掉帧为代价的。

以下是垂直同步+双缓存的一个图解过程

image.png

• 垂直同步：是指给帧缓冲加锁，当电子光束扫描的过程中，只有扫描完成了才会读取下一帧的数据，而不是只读取一部分
• 双缓冲区：采用两个帧缓冲区用途GPU处理结果的存储，当屏幕显示其中一个缓存区内容时，另一个缓冲区继续等待下一个缓冲结果，两个缓冲区依次进行交替

掉帧

采用苹果的双缓冲区方案后，又会出现新的问题，掉帧。
什么是掉帧？简单来说就是 屏幕重复显示同一帧数据的情况就是掉帧

如图所示：当前屏幕显示的是A，在收到垂直信号后，CPU和GPU处理的B还没有准备好，此时，屏幕显示的仍然是A

image.png

• 针对掉帧情况，我们可以在苹果方案的基础上进行优化，即采用三缓存区，意味着，在屏幕显示时，后面还准备了3个数据用于显示，但是这只能减少掉帧情况仍然无法从根本上解决掉帧问题。

iOS 中渲染流程

在iOS中渲染的整体流程如下所示

image.png

• App通过调用CoreGraphics、CoreAnimation、CoreImage等框架的接口触发图形渲染操作，CoreGraphics、CoreAnimation、CoreImage等框架将渲染交由OpenGL ES，OpenGL ES来驱动GPU做渲染，最后显示到屏幕上，由于OpenGL ES 是跨平台的，所以在他的实现中，是不能有任何窗口相关的代码，而是让各自的平台为OpenGL ES提供载体。在ios中，如果需要使用OpenGL ES，就是通过CoreAnimation提供窗口，让App可以去调用。

iOS中渲染框架总结

主要由以下六种框架

image.png

View 与 CALayer 的关系

首先分别简单说下UIView和CALayer各自的作用

• UIView

  • UIView属于UIKIt
  • 负责绘制图形和动画操作
  • 用于界面布局和子视图的管理
  • 处理用户的点击事件

• CALayer

  • CALayer属于CoreAnimation
  • 只负责显示，且显示的是位图
  • CALayer既用于UIKit，也用于APPKit，
    ==> UIKit是iOS平台的渲染框架，APPKit是Mac OSX系统下的渲染框架，
    ==> 由于iOS和Mac两个系统的界面布局并不是一致的，iOS是基于多点触控的交互方式，而Mac OSX是基于鼠标键盘的交互方式，且分别在对应的框架中做了布局的操作，所以并不需要layer载体去布局，且不用迎合任何布局方式。

UIView和CALayer的关系

• UIView基于UIKit框架，可以处理用户触摸事件，并管理子视图
• CALayer基于CoreAnimation，而CoreAnimation是基于QuartzCode的。所以CALayer只负责显示，不能处理用户的触摸事件
• 从父类来说，CALayer继承的是NSObject，而UIView是直接继承自UIResponder的，所以UIVIew相比CALayer而言，只是多了事件处理功能，
• 从底层来说，UIView属于UIKit的组件，而UIKit的组件到最后都会被分解成layer，存储到图层树中
• 在应用层面来说，需要与用户交互时，使用UIView，不需要交互时，使用两者都可以

UIView和CALayer的渲染

下图可以说明view 和 layer之间是如何渲染的

image.png

界面触发的方式有两种

• ==> 通过loadView中子View的drawRect方法触发：会回调CoreAnimation中监听Runloop的BeforeWaiting的RunloopObserver，通过RunloopObserver来进一步调用CoreAnimation内部的CA::Transaction::commit()，进而一步步走到drawRect方法
  ==> 用户点击事件触发：唤醒Runloop，由source1处理(__IOHIDEventSystemClientQueueCallback)，并且在下一个runloop里由source0转发给UIApplication(_UIApplicationHandleEventQueue)，从而能通过source0里的事件队列来调用CoreAnimation内部的CA::Transaction::commit();方法，进而一步一步的调用drawRect。
  最终都会走到CoreAnimation中的CA::Transaction::commit()方法，从而来触发UIView和CALayer的渲染,这时，已经到了CoreAnimation的内部，即调用CA::Transaction::commit();来创建CATrasaction，然后进一步调用 CALayer drawInContext:()回调CALayer的Delegate(UIView)，问UIView没有需要画的内容，即回调到drawRect:方法在drawRect:方法里可以通过CoreGraphics函数或UIKit中对CoreGraphics封装的方法进行画图操作将绘制好的位图交由CALayer，由OpenGL ES 传送到GPU的帧缓冲区,等屏幕接收到垂直信号后，就读取帧缓冲区的数据，显示到屏幕上

CoreAnimation

在苹果官方的描述中，Render、Compose，and animate visual elements，CoreAnimationg中的动画只是一部分，它其实是一个复合引擎，主要的职责包括 渲染、构建和动画实现。

ios中CoreAnimation如图所示

image.png

• ios中基于CoreAnimation构建的框架有两个：UIKit和APPKit
• CoreAnimation 又是基于Metal 、CoreGraphics封装的
  苹果为什么要基于UIView和CALayer提供两个平行的层级关系（UIKit 和APPKit）？
  • 职责分离，可以避免大量重复代码
  • 两个系统交互规则不一致，虽然功能上类似，但实现上有显著区别

CoreAnimation中的渲染流水线

CoreAnimation中渲染的流程如图所示

image.png

主要分为两部分：

• CoreAnimation部分
• GPU部分
  CoreAnimation部分
• App处理UIView、UIButton等载体的事件，然后通过CPU完成对显示内容的计算，并将计算后的图层进行打包，在下一次runloop时，发送到渲染服务器
• Render Server中主要对收到的准备显示的内容进行解码，然后执行OpenGL等相关程序，并调用GPU进行渲染
  ==> Render Server 操作分析
  
  image.png
  
  GPU部分
• GPU中通过顶点着色器、片元着色器完成对显示内容的渲染，将结果存入帧缓存区
• GPU通过帧缓存区、视频控制器等相关部件，将其显示到屏幕上

总结

屏幕撕裂问题和掉帧问题根本的原因是CPU和GPU的计算能力跟不上帧的刷新率(60FPS)才会有可能发生撕裂或者掉帧，在iOS的设备上经过苹果的垂直同步信号+双缓冲区的解决方案后很少看到撕裂，除非是在旧的设备（例如iphone4s）或运行对画质要求特别高的游戏或复杂动画有可能会出现撕裂，掉帧也是同样的道理。iOS 绘制普通的UIView、UIImageView等是不会出现撕裂或掉帧的。虽然苹果的解决方案没有从根本上解决存在的问题，但是我们的实际体验中撕裂和掉帧问题并不常见。