背景
UIView实际是一个复合类型，CALayer是它内部实际承担绘制显示任务的部分。
当一个view的图层(layer)属性发生变化的时候，系统是如何知道要去重新渲染这个图层呢？比如修改背景色：_testLayer.backgroundColor = [UIColor blueColor].CGColor;。
- CATransaction会捕获CALayer的变化，包括任何的渲染属性，把这些都提交到一个中间态
- 然后在当前Runloop进入休眠或结束前，会发出Observer 消息。这是一种runloop消息类型，跟通知的方式类似，会通知观察者，这时Core Animation会把这些CALayer的变化提交给GPU绘制
所以问题的核心就是CATransaction怎么捕获layer变化的。
就像下面这样，包含在begin和commit内部的变化会被捕获。
[CATransaction begin];
_testLayer.backgroundColor = [UIColor blueColor].CGColor;
[CATransaction commit];
至于主线程里直接修改layer为什么也可以，是因为
Core Animation supports two types of transactions: implicit transactions and explicit transactions. Implicit transactions are created automatically when the layer tree is modified by a thread without an active transaction and are committed automatically when the thread's runloop next iterates
隐式的事务（Implicit transactions）会在图层树的修改的时候自动创建，并且在下一次runloop迭代的时候提交。而主线程有一个自动开启的runloop，所以即使不写CATransaction代码也会起作用。
真正问题
但我这篇文章关心并不是CATransaction、CoreAnimation或runloop的机制问题，而是为什么被夹在[CATransaction begin];和[CATransaction commit];为什么能够被CATransaction抓到，我关心是的是代码设计上的问题。
其实这种代码句式有很多地方用到：
@autoreleasepool {
__autoreleasing UIButton *button = [[UIButton alloc] initWithFrame:(CGRectMake(30, 100, 100, 30))];
}
@synchronized (self) {
//资源操作
}
[UIView beginAnimations:@"" context:nil];
//动画内容
[UIView commitAnimations];
作为对比的反例是UITableView的更新：
UITableView *_tableview;
[_tableview beginUpdates];
[_tableview deleteSections:[NSIndexSet indexSetWithIndex:1] withRowAnimation:(UITableViewRowAnimationAutomatic)];
[_tableview endUpdates];
tableview这个和前面的有什么区别？
虽然它们都是前后包裹的一段代码这样的格式，但是tableview这个是针对一个对象的，而前面的3个是没有指定对象或变量的。
先猜测一下[_tableview beginUpdates];的逻辑：
在调用deleteSections之类的方法时本来会立即起作用的，但是在beginUpdates内部就不会，那么用一个检查就可以达到效果。deleteSections这类更新方法的时候，先检查是否在begin和end之间，是就不处理，否则就处理。
而到[UIView beginAnimations:@"" context:nil];这里，你根本没有指定是哪个view的动画，它是怎么怎么把内部的动画打包的呢？
我的猜测
首先没有绑定某个对象或变量，但是它要存储信息，那么肯定是用了某种全局性的东西，比如全局变量，或者UIApplication唯一的，或者当前线程唯一的。
用这个全局的变量来存储，对于像下面这样的代码
[CATransaction begin];
_testLayer.backgroundColor = [UIColor blueColor].CGColor;
[CATransaction commit];
可以猜测它实际是这样的：
//生成一个新的事务并返回
[CATransaction newTransaction];
{ //这一段是layer修改背景色内部的逻辑
setBackgroundColor{
//获取当前的CATransaction，并把修改提供给它
CATransaction *currentTrans = [CATransaction getCurrentTransaction];
[currentTrans addLayerChange:self forKey:@"backgroundColor"];
}
}
//提交layer变化并移除当前的事务
[CATransaction commitLayerChanges];
[CATransaction removeCurrentTransaction];
也就是只要维持一个当前正确的CATransaction就正确了。
但是考虑到CATransaction是可以嵌套的，那么就有这样的过程：事务1-->事务2开启-->layer修改-->事务2提交结束-->回到事务1。
这种一看就很符合栈的行为，所以可以使用一个全局的栈来管理CATransaction：
- begin的时候，新建一个CATransaction，push放到栈顶
- 然后获取当前CATransaction的时候呢，就取栈顶元素就可以
- commit的时候，pop栈顶元素。并且把layer的变化提交。
验证想法
因为CATransaction的代码看不到，没法验证逻辑，但是autoreleasepool的代码是可以看的，因为OC的一些源码都开源了，这是地址。
- 首先
@autoreleasepool {xxx}会被解析成：
void *context = objc_autoreleasePoolPush();
// {}中的代码
objc_autoreleasePoolPop(context);
看这个样式，跟CATransaction是一样的，{}的结构其实只是编译器的作用，其实还是前后一段代码。
- 然后先看push:
void *
objc_autoreleasePoolPush(void)
{
return AutoreleasePoolPage::push();
}
static inline void *push()
{
id *dest;
if (DebugPoolAllocation) {
// Each autorelease pool starts on a new pool page.
dest = autoreleaseNewPage(POOL_BOUNDARY);
} else {
dest = autoreleaseFast(POOL_BOUNDARY);
}
assert(dest == EMPTY_POOL_PLACEHOLDER || *dest == POOL_BOUNDARY);
return dest;
}
push的代码里有个DebugPoolAllocation引起分支：
- autoreleaseNewPage这个干的事就是：新建一个AutoreleasePoolPage,把它作为hotPage然后把POOL_BOUNDARY这条数据加入这个新的page
- 而autoreleaseFast就是直接在当前的hotPage里加入POOL_BOUNDARY这条数据
所以这里有几个问题：
- AutoreleasePoolPage是啥？
正如它的名字page,它就相当于笔记本里的一页纸，它保存了许多个对象，这些对象都是加入到自动释放池的那些。然后等一个page满了，就开一个新的page,然后通过parent和child指针连接：
AutoreleasePoolPage * const parent;
AutoreleasePoolPage *child;
所以说它就是一个双链表的结构，每一个节点保存了若干的释放池对象。
AutoreleasePoolPage结构示意图
-
hotPage是啥？
hotPage就是当前最新的一个page，它还有空间，可以继续存储对象。所以在push时，都是把内容加入到hotPage。 -
POOL_BOUNDARY的作用
这个东西至关重要，从上面的结构里可以看出，当我开启一个新的自动释放池的时候，并没有开启一个新的对象，就得释放池和新的释放池是在同一个AutoreleasePoolPage的双链表里。
那么我要怎么区分哪些对象是当前的自动释放池里的呢？
就是用POOL_BOUNDARY这个东西，它就是用来确定边界的，它左边和右边不是同一个自动释放池。看上面的示意图里的（1）和（2）的位置。比如第二个page还有一部分空间，这时开启了一个新的自动释放，那么就是在（1）的这部分空间最顶上插入一个POOL_BOUNDARY作为标识，这样之后的内存就是属于新的释放池了。
而push里因为DebugPoolAllocation造成的两种不同结果，只是开启一个新的释放池的时候是直接在下一个空位加入标识，还是另建立一个page再插入标识，也就是位置（1）和（2）的区别。
- 在pop的时候，会把当前的hotPage的数据一致删，删到最新的标志位，也就是开启释放池的时候插入的POOL_BOUNDARY位置。
所以流程就是：
- 开启自动释放池：在AutoreleasePoolPage的双链表里加入一个POOL_BOUNDARY标识
- 对象调用autoRelease或者标记__autoreleasing就会被push到当前的hotPage里
- 自动释放池结束：AutoreleasePoolPage的双链表把对象一个个释放，直到POOL_BOUNDARY标识
结论
Autorelease的处理方式基本印证了我的想法，就是靠“全局+栈结构”的方式来处里。AutoreleasePoolPage的双链表就是栈的行为
略微的区别是：
- 自动释放池本身是没有封装成一个结构或者对象的，它只是链表中的一节。即我想的结构是是：
全局的栈-->CATransaction-->layer的改变。而自动释放池的结构是:全局的栈-->AutoreleasePoolPage-->变量。实际它是直接抹平了中间层，把数据直接放到栈里操控。 - 它的“全局”，是线程唯一的数据，通过把数据和线程绑定来获得当前的，并不是通过全局变量。
网友评论