RunLoop 是 iOS 开发中一个非常基础而又重要的一个概念
- 为什么说它非常重要呢？
- 它不仅是检验一个程序员水平的知识点
- 它也是和
事件的传递和响应、Runtime一样被作为面试的常见问题 - 而且，程序的入口
main()函数本身其实内部就开启了一个主运行循环，你可以理解为是一个死循环，它保证了程序不退出一直运行，可以说没有runloop，那么程序一启动就会闪退了 - 它可以节省CPU资源，提高程序的性能（原则是有事就做处理，没事就休息）
- 由此可见其重要性
- 那为什么又说它非常基础呢？
其实我们在开发中无时无刻不在接触这个东西 - 我们在使用NSTimer的时候用到了这个
- 各种触摸事件
- selector事件，比如performSelector
- 等等等等这些很基础的东西都用到了它
- RunLoop--简单认识
- 从字面意思上说，它就是运行循环,不断的循环，不断的跑圈处理事件
- 苹果提供了2套API来访问RunLoop
core foundation框架[CFRunloopRef]和foundation框架[NSRunloop] - NSRunLoop是基于CFRunLoopRef的一层OC包装，提供了面向对象的 API，但是这些 API 不是线程安全的。如果想要更深的了解RunLoop内部结构，建议多研究CFRunLoopRef层面的API（Core Foundation层面）
- RunLoop参考资料-官方文档、 CFRunLoopRef开源代码下载地址
- RunLoop--线程相关
- 一个Runloop对应着一条唯一的线程
- 线程本身是执行完自己的任务就死了，但是可以通过给线程开启一个RunLoop保证其即使执行完自己任务也不死
- 程序启动默认是已经开启了一个Runloop，它是和主线程有关联的
- 除了主线程的runloop是系统默认开启的，其他的子线程的runloop需要自己手动创建，不然是不会开启的
- runloop会在第一次获取时被创建，在线程结束时被销毁
- RunLoop--创建初识
- 获取当前应用程序的主线程对应的Runloop
//NSRunloop类型
NSRunLoop * runloop = [NSRunLoop mainRunLoop];
//CFRunLoopRef类型
CFRunLoopRef runloop = CFRunLoopGetMain(); - 获得当前线程的Runloop
//NSRunloop类型
NSRunLoop * runloop = [NSRunLoop currentRunLoop];
//CFRunLoopRef类型
CFRunLoopRef runloop = CFRunLoopGetCurrent(); - 上述方法里面需要注意的是，runloop的创建是直接使用currentRunLoop方法创建的，并不是普通的对象那种alloc init方法创建，而且其本身是一个懒加载
- 线程的runloop对象是通过字典来进行存储的，字典的value自然 不必多说，就是对应的runloop对象，它的key就是对应的线程啦~
- RunLoop--相关类
- CFRunloopRef （对象）
- CFRunloopModeRef（Runloop的运行模式）
- CFRunloopSourceRef（Runloop要处理的事件源）
- CFRunloopTimerRef（Timer事件）
- CFRunloopObserverRef（Runloop的观察者（监听者））
RunLoop相关类关系图.png
`
- CFRunLoopSourceRef 是事件产生的地方
Source有两个版本：Source0(非基于端口) 和 Source1(基于端口) ;
Source0 只包含了一个回调（函数指针），它并不能自己主动触发事件,一般用于需要用户去主动触发的事件。使用时，你需要先调用 CFRunLoopSourceSignal(source)，将这个 Source 标记为待处理，然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件;
Source1 包含了一个 mach_port 和一个回调（函数指针），被用于通过内核和其他线程相互发送消息。这种 Source 能主动唤醒 RunLoop 的线程 - CFRunLoopTimerRef 是基于时间的触发器
它和 NSTimer 是差不多的。其包含一个时间长度和一个回调（函数指针）。当其加入到 RunLoop 时，RunLoop会注册对应的时间点，当时间点到时，RunLoop会被唤醒以执行那个回调。
3）CFRunLoopObserverRef 是观察者，每个 Observer 都包含了一个回调（函数指针），当 RunLoop 的状态发生变化时，观察者就能通过回调接受到这个变化。
可观察状态发生变化的几个时间节点
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
kCFRunLoopEntry = (1UL << 0), // 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1), // 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2), // 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5), // 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6), // 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7), // 即将退出Loop
};
`
- 对上述关系图的一些解析(对于理解runloop个人感觉还是非常重要的)
- runloop内部有很多的模式，它可以任意切换不同的模式，每个模式里面又有很多的Timer、Source、Observer等对象，这些对象用以告诉runloop需要去处理什么事情，这样runloop就可以监听到不同的操作，如果它有被唤醒，那么它就一直循环的处理事件，否则就去睡觉
- 每次runloop启动后只可以同时指定一个mode，并且Mode里面至少要有一个source或者一个timer，仅仅只有一个observer是不行的，不然程序一启动还是会退出的，并且当前这个runloop被称为currentRunloop
- 如果需要切换mode，那么只可以先退出当前的loop，再重新指定一个mode进入，这样做的目的也很简单，主要是为了区分不同组的timer、source、observer让其互不影响
- RunLoop -- 逻辑处理
先上一幅比较能说明问题的图片，这个是万能的网友整理的，让我想起了，当年大学英语四六级，每次考完试就有源源不断的各种网友整理版答案
Runloop逻辑处理.png
对应逻辑.png
- RunLoop和NSTimer使用相关
- 先看一个系统默认注册的五个模式
a.kCFRunLoopDefaultMode：App的默认Mode，通常主线程是在这个Mode下运行
b.UITrackingRunLoopMode：界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响
c.UIInitializationRunLoopMode: 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用
d.GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，通常用不到
e.kCFRunLoopCommonModes: 这是一个占位用的Mode，不是一种真正的Mode - 之所以先拿这个说明一些问题是因为定时器是我们平时使用比较多也比较基础的东西
- NSTimer如果调用了scheduledTimer方法，那么会自动添加到当前的runloop里面去，而且runloop的运行模式为kCFRunLoopDefaultMode ，如需更改的话
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes]; - NSTimer如果调用了timerWithTimeInterval方法，需要自己手动将其添加到对应的runloop运行模式里面
- 正常的规则是将定时器添加到什么模式下，它就在什么模式下有效，一旦切换模式，那么它就不工作
- 在主线程中操作定时器，因为主线程的操作默认都是在主运行循环中执行，主运行循环默认的模式是默认模式，这个时候如果处于拖拽模式就不会工作了
- 定时器设置为通用模式后，里面相当于包括了2个模式，普通和拖拽
- 但是这个并不违背每一个runloop只可以同时指定一个Mode，因为它默认是相当于把定时器分别添加到了普通和拖拽模式下，这样无论是切换到普通还是拖拽，定时器都可以运作
- 常用的那种定时器创建方式(调度那种)，系统默认是已经将其添加到默认模式了，如果我们想让他无论是拖拽还是默认都起作用还需要将定时器添加到拖拽模式
结束语
OK，繁杂的文字说明暂时告一段落，实在没办法，runloop本身就是这样的，需要用文字去说明其本身的含义，写的不足之处欢迎指正，一起学习，这些是目的我对于runloop的基本理解，接下来会继续写关于runloop在iOS开发中的一些实际应用，比如自动释放池，手势识别，常驻线程、PerformSelecter等
网友评论