概览
我个人了解一个事物的习惯，先去看的的外形，这可以让我知道他是一个什么东西，其次，了解他被设计出来的意义，这可以让我知道他的核心逻辑与服务目标。这样在我眼里他是什么，要去做什么就能有一个大概的概念。再从两个方向出发向中间对合，挖出他怎样执行目标，如何实现逻辑的行动思想。就可以将其串联起来，有一个容易理解的印象。
附一个runloop小demo：https://github.com/AnduinWrynnK/Diablos
RunLoop的外形
cfrunloop及mode结构体
runloop表层实现为一个结构体，根据字面量，内部属性有1.所有加入的mode。2.所有的公开mode。3.所有公开mode的内部事件集合。4.当前运行的mode。
RunLoop的设计意义
RunLoop循环是一个面向线程的任务处理机制，他的核心思想是依附于线程的生命周期，有任务执行，无任务休眠。达到一个在任务空闲时节省CPU资源的目的，同时也规定了一次任务处理循环的标准动作。同时，开发者可以使用RunLoop循环来实现线程间的通信，拿出优化解决方案。
RunLoop的运行原理
基于RunLoop外形，runloop的运行原理是：
原理图
实现（上）
实现（下）
runLoop跟随线程创建，可以处理source1、source0与Timer类型的事件。进入循环后，依次发出timer source0的执行通知并随后处理这些任务，再检查是否有source1的事件，有则直接去处理，处理完重新返回查找source0与Timer类型的事件，没有则跳过。执行完毕后发出通知线程进入休眠，当收到新的source1消息或手动运行循环时，唤醒线程重复进入循环后的步骤。当runloop中source1、source0与Timer类型的事件全部处理完毕或runloop达到超时时间，runloop退出。
与运行原理相关的概念：
RunLoopMode
runloop是loop->mode->source，三级结构，一个runloop可以有多个mode，但是一次只能以一个mode运行，runloop处理mode内部的事件或者说与mode类型相同的事件，也只发送当前mode注册的通知，并在执行完毕时退出，未运行的mode不影响当前的runloop活动。
kCFRunLoopDefaultMode
App的默认Mode，通常主线程是在这个Mode下运行
UITrackingRunLoopMode：
界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响
UIInitializationRunLoopMode:
在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用
GSEventReceiveRunLoopMode:
接受系统事件的内部 Mode，通常用不到
kCFRunLoopCommonModes:
这是一个占位用的Mode，作为标记kCFRunLoopDefaultMode和UITrackingRunLoopMode用，并不是一种真正的Mode
context
source、Timer与observer都有上下文对象，source与timer的上下文主要内容是三个回调函数用来在加入循环，执行与移出循环时回调。而observer的回调函数在构建CFRunLoopObserverRef时传入，不需在上下文中指出。
RunLoop的生命周期
runLoop的生命周期大致与此线程的生命周期相同，起于在线程内获取runloop，终于线程结束。CFDictionaryGetValue(loopsDic, thread)用来在全局查找thread对应的runloop，没有时会用_CFRunLoopCreate()方法创建并将之加入字典。只要是没有超时且还有未解决的事件，runloop就不会退出，不过这不能保证他是在唤起状态，source0与timer加入一个休眠线程是无法执行的，所以我们将一个事件加入一个runloop之后可以手动唤起他。或者是给他加一个port（source1）事件来让他停留在执行port检测这一步保持他的活跃。
开发者对RunLoop的实际应用
1.nstimer在默认mode下滑动UI时卡顿，换滑动响应的model就可以了，或者将timer丢到子线程并保活子线程。
2.在scrollView会大量加载图片的情况时，可以在runloop通知里结局这个问题，滑动时不加载图片，或者加一个缓存数组，一次循环只加载一张图片。
3.通过信号量与runloopObserver方法结合监听UI卡顿。
4.在runloop中监听崩溃类型，重新运行所有的mode，可以阻止此次崩溃，可是阻止不了第二次。
5.后台用mach-port保活一个线程用来专门做下载。
6.跟面试官对线。
网友评论