好长时间没有更新了，今天来谈谈关于界面卡顿的原理以及优化的方案
界面卡顿
通常来说，计算机中的显示过程是下面这样的，通过CPU、GPU、显示器协同工作来将图片显示到屏幕上
1、CPU计算好显示内容，提交至GPU
2、GPU经过渲染完成后将渲染的结果放入
FrameBuffer（帧缓存区）3、随后
视频控制器会按照VSync信号逐行读取FrameBuffer的数据4、经过可能的数模转换传递给显示器进行显示
最开始时，FrameBuffer只有一个，这种情况下FrameBuffer的读取和刷新有很大的效率问题，为了解决这个问题，引入了双缓存区。即双缓冲机制。在这种情况下，GPU会预先渲染好一帧放入FrameBuffer，让视频控制器读取，当下一帧渲染好后，GPU会直接将视频控制器的指针指向第二个FrameBuffer。
双缓存机制虽然解决了效率问题，但是随之而言的是新的问题，当视频控制器还未读取完成时，例如屏幕内容刚显示一半，GPU将新的一帧内容提交到FrameBuffer，并将两个FrameBuffer而进行交换后，视频控制器就会将新的一帧数据的下半段显示到屏幕上，造成屏幕撕裂现象
为了解决这个问题，采用了垂直同步信号机制。当开启垂直同步后，GPU会等待显示器的VSync信号发出后，才进行新的一帧渲染和FrameBuffer更新。而目前iOS设备中采用的正是双缓存区+VSync
屏幕卡顿原因
下面我们来说说，屏幕卡顿的原因
在 VSync信号到来后，系统图形服务会通过 CADisplayLink 等机制通知 App，App 主线程开始在CPU中计算显示内容。随后 CPU 会将计算好的内容提交到 GPU 去，由GPU进行变换、合成、渲染。随后 GPU 会把渲染结果提交到帧缓冲区去，等待下一次 VSync 信号到来时显示到屏幕上。由于垂直同步的机制，如果在一个 VSync 时间内，CPU 或者 GPU 没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而这时显示屏会保留之前的内容不变。所以可以简单理解掉帧
如下图所示，是一个显示过程，第1帧在VSync到来前，处理完成，正常显示，第2帧在VSync到来后，仍在处理中，此时屏幕不刷新，依旧显示第1帧，此时就出现了掉帧情况，渲染时就会出现明显的卡顿现象
从图中可以看出，CPU和GPU不论是哪个阻碍了显示流程，都会造成掉帧现象，所以为了给用户提供更好的体验，在开发中，我们需要进行卡顿检测以及相应的优化
卡顿监控
卡顿监控的方案一般有两种：
FPS监控：为了保持流程的UI交互，App的刷新拼搏应该保持在60fps左右， 其原因是因为iOS设备默认的刷新频率是60次/秒，现在苹果13已引入了高刷120fps120次/秒某种程度上减少了卡顿，而目前大多设备1次刷新（即VSync信号发出）的间隔是1000ms/60 = 16.67ms，所以如果在16.67ms内没有准备好下一帧数据，就会产生卡顿主线程卡顿监控：通过子线程监测主线程的RunLoop，判断两个状态（kCFRunLoopBeforeSources和kCFRunLoopAfterWaiting）之间的耗时是否达到一定阈值
FPS监控
FPS的监控，参照YYKit中的YYFPSLabel，主要是通过CADisplayLink实现。借助link的时间差，来计算一次刷新刷新所需的时间，然后通过 刷新次数 / 时间差 得到刷新频次，并判断是否其范围，通过显示不同的文字颜色来表示卡顿严重程度。代码实现如下：
class CJLFPSLabel: UILabel {
fileprivate var link: CADisplayLink = {
let link = CADisplayLink.init()
return link
}()
fileprivate var count: Int = 0
fileprivate var lastTime: TimeInterval = 0.0
fileprivate var fpsColor: UIColor = {
return UIColor.green
}()
fileprivate var fps: Double = 0.0
override init(frame: CGRect) {
var f = frame
if f.size == CGSize.zero {
f.size = CGSize(width: 80.0, height: 22.0)
}
super.init(frame: f)
self.textColor = UIColor.white
self.textAlignment = .center
self.font = UIFont.init(name: "Menlo", size: 12)
self.backgroundColor = UIColor.lightGray
//通过虚拟类
link = CADisplayLink.init(target: CJLWeakProxy(target:self), selector: #selector(tick(_:)))
link.add(to: RunLoop.current, forMode: RunLoop.Mode.common)
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
deinit {
link.invalidate()
}
@objc func tick(_ link: CADisplayLink){
guard lastTime != 0 else {
lastTime = link.timestamp
return
}
count += 1
//时间差
let detla = link.timestamp - lastTime
guard detla >= 1.0 else {
return
}
lastTime = link.timestamp
//刷新次数 / 时间差 = 刷新频次
fps = Double(count) / detla
let fpsText = "\(String.init(format: "%.2f", fps)) FPS"
count = 0
let attrMStr = NSMutableAttributedString(attributedString: NSAttributedString(string: fpsText))
if fps > 55.0 {
//流畅
fpsColor = UIColor.green
}else if (fps >= 50.0 && fps <= 55.0){
//一般
fpsColor = UIColor.yellow
}else{
//卡顿
fpsColor = UIColor.red
}
attrMStr.setAttributes([NSAttributedString.Key.foregroundColor: fpsColor], range: NSMakeRange(0, attrMStr.length - 3))
attrMStr.setAttributes([NSAttributedString.Key.foregroundColor: UIColor.white], range: NSMakeRange(attrMStr.length - 3, 3))
DispatchQueue.main.async {
self.attributedText = attrMStr
}
}
}
如果只是简单的监测，使用FPS足够了。
主线程卡顿监控
除了FPS，还可以通过RunLoop来监控，因为卡顿的是事务，而事务是交由主线程的RunLoop处理的。
实现思路：检测主线程每次执行消息循环的时间，当这个时间大于规定的阈值时，就记为发生了一次卡顿。这个也是微信卡顿三方matrix的原理
以下是一个简易版RunLoop监控的实现
import UIKit
class CJLBlockMonitor: NSObject {
static let share = CJLBlockMonitor.init()
fileprivate var semaphore: DispatchSemaphore!
fileprivate var timeoutCount: Int!
fileprivate var activity: CFRunLoopActivity!
private override init() {
super.init()
}
public func start(){
//监控两个状态
registerObserver()
//启动监控
startMonitor()
}
}
fileprivate extension CJLBlockMonitor{
func registerObserver(){
let controllerPointer = Unmanaged.passUnretained(self).toOpaque()
var context: CFRunLoopObserverContext = CFRunLoopObserverContext(version: 0, info: controllerPointer, retain: nil, release: nil, copyDescription: nil)
let observer: CFRunLoopObserver = CFRunLoopObserverCreate(nil, CFRunLoopActivity.allActivities.rawValue, true, 0, { (observer, activity, info) in
guard info != nil else{
return
}
let monitor: CJLBlockMonitor = Unmanaged.fromOpaque(info!).takeUnretainedValue()
monitor.activity = activity
let sem: DispatchSemaphore = monitor.semaphore
sem.signal()
}, &context)
CFRunLoopAddObserver(CFRunLoopGetMain(), observer, CFRunLoopMode.commonModes)
}
func startMonitor(){
//创建信号
semaphore = DispatchSemaphore(value: 0)
//在子线程监控时长
DispatchQueue.global().async {
while(true){
// 超时时间是 1 秒，没有等到信号量，st 就不等于 0， RunLoop 所有的任务
let st = self.semaphore.wait(timeout: DispatchTime.now()+1.0)
if st != DispatchTimeoutResult.success {
//监听两种状态kCFRunLoopBeforeSources 、kCFRunLoopAfterWaiting，
if self.activity == CFRunLoopActivity.beforeSources || self.activity == CFRunLoopActivity.afterWaiting {
self.timeoutCount += 1
if self.timeoutCount < 2 {
print("timeOutCount = \(self.timeoutCount)")
continue
}
// 一秒左右的衡量尺度 很大可能性连续来 避免大规模打印!
print("检测到超过两次连续卡顿")
}
}
self.timeoutCount = 0
}
}
}
}
使用时，直接调用即可
CJLBlockMonitor.share.start()
也可以直接使用三方库
Swift的卡顿检测第三方ANREye，其主要思路是：创建子线程进行循环监测，每次检测时设置标记置为true，然后派发任务到主线程，标记置为false，接着子线程睡眠超过阈值时，判断标记是否为false，如果没有，说明主线程发生了卡顿OC可以使用 微信matrix、滴滴DoraemonKit
界面优化
CPU层面的优化
1、尽量
用轻量级的对象代替重量级的对象，可以对性能有所优化，例如 不需要相应触摸事件的控件，用CALayer代替UIView-
2、尽量减少对
UIView和CALayer的属性修改CALayer内部并没有属性，当调用属性方法时，其内部是通过运行时
resolveInstanceMethod为对象临时添加一个方法，并将对应属性值保存在内部的一个Dictionary中，同时还会通知delegate、创建动画等，非常耗时UIView相关的显示属性，例如frame、bounds、transform等，实际上都是从CALayer映射来的，对其进行调整时，消耗的资源比一般属性要大
3、当有大量对象释放时，也是非常耗时的，尽量挪到后台线程去释放
4、尽量
提前计算视图布局，即预排版，例如cell的行高5、
Autolayout在简单页面情况下们可以很好的提升开发效率，但是对于复杂视图而言，会产生严重的性能问题，随着视图数量的增长，Autolayout带来的CPU消耗是呈指数上升的。所以尽量使用代码布局。如果不想手动调整frame等，也可以借助三方库，例如Masonry（OC）、SnapKit（Swift）、ComponentKit、AsyncDisplayKit等-
6、文本处理的优化：当一个界面有大量文本时，其行高的计算、绘制也是非常耗时的
-
1）如果对文本没有特殊要求，可以使用UILabel内部的实现方式，且需要放到子线程中进行，避免阻塞主线程
计算文本宽高：
[NSAttributedString boundingRectWithSize:options:context:]文本绘制：
[NSAttributedString drawWithRect:options:context:]
2）自定义文本控件，利用
TextKit或最底层的CoreText对文本异步绘制。并且CoreText对象创建好后，能直接获取文本的宽高等信息，避免了多次计算（调整和绘制都需要计算一次）。CoreText直接使用了CoreGraphics占用内存小，效率高
-
-
7、图片处理（解码 + 绘制）
1）当使用
UIImage或CGImageSource的方法创建图片时，图片的数据不会立即解码，而是在设置时解码（即图片设置到UIImageView/CALayer.contents中，然后在CALayer提交至GPU渲染前，CGImage中的数据才进行解码）。这一步是无可避免的，且是发生在主线程中的。想要绕开这个机制，常见的做法是在子线程中先将图片绘制到CGBitmapContext，然后从Bitmap直接创建图片，例如SDWebImage三方框架中对图片编解码的处理。这就是Image的预解码当使用CG开头的方法绘制图像到画布中，然后从画布中创建图片时，可以将图像的
绘制在子线程中进行
-
8、图片优化
1）尽量使用
PNG图片，不使用JPGE图片2）通过
子线程预解码，主线程渲染，即通过Bitmap创建图片，在子线程赋值image3）优化图片大小，尽量避免动态缩放
4）尽量将多张图合为一张进行显示
9、尽量
避免使用透明view，因为使用透明view，会导致在GPU中计算像素时，会将透明view下层图层的像素也计算进来，即颜色混合处理10、
按需加载，例如在TableView中滑动时不加载图片，使用默认占位图，而是在滑动停止时加载11、少使用
addView给cell动态添加view
GPU层面优化
相对于CPU而言，GPU主要是接收CPU提交的纹理+顶点，经过一系列transform，最终混合并渲染，输出到屏幕上。
1、尽量
减少在短时间内大量图片的显示，尽可能将多张图片合为一张显示，主要是因为当有大量图片进行显示时，无论是CPU的计算还是GPU的渲染，都是非常耗时的，很可能出现掉帧的情况2、尽量避免图片的尺寸超过
4096×4096，因为当图片超过这个尺寸时，会先由CPU进行预处理，然后再提交给GPU处理，导致额外CPU资源消耗3、尽量减少视图数量和层次，主要是因为视图过多且重叠时，GPU会将其混合，混合的过程也是非常耗时的
4、尽量避免离屏渲染
5、异步渲染，例如可以将cell中的所有控件、视图合成一张图片进行显示。可以参考Graver三方框架
注：上述这些优化方式的落地实现，需要根据自身项目进行评估，合理的使用进行优化