首先从Image的加载说起
从磁盘加载一张图片，使用UIImageVIew显示在屏幕上，需要经过以下步骤：
(1) 从磁盘拷贝数据到内核缓冲区
(2) 从内核缓冲区复制数据到用户空间
(3) 把图像数据赋值给UIImageView
(4) 如果图像数据为未解码的PNG/JPG,解码为位图数据
(5) CATransaction捕获到UIImageView的layer的图层树的变化
(6) Runloop回调对CATransaction的Observer函数,开始进行图像渲染
(6.1) 如果数据没有字节对齐,Core Animation会再拷贝一份数据,进行字节对齐
(6.2) GPU处理位图数据并进行渲染
然后我们讨论一下CALayer
CALayer 和 UIView 一样存在着一个层级树状结构,称之为图层树(Layer Tree)。
直接创建的layer或者通过 view.layer 获得的layer是用于显示的图层树,称之为模型树(Model Tree),模型树的背后还存在两份图层树的拷贝,一个是呈现树(Presentation Tree),一个是渲染树(Render Tree)。呈现树可以通过 layer的 layer.presentationLayer 获得; 渲染树是私有的、无法访问到; 而模型树则可以通过 layer.modelLayer 属性获得，模型树的属性在其被修改的时候就变成了新的值,这个是可以用代码直接操控的部分。
呈现树的属性值和动画运行过程中界面上看到的是一致的; 渲染树是对呈现树的数据进行渲染,为了不阻塞主线程,渲染的过程是在单独的进程或线程中进行的,所以你会发现 Animation 的动画并不会阻塞主线程。
CALayer 的那些可用于动画的(Animatable)属性,称之为 Animatable Properties。如果一个 Layer 对象存在对应着的 View,则称这个 Layer 是一个Root Layer；非 Root Layer 一般都是通过 CALayer 或其子类直接创建的、所有的非 Root Layer 在设置 Animatable Properties 的时候都存在着隐式动画,默认的 duration 是 0.25 秒。
任何 Layer 的 animatable Property 的设置都应该属于某个 CA 事务(CATransaction),事务的作用是为了保证多个 animatable 属性的变化同时进行,不管是同一个 layer 还是不同的 layer 之间的。CATransaction 也分两类:显式的和隐式的。当在某次 RunLoop 中设置一个 animatable 属性的时候,如果发现当前没有事务,则会自动创建一个 CA 事务,在线程的下个 RunLoop 开始时自动 commit 这个事务。如果在没有 RunLoop 的地方设置 layer 的animatable Property,则必须使用显式的事务 (PS:子线程中设置 layer.backgroundColor 后必须显示的调用"[CATransaction commit];"才行)。
CATransaction 是 Core Animation 中的事务类，在 iOS 的图层中、图层的每个改变都是事务的一部分，CATransaction 可以对多个 layer 的属性同时进行修改，同时负责批量的把多个图层树的修改作为一个原子更新到渲染树。
CATransaction 事务类分为隐式事务和显式事务。
注意以下两组概念的区分:
隐式动画和隐式事务 - 隐式动画通过隐式事务实现动画。
显式动画和显式事务 - 显式动画有多种实现方式，显式事务是一种实现显式动画的方式。
隐式事务是基于 CALayer的，任何对于 CALayer 属性的修改都是隐式事务、这样的事务会在 runloop 中被提交。
隐式事务是 CoreAnimation 的一部分，是对 layer-tree 进行原子更新为 render-tree 的机制，由 CoreAnimation 帮助创建事务。当前线程的 runloop下次循环就会自动 commit，如果当前线程没有 runloop，或者 runloop 被阻塞，则应该使用显示事务。所谓的隐式动画是因为我们并没有指定任何动画的类型，我们仅仅改变了一个属性，然后 Core Animation 来决定如何并且何时去做动画。但当你改变一个属性，Core Animation 是如何判断动画类型和持续时间的呢? 实际上动画执行的时间取决于当前事务的设置，动画类型取决于图层行为。事务实际上是 Core Animation 用来包含一系列属性动画集合的机制，任何用指定事务去改变可以做动画的图层属性都不会立刻发生变化，而是当事务一旦提交的时候开始用一个动画过渡到新值。
调用 CATransaction 的 begin 和 commit 方法就可以实现显示事务。
线程是如何捕捉到 CATransaction 的 ?
调用 CATransaction 的 begin 和 commit 方法实现显示事务、包含在begin & commit之间的代码就可以被捕捉。
那么其他的情况呢? 比如直接修改layer的contents属性的情况。
（1）在临时子线程中修改layer的属性:
如上所示当修改了layer的背景色之后layer并不会立即就进行更新。而是等到子线程退出时才会进行更新、此时会有不可预估的时间延迟（当修改layer的背景色之后会延迟几秒亦或几分钟后背景色才会被更新）。原因是：当子线程退出时会调用_pthread_tsd_cleanup继而调用CATransaction的Transaction::release_thread方法、接着调用Transaction::commit()方法、在commit方法中对layer的修改才会被提交到GPU进行绘制。
以上的整个过程不会唤醒main runloop、更不会引起main runloop的运行状态变化。这也从侧面证实了渲染的过程是在单独的进程或线程中进行的、并不会阻塞主线程。
getSubThreadInQueue方法是从GCD线程池里请求大量的线程、目的是让系统尽快释放不再需要的线程、便于调试：
（2）临时子线程中修改layer的属性、显示地调用commit：
显示的调用Transaction::commit()方法、在commit方法中对layer的修改会被提交到GPU进行绘制、此时layer会立即更新、不会出现延迟的情况。
如上所示的代码中对CATransaction设置的CompletionBlock并不会在commit之后被调用！(由于临时子线程中没有runloop的原因、调用时机是系统对当前线程进行回收之时、(添加了断点:_pthread_tsd_cleanup))
以上的整个过程不会唤醒mainrunloop、更不会引起main runloop的运行状态变化。这也从侧面证实了渲染的过程是在单独的进程或线程中进行的、并不会阻塞主线程。
（3）常驻子线程中修改layer的属性：
修改layer的property对当前线程的runloop产生的影响：
在修改layer的contents属性之前、查看当前线程中runloop的状态 （po [NSRunLoop currentRunLoop]）：
当修改了layer的contents属性之后、当前线程的runloop的变化（添加了一个监听Transaction的observer）:
如上图所示：app启动后main runloop会在图层树第一次被修改的时候添加一个Transaction的Observer监听、监听BeforeWaiting & Exit、其回调函数是"_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv"也就是主线程里会捕捉到CATransaction的原因。
PS： 在“application:didFinishLaunchingWithOptions:”处打断点查看po currentRunloop、可发现此时尚未创建这个Transaction的监听。
注意事项
当前线程的 runloop 状态变为 BeforeWaiting 或者 Exit 时、在回调的'CA::Transaction::observer_callback'方法中并不是每次都会调用'CA::Transaction::commit'方法。
如果存放 layer 属性更改的容器中没有元素、那么在执行回调函数'CA::Transaction::observer_callback'的方法中就不会再调用'CA::Transaction::commit'方法了。
可添加以下断点、自行进行调试：
CATransaction如何使用 ?
使用案例(QATextTransaction) GitHub - Avery-AN/TableView: TableView优化案例、Cell展示内容的异步绘制、Cell展示图片的异步解码与字节对齐的处理、TableView首屏cell渲染的提速、支持Cell展示内容中包含的各种富文本的交互。
