iOS高性能OC五:Runloop

一.基本概念

1.runloop是一个事件驱动的循环,收到事件就去处理,没有事件就进入睡眠.
2.应用一启动主线程被创建后,主线程对应的runloop也被创建,runloop也保证了程序能够一直运行.之后创建的子线程默认是没有runloop的,只有当调用[NSRunLoop currentRunLoop]去获取的时候才被创建.
3.runloop的模式:
mode一共五种:

NSDefaultRunLoopMode 默认
UITrackingRunLoopMode UI专用
UIInitializationRunLoopMode 在刚启动App时第进入的第一个Mode，启动完成后就不再使用
GSEventReceiveRunLoopMode 接受系统事件的内部Mode
NSRunLoopCommonModes 这是一个占位用的Mode，不是一种真正的Mode

首先是这样一个例子:

NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(tim) userInfo:nil repeats:YES];
    [[NSRunLoop currentRunLoop]addTimer:timer forMode:NSDefaultRunLoopMode];
    
    UITextView *tv = [[UITextView alloc]init];
    tv.backgroundColor = [UIColor lightGrayColor];
    tv.text = @"aasdasdsdasdsdasasdasdasdasdasdasdasaasdasdsdasdsdasasdas";
    tv.frame = CGRectMake(0, 100, 50, 50);
    [self.view addSubview:tv];

timer添加在default模式中,默认是正常执行的,当滑动textView的时候,timer就停下来了.
模式类似于跑道,一个runloop同时只能在一个跑道上进行,并且模式有优先级,UITrackingRunLoopMode是UI模式,是优先级最高的模式,当runloop遇到事件的时候,会根据事件指定的模式,去切换跑到,UITrackingRunLoopMode的优先级最高,所以就切换到了这个模式上,这时候其他模式下的事件就不会被执行.
并且UITrackingRunLoopMode只能被UI事件唤醒,如果将上面的timer指定的模式改成UI模式,那么默认是不会执行的,但是当滑动textView时,跑到就切换到了UI模式,timer就可以执行了,一旦停止滑动,timer又会停下来.
NSRunLoopCommonModes实质就是NSDefaultRunLoopMode和UITrackingRunLoopMode,等同于在两个模式上都添加一遍,不管是那个跑道,都会遇到timer的事件.

NSThread *th = [[NSThread alloc]initWithBlock:^{
        NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(tim) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop]addTimer:timer forMode:NSDefaultRunLoopMode];
        [[NSRunLoop currentRunLoop] run];
        NSLog(@"runloop后面");
    }];
    [th start];

在子线程获取runloop,由于UI只在主线程进行,主线程的runloop和子线程的runloop自然是没有关系的,此时使用NSDefaultRunLoopMode不再受到UI事件影响.
一旦调用run方法,runloop就会开始执行,子线程也不会被销毁,run后面的代码在runloop停下来之前也不会被执行.

NSThread *th = [[NSThread alloc]initWithBlock:^{
        self.shouldStop = NO;
        NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(tim) userInfo:nil repeats:YES];
        [[NSRunLoop currentRunLoop]addTimer:timer forMode:NSDefaultRunLoopMode];
        while(!self.shouldStop){
            [[NSRunLoop currentRunLoop]runUntilDate:[NSDate dateWithTimeIntervalSinceNow:.0001]];
        }
        NSLog(@"runloop后面");
    }];
    [th start];

换成runUntilDate方法,runloop只会执行一段时间,放在while循环里就可以进行控制.

二.Runloop的结构

一个RunLoop包含了多个Mode，也就是跑道,每个Mode又包含了若干个Source/Timer/Observer。每次调用 RunLoop的主函数时，只能指定其中一个Mode，这个Mode被称作CurrentMode。如果需要切换 Mode，只能退出Loop，再重新指定一个Mode.
runloop的结构如下:

struct __CFRunLoop {
     pthread_t _pthread;//线程
    CFMutableSetRef _commonModes;     // commonModes下的两个mode（kCFRunloopDefaultMode和UITrackingMode）
    CFMutableSetRef _commonModeItems; // 在commonModes状态下运行的对象（例如Timer）
    CFMutableSetRef _modes;           // 运行的所有模式（CFRunloopModeRef类）
    CFRunLoopModeRef _currentMode;//在当前loop下运行的mode
    ...
};

struct __CFRunLoopMode {
    CFStringRef _name;            // Mode Name, 例如 @"kCFRunLoopDefaultMode"
    CFMutableSetRef _sources0;    // Set
    CFMutableSetRef _sources1;    // Set
    CFMutableArrayRef _observers; // Array
    CFMutableArrayRef _timers;    // Array
    ...
};

Source/Timer/Observer是事件源, 也就是要执行的任务,RunLoop里面保存的是RunLoopMode，而RunLoopMode中保存的才是实际执行的任务.

@property (nonatomic, strong) dispatch_source_t timer;

self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_global_queue(0, 0));
    dispatch_source_set_timer(self.timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0);
  dispatch_source_set_event_handler(self.timer, ^{
        NSLog(@"lala");
    });
dispatch_resume(self.timer);

这段代码使用GCD创建了一个timer,这里就出现了source
source分为两种

source0:触摸事件，PerformSelectors，非基于Port的
source1:系统内核事件,基于Port的线程间通信

observer:
observer是runloop的监听者,能够监听这几种状态

