转载：程序猿（二，31-55）

猜想runloop内部是如何实现的？
一般来讲，一个线程一次只能执行一个任务，执行完成后线程就会退出。如果我们需要一个机制，让线程能随时处理事件但并不退出，通常的代码逻辑是这样的：

function loop() { initialize(); do { var message = get_next_message(); process_message(message); } while (message != quit);}

或使用伪代码来展示下:
// // http://weibo.com/luohanchenyilong/ (微博@iOS程序犭袁)// https://github.com/ChenYilongint main(int argc, char * argv[]) { //程序一直运行状态 while (AppIsRunning) { //睡眠状态，等待唤醒事件 id whoWakesMe = SleepForWakingUp(); //得到唤醒事件 id event = GetEvent(whoWakesMe); //开始处理事件 HandleEvent(event); } return 0;}

参考链接：
《深入理解RunLoop》
摘自博文CFRunLoop，原作者是微博@我就叫Sunny怎么了

[

~~编译时根据代码上下文，插入 retain/release~~
ARC相对于MRC，不是在编译时添加retain/release/autorelease这么简单。应该是编译期和运行期两部分共同帮助开发者管理内存。
在编译期，ARC用的是更底层的C接口实现的retain/release/autorelease，这样做性能更好，也是为什么不能在ARC环境下手动retain/release/autorelease，同时对同一上下文的同一对象的成对retain/release操作进行优化（即忽略掉不必要的操作）；ARC也包含运行期组件，这个地方做的优化比较复杂，但也不能被忽略。【TODO:后续更新会详细描述下】
[

释放的时机总结起来，可以用下图来表示：

autoreleasepool与 runloop 的关系图

下面对这张图进行详细的解释：
从程序启动到加载完成是一个完整的运行循环，然后会停下来，等待用户交互，用户的每一次交互都会启动一次运行循环，来处理用户所有的点击事件、触摸事件。
我们都是知道： 所有 autorelease 的对象，在出了作用域之后，会被自动添加到最近创建的自动释放池中。
但是如果每次都放进应用程序的 main.m
中的 autoreleasepool 中，迟早有被撑满的一刻。这个过程中必定有一个释放的动作。何时？
在一次完整的运行循环结束之前，会被销毁。
那什么时间会创建自动释放池？运行循环检测到事件并启动后，就会创建自动释放池。
子线程的 runloop 默认是不工作，无法主动创建，必须手动创建。
自定义的 NSOperation 和 NSThread 需要手动创建自动释放池。比如：自定义的 NSOperation 类中的 main 方法里就必须添加自动释放池。否则出了作用域后，自动释放对象会因为没有自动释放池去处理它，而造成内存泄露。
但对于 blockOperation 和 invocationOperation 这种默认的Operation ，系统已经帮我们封装好了，不需要手动创建自动释放池。
@autoreleasepool 当自动释放池被销毁或者耗尽时，会向自动释放池中的所有对象发送 release 消息，释放自动释放池中的所有对象。
如果在一个vc的viewDidLoad中创建一个 Autorelease对象，那么该对象会在 viewDidAppear 方法执行前就被销毁了。
参考链接：《黑幕背后的Autorelease》
[

objc_autoreleasepoolPop

objc_autorelease

看函数名就可以知道，对 autorelease 分别执行 push，和 pop 操作。销毁对象时执行release操作。
举例说明：我们都知道用类方法创建的对象都是 Autorelease 的，那么一旦 Person 出了作用域，当在 Person 的 dealloc 方法中打上断点，我们就可以看到这样的调用堆栈信息：

enter image description here

[

参考链接：微博@唐巧_boy的著作《iOS开发进阶》中的第11.2.3章节
[

[[NSOperationQueue mainQueue] addOperationWithBlock:^{ self.someProperty = xyz; }];

[[NSNotificationCenter defaultCenter] addObserverForName:@"someNotification" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * notification) { self.someProperty = xyz; }];

这些情况不需要考虑“引用循环”。
但如果你使用一些参数中可能含有 ivar 的系统 api ，如 GCD 、NSNotificationCenter就要小心一点：比如GCD 内部如果引用了 self，而且 GCD 的其他参数是 ivar，则要考虑到循环引用：
__weak typeof(self) weakSelf = self;dispatch_group_async(_operationsGroup, _operationsQueue, ^{typeof(self) strongSelf = weakSelf;[strongSelf doSomething];[strongSelf doSomethingElse];} );

类似的：
__weak typeof(self) weakSelf = self; _observer = [[NSNotificationCenter defaultCenter] addObserverForName:@"testKey" object:nil queue:nil usingBlock:^(NSNotification *note) { typeof(self) strongSelf = weakSelf; [strongSelf dismissModalViewControllerAnimated:YES]; }];

self --> _observer --> block --> self 显然这也是一个循环引用。
[

[

](https://github.com/ChenYilong/iOSInterviewQuestions/blob/master/01%E3%80%8A%E6%8B%9B%E8%81%98%E4%B8%80%E4%B8%AA%E9%9D%A0%E8%B0%B1%E7%9A%84iOS%E3%80%8B%E9%9D%A2%E8%AF%95%E9%A2%98%E5%8F%82%E8%80%83%E7%AD%94%E6%A1%88/%E3%80%8A%E6%8B%9B%E8%81%98%E4%B8%80%E4%B8%AA%E9%9D%A0%E8%B0%B1%E7%9A%84iOS%E3%80%8B%E9%9D%A2%E8%AF%95%E9%A2%98%E5%8F%82%E8%80%83%E7%AD%94%E6%A1%88%EF%BC%88%E4%B8%8B%EF%BC%89.md#42-dispatch_barrier_async的作用是什么)42. dispatch_barrier_async
的作用是什么？
在并行队列中，为了保持某些任务的顺序，需要等待一些任务完成后才能继续进行，使用 barrier 来等待之前任务完成，避免数据竞争等问题。 dispatch_barrier_async
函数会等待追加到Concurrent Dispatch Queue并行队列中的操作全部执行完之后，然后再执行 dispatch_barrier_async
函数追加的处理，等 dispatch_barrier_async
追加的处理执行结束之后，Concurrent Dispatch Queue才恢复之前的动作继续执行。
打个比方：比如你们公司周末跟团旅游，高速休息站上，司机说：大家都去上厕所，速战速决，上完厕所就上高速。超大的公共厕所，大家同时去，程序猿很快就结束了，但程序媛就可能会慢一些，即使你第一个回来，司机也不会出发，司机要等待所有人都回来后，才能出发。 dispatch_barrier_async
函数追加的内容就如同 “上完厕所就上高速”这个动作。
（注意：使用 dispatch_barrier_async
，该函数只能搭配自定义并行队列 dispatch_queue_t
使用。不能使用：dispatch_get_global_queue
，否则 dispatch_barrier_async
的作用会和 dispatch_async
的作用一模一样。）
[

(void)viewDidLoad{ [super viewDidLoad]; NSLog(@"1"); dispatch_sync(dispatch_get_main_queue(), ^{ NSLog(@"2"); }); NSLog(@"3");}

只输出：1 。发生主线程锁死。
[

observer中需要实现一下方法：
// 所有的 kvo 监听到事件，都会调用此方法/* 1. 观察的属性 2. 观察的对象 3. change 属性变化字典（新／旧） 4. 上下文，与监听的时候传递的一致 */- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context;

[

](https://github.com/ChenYilong/iOSInterviewQuestions/blob/master/01%E3%80%8A%E6%8B%9B%E8%81%98%E4%B8%80%E4%B8%AA%E9%9D%A0%E8%B0%B1%E7%9A%84iOS%E3%80%8B%E9%9D%A2%E8%AF%95%E9%A2%98%E5%8F%82%E8%80%83%E7%AD%94%E6%A1%88/%E3%80%8A%E6%8B%9B%E8%81%98%E4%B8%80%E4%B8%AA%E9%9D%A0%E8%B0%B1%E7%9A%84iOS%E3%80%8B%E9%9D%A2%E8%AF%95%E9%A2%98%E5%8F%82%E8%80%83%E7%AD%94%E6%A1%88%EF%BC%88%E4%B8%8B%EF%BC%89.md#46-如何手动触发一个value的kvo)46. 如何手动触发一个value的KVO
所谓的“手动触发”是区别于“自动触发”：
自动触发是指类似这种场景：在注册 KVO 之前设置一个初始值，注册之后，设置一个不一样的值，就可以触发了。
想知道如何手动触发，必须知道自动触发 KVO 的原理：
键值观察通知依赖于 NSObject 的两个方法: willChangeValueForKey:
和 didChangevlueForKey:
。在一个被观察属性发生改变之前， willChangeValueForKey:
一定会被调用，这就会记录旧的值。而当改变发生后， didChangeValueForKey:
会被调用，继而 observeValueForKey:ofObject:change:context:
也会被调用。如果可以手动实现这些调用，就可以实现“手动触发”了。
那么“手动触发”的使用场景是什么？一般我们只在希望能控制“回调的调用时机”时才会这么做。
具体做法如下：
如果这个 value
是表示时间的 self.now
，那么代码如下：最后两行代码缺一不可。
// .m文件// Created by https://github.com/ChenYilong// 微博@iOS程序犭袁(http://weibo.com/luohanchenyilong/).// 手动触发 value 的KVO，最后两行代码缺一不可。//@property (nonatomic, strong) NSDate *now;- (void)viewDidLoad{ [super viewDidLoad]; [self willChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。 [self didChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。}

但是平时我们一般不会这么干，我们都是等系统去“自动触发”。“自动触发”的实现原理：
比如调用 setNow:
时，系统还会以某种方式在中间插入 wilChangeValueForKey:
、 didChangeValueForKey:
和observeValueForKeyPath:ofObject:change:context:
的调用。

大家可能以为这是因为 setNow:
是合成方法，有时候我们也能看到人们这么写代码:

(void)setNow:(NSDate *)aDate { [self willChangeValueForKey:@"now"]; // 没有必要 _now = aDate; [self didChangeValueForKey:@"now"];// 没有必要}

这是完全没有必要的代码，不要这么做，这样的话，KVO代码会被调用两次。KVO在调用存取方法之前总是调用willChangeValueForKey:
，之后总是调用 didChangeValueForkey:
。怎么做到的呢?答案是通过 isa 混写（isa-swizzling）。下文《apple用什么方式实现对一个对象的KVO？》会有详述。
参考链接： Manual Change Notification---Apple 官方文档
[

[

从Apple 的文档可以看出：Apple 并不希望过多暴露 KVO 的实现细节。不过，要是借助 runtime 提供的方法去深入挖掘，所有被掩盖的细节都会原形毕露：
当你观察一个对象时，一个新的类会被动态创建。这个类继承自该对象的原本的类，并重写了被观察属性的 setter 方法。重写的 setter 方法会负责在调用原 setter 方法之前和之后，通知所有观察对象：值的更改。最后通过 isa 混写（isa-swizzling）
把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新创建的子类，对象就神奇的变成了新创建的子类的实例。我画了一张示意图，如下所示：

enter image description here

KVO 确实有点黑魔法：
Apple 使用了 isa 混写（isa-swizzling）
来实现 KVO 。

下面做下详细解释：
键值观察通知依赖于 NSObject 的两个方法: willChangeValueForKey:
和 didChangevlueForKey:
。在一个被观察属性发生改变之前， willChangeValueForKey:
一定会被调用，这就会记录旧的值。而当改变发生后， didChangeValueForKey:
会被调用，继而 observeValueForKey:ofObject:change:context:
也会被调用。可以手动实现这些调用，但很少有人这么做。一般我们只在希望能控制回调的调用时机时才会这么做。大部分情况下，改变通知会自动调用。
比如调用 setNow:
时，系统还会以某种方式在中间插入 wilChangeValueForKey:
、 didChangeValueForKey:
和observeValueForKeyPath:ofObject:change:context:
的调用。大家可能以为这是因为 setNow:
是合成方法，有时候我们也能看到人们这么写代码:

(void)setNow:(NSDate *)aDate { [self willChangeValueForKey:@"now"]; // 没有必要 _now = aDate; [self didChangeValueForKey:@"now"];// 没有必要}

这是完全没有必要的代码，不要这么做，这样的话，KVO代码会被调用两次。KVO在调用存取方法之前总是调用willChangeValueForKey:
，之后总是调用 didChangeValueForkey:
。怎么做到的呢?答案是通过 isa 混写（isa-swizzling）。第一次对一个对象调用 addObserver:forKeyPath:options:context:
时，框架会创建这个类的新的 KVO 子类，并将被观察对象转换为新子类的对象。在这个 KVO 特殊子类中， Cocoa 创建观察属性的 setter ，大致工作原理如下:

(void)setNow:(NSDate *)aDate { [self willChangeValueForKey:@"now"]; [super setValue:aDate forKey:@"now"]; [self didChangeValueForKey:@"now"];}

这种继承和方法注入是在运行时而不是编译时实现的。这就是正确命名如此重要的原因。只有在使用KVC命名约定时，KVO才能做到这一点。
KVO 在实现中通过 isa 混写（isa-swizzling）
把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新创建的子类，对象就神奇的变成了新创建的子类的实例。这在Apple 的文档可以得到印证：
Automatic key-value observing is implemented using a technique called isa-swizzling... When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class ...

然而 KVO 在实现中使用了 isa 混写（ isa-swizzling）
，这个的确不是很容易发现：Apple 还重写、覆盖了 -class
方法并返回原来的类。企图欺骗我们：这个类没有变，就是原本那个类。。。
但是，假设“被监听的对象”的类对象是 MYClass
，有时候我们能看到对 NSKVONotifying_MYClass
的引用而不是对MYClass
的引用。借此我们得以知道 Apple 使用了 isa 混写（isa-swizzling）
。具体探究过程可参考这篇博文。
[

不过这个回答漏了个重要知识，使用storyboard（xib不行）创建的vc，会有一个叫_topLevelObjectsToKeepAliveFromStoryboard的私有数组强引用所有top level的对象，所以这时即便outlet声明成weak也没关系
[

enter image description here

设置全局断点快速定位问题代码所在行

Xcode 7 已经集成了BAD_ACCESS捕获功能：Address Sanitizer。用法如下：在配置中勾选✅
Enable Address Sanitizer

enter image description here

[

更多 lldb（gdb）调试命令可查看
The LLDB Debugger ；
苹果官方文档： iOS Debugging Magic 。

最后编辑于：2017.12.03 03:09:38

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 160,706评论 4赞 366
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 68,002评论 1赞 301
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 110,462评论 0赞 250
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 44,375评论 0赞 216
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 52,763评论 3赞 294
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 40,849评论 1赞 224
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 32,033评论 2赞 317
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 30,768评论 0赞 204
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 34,490评论 1赞 246
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 30,734评论 2赞 253
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 32,204评论 1赞 264
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 28,566评论 3赞 260
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 33,227评论 3赞 241
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 26,137评论 0赞 8
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 26,934评论 0赞 201
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 35,926评论 2赞 283
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 35,774评论 2赞 274

转载：程序猿（二，31-55）

推荐阅读更多精彩内容