UIView 绘制渲染机制

#前言

APP页面优化对小编来说一直是难题，最近一直在不断的学习和总结 ，发现APP页面优化说到底离不开view的绘制和渲染机制。网上有很多精彩的博客，小编借鉴之前N多大牛研究成果，同时结合自己遇到的一些问题，整理了这篇博客。

尝试和大家一起探讨以下问题：

1. view绘制渲染机制和runloop什么关系？
2. 所谓的列表卡顿，到底是什么原因引发的？
3. 我们经常在drawrect方法里绘制代码，但该方法是谁调用的 何时调用的？
4. drawrect方法内为何第一行代码往往要获取图形的上下文？
5. layer的代理必须是view吗，可以是vc吗，为何CALayerDelegate 不能主动遵循？
6. view绘制机制和CPU之间关系？
7. view渲染机制和GPU之间关系？
8. 所有的切圆角都很浪费性能吗？
9. 离屏渲染很nb吗?
10. 那些绘制API都是哪个类提供的 我如何系统的学习它？
11. 如何优化CPU /GPU使用率？

view绘制渲染机制和runloop什么关系？

代码示例

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    ZYYView *view = [[ZYYView alloc] init];
    view.backgroundColor = [UIColor whiteColor];
    view.bounds = CGRectMake(0, 0, 100, 100);
    view.center = CGPointMake(100, 100);
    [self.view addSubview:view];
}

@end

@implementation ZYYView

- (void)drawRect:(CGRect)rect {
    CGContextRef con = UIGraphicsGetCurrentContext();
    CGContextAddEllipseInRect(con, CGRectMake(0,0,100,200));
    CGContextSetRGBFillColor(con, 0, 0, 1, 1);
    CGContextFillPath(con);
}

@end

堆栈展示

底层原理

当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局的容器去。
苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件，回调去执行一个很长的函数：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整，并更新 UI 界面。
这个函数内部的调用栈大概是这样的：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayer layoutSublayers];
[UIView layoutSubviews];
CA::Layer::display_if_needed();
[CALayer display];
[UIView drawRect];

我们上图的堆栈信息 截图 ，看到巴拉巴拉一大堆调用堆栈信息，其实这就是个函数做的孽 。如何不能理解，那直接看下面的流程图吧。

流程图