/* Run Loop Observer Activities */
typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry = (1UL << 0), //即将进入
    kCFRunLoopBeforeTimers = (1UL << 1),//即将处理timer
    kCFRunLoopBeforeSources = (1UL << 2),//即将处理source
    kCFRunLoopBeforeWaiting = (1UL << 5),//即将进入睡眠
    kCFRunLoopAfterWaiting = (1UL << 6),//刚从睡眠中苏醒
    kCFRunLoopExit = (1UL << 7),//即将退出
    kCFRunLoopAllActivities = 0x0FFFFFFFU //所有状态
};

监听runloop需要使用到CoreFoundation 下的CFRunLoop,首先看创建CFRunLoopObserverRef的代码

CFRunLoopRef runloop = CFRunLoopGetCurrent();
CFRunLoopObserverContext context = {
        0,
        (__bridge void *)(self),
        &CFRetain,
        &CFRelease,
        NULL
    };
static CFRunLoopObserverRef observer;
    observer = CFRunLoopObserverCreate(NULL, kCFRunLoopBeforeWaiting, YES, 0, &callBack, &context);
    CFRunLoopAddObserver(runloop, observer, kCFRunLoopCommonModes);

首先需要获取CFRunLoopRef指针,也就是当前runloop
然后调用函数CFRunLoopObserverCreate(<#CFAllocatorRef allocator#>, <#CFOptionFlags activities#>, <#Boolean repeats#>, <#CFIndex order#>, <#CFRunLoopObserverCallBack callout#>, <#CFRunLoopObserverContext context#>)
CFAllocatorRef allocator直接使用NULL,
CFOptionFlags activities指的是前面说到的可以监听的几种状态,
Boolean repeats是否持续监听,
CFIndex order用0,
CFRunLoopObserverCallBack callout是回调函数,需要一个C函数指针,函数的类型是typedef void (CFRunLoopObserverCallBack)(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info);
CFRunLoopObserverContext *context是上下文,它的结构是这样的

typedef struct {
    CFIndex version;
    void *  info;
    const void *(*retain)(const void *info);
    void    (*release)(const void *info);
    CFStringRef (*copyDescription)(const void *info);
} CFRunLoopObserverContext;

CFRunLoopObserverContext的info就是函数CFRunLoopObserverCallBack的参数info.
最后调用CFRunLoopAddObserver函数来执行

创建一个Observer观察者添加到主线程RunLoop的CommonMode模式下观察，创建一个持续的子线程专门用来监控主线程的RunLoop状态，一旦发现进入睡眠前的KCFRunLoopBeforeSource状态，或者唤醒后的状态KCFRunLoopAfterWaiting，在设置的时间阈值内一直没有变化，即可判断为卡顿，根据堆栈的信息，可以分析出是哪个方法比较耗时.

三.Runloop与其他模块相关

释放池
程序启动后,主线程 RunLoop 里注册了两个 Observer，其回调都是 _wrapRunLoopWithAutoreleasePoolHandler()，一是,监测Entry(即将进入Loop)状态,其回调内会调用 _objc_autoreleasePoolPush() 创建自动释放池,其 order 是-2147483647，优先级最高，保证创建释放池发生在其他所有回调之前；另外一个，Observer 监视了两个事件： BeforeWaiting(准备进入休眠) 时调用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 释放旧的池并创建新池；Exit(即将退出Loop) 时调用 _objc_autoreleasePoolPop() 来释放自动释放池。这个 Observer 的 order 是 2147483647，优先级最低，保证其释放池子发生在其他所有回调之后.
UI事件
苹果注册了一个 Source1 (基于 mach port 的) 用来接收系统事件，其回调函数为 __IOHIDEventSystemClientQueueCallback()。
当一个硬件事件(触摸/锁屏/摇晃等)发生后，首先由 IOKit.framework 生成一个 IOHIDEvent 事件并由 SpringBoard 接收。SpringBoard 只接收按键(锁屏/静音等)，触摸，加速，接近传感器等几种 Event，随后用 mach port 转发给需要的App进程。随后苹果注册的那个 Source1 就会触发回调，并调用 _UIApplicationHandleEventQueue() 进行应用内部的分发。
_UIApplicationHandleEventQueue() 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发，其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。
手势
_UIApplicationHandleEventQueue() 识别了一个手势时，其首先会调用 Cancel 将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。苹果注册了一个 Observer 监测 BeforeWaiting (Loop即将进入休眠) 事件，这个Observer的回调函数是 _UIGestureRecognizerUpdateObserver()，其内部会获取所有刚被标记为待处理的 GestureRecognizer，并执行GestureRecognizer的回调。
当有 UIGestureRecognizer 的变化(创建/销毁/状态改变)时，这个回调都会进行相应处理。
GCD
当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会向主线程的 RunLoop 发送消息，RunLoop会被唤醒，并从消息中取得这个 block，并在回调里执行这个 block。Runloop只处理主线程的block，dispatch 到其他线程仍然是由 libDispatch 处理的。

performSelector
除了基于端口的源，Cocoa定义了自定义输入源，允许你在任何线程执行selector方法。和基于端口的源一样，执行selector请求会在目标线程上序列化，减缓许多在线程上允许多个方法容易引起的同步问题。不像基于端口的源，一个selector执行完后会自动从run loop里面移除。
当在其他线程上面执行selector时，目标线程须有一个活动的run loop。对于你创建的线程，这意味着线程在你显式的启动run loop之前是不会执行selector方法的，而是一直处于休眠状态。