再谈runloop

首先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
};

do-while的过程中，做了以下操作

• 监听source（source1是基于port的线程通信(触摸/锁屏/摇晃等)，source0是不基于port的，是App事件 包括：UIEvent、performSelector），监听到就处理
• 监听timer的事件，监听到就处理
• 没有source和timer的时候，就休眠，休眠不是不监听，还是保持监听的，只是当有事件的时候，才唤醒，继续处理

当我们触发了事件（触摸/锁屏/摇晃等）后，由IOKit.framework生成一个 IOHIDEvent事件，而IOKit是苹果的硬件驱动框架，由它进行底层接口的抽象封装与系统进行交互传递硬件感应的事件，并专门处理用户交互设备，由IOHIDServices和IOHIDDisplays两部分组成，其中IOHIDServices是专门处理用户交互的，它会将事件封装成IOHIDEvents对象，接着用mach port转发给需要的App进程，随后 Source1就会接收IOHIDEvent，之后再回调__IOHIDEventSystemClientQueueCallback()，__IOHIDEventSystemClientQueueCallback()内触发Source0，
Source0 再触发 _UIApplicationHandleEventQueue()。
所以触摸事件看到是在 Source0 内的。

struct __CFRunLoop {
    pthread_t _pthread;                // 线程对象
    CFMutableSetRef _commonModes;       //    mode
    CFMutableSetRef _commonModeItems;
    CFRunLoopModeRef _currentMode;
    CFMutableSetRef _modes;
    ...
    // 简化
};

• kCFRunLoopDefaultMode: App的默认 Mode，通常主线程是在这个 Mode 下运行的。
• UITrackingRunLoopMode: 界面跟踪 Mode，用于 ScrollView 追踪触摸滑动，保证界面滑动时不受其他 Mode 影响。
• UIInitializationRunLoopMode: 在刚启动 App 时第进入的第一个 Mode，启动完成后就不再使用。
• GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，通常用不到。
• kCFRunLoopCommonModes: 这是一个占位的 Mode，没有实际作用。

除了以上5个mode，还有其他mode，但是很少遇见这里

4.子线程不自动开启runloop，手动开启runloop前，必须得有输入源和定时器（输入源就是通过监听端口，可以获取不同的事件），通过CFRunloop源码中的CFRunLoopRunSpecific函数，其中判断了当mode为null或者modeItem为空，直接return

当开启一个线程，就会对应创建一个runloop对象吗？

不是的,调用获取当前runloop的方法，内部实现：如果当前runloop不存在就创建一个，存在就返回当前runloop

所以走这句代码self.myRunloop = [NSRunLoop currentRunLoop];就生成当前线程对应的runloop

- (void)test2
{
    [self.myThread setName:@"TestThread"];
    self.myRunloop = [NSRunLoop currentRunLoop];
    self.myPort = [NSMachPort port];
    
    // 添加监听NSMachPort的端口（这个端口可以理解为输入源，因为可以一直监听这个，所以这时候的runloop不会退出，会一直在做do-while）
    [self.myRunloop addPort:self.myPort forMode:NSDefaultRunLoopMode];
    
    [self.myRunloop run];
    
    // [self.myRunloop run]; 会导致以下代码没法走，
//因为runloop就是一个do-while的循环，do-while监听源，处理源
    [self.testPtr release];
}

如果NSTimer的repeats是NO,那么执行一次timer的事件后，就会退出runloop

以上，如果通过移除端口，结束timer，反正以移除已知的输入源或者定时器来退出runloop都是不太靠谱的，因为系统内部有可能会在当前线程的runloop中添加一些输入源，也就是还有未知的输入源，我们没有移除。

三种Run方法

// 不会退出runloop
- (void)run; 

// 超时时候到退出runloop
- (void)runUntilDate:(NSDate *)limitDate； 

// 处理完source会退出或者时间到也会退出
- (void)runMode:(NSString *)mode beforeDate:(NSDate *)limitDate;

// 上三个方法分别对应CFRunloop

将上一段代码[self.myRunloop run];
替换成[self.myRunloop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];

虽然 可以成功退出runloop，但是还是有问题，当runloop处理完source后，就退出runloop了，而且这时候，也不会像调用run方法那样，重新进入runloop

BOOL shouldKeepRunning = YES; // global
NSRunLoop *theRL = [NSRunLoop currentRunLoop];
while (shouldKeepRunning) {
	// runMode是有返回值的，当启动runloop后，是不会返回的，
         //所以不会一直在调这个方法，runloop退出了，才会再调
	[theRL runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]]
       // 有返回值 但是一直不返回的方法
}

runloop和autoreleasepool

App启动后，苹果在主线程 RunLoop 里注册了两个 Observer，其回调都是 _wrapRunLoopWithAutoreleasePoolHandler()。

第一个 Observer 监视的事件是
 Entry(即将进入Loop)，其回调内会调用 _objc_autoreleasePoolPush() 创建自动释放池。其 order 是-2147483647，优先级最高，保证创建释放池发生在其他所有回调之前。

第二个 Observer 监视了两个事件：
 BeforeWaiting(准备进入休眠) 时调用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 释放旧的池并创建新池；

Exit(即将退出Loop) 时调用 _objc_autoreleasePoolPop() 来释放自动释放池。这个 Observer 的 order 是 2147483647，优先级最低，保证其释放池子发生在其他所有回调之后。