博客> 深入理解RunLoop
深入理解RunLoop
2018-08-15 00:36 评论:0 阅读:247 唐秦风
深入理解RunLoop

作为一个开发者,有一个学习的氛围跟一个交流圈子特别重要,小编的qq群:686183764 不管你是小白还是大牛欢迎入驻 ,分享面试题、面试经验,讨论技术, 大家一起交流学习成长!进群有群主精心整理资料领取!

RunLoop 是 iOS 和 OS X 开发中非常基础的一个概念,这篇文章将从 CFRunLoop 的源码入手,介绍 RunLoop 的概念以及底层实现原理。之后会介绍一下在 iOS 中,苹果是如何利用 RunLoop 实现自动释放池、延迟回调、触摸事件、屏幕刷新等功能的。

问题

当scroll滑动时,同页面上的定时器为什么会暂停? 怎么在tableview滑动时延迟加载图片来提高流畅度? 常说的AFNetworking常驻线程保活是什么原理?

其实上述问题都与RunLoop有关系,要想弄清楚其中的原因,就需要理解RunLoop到底是什么?

RunLoop

让线程能随时处理事件但并不退出的一种机制 我们知道每个程序的入口都是main函数:

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

就这么几行代码,可是不应该是代码执行完后程序就结束了吗?那我们见到的程序是怎么能长时间保持在活跃状态的?这一切都是RunLoop的功劳,其实UIApplicationMain()会创建主线程,主线程内部会主动开启一个RunLoop,而RunLoop本质上就是一个do-while循环,只要条件满足,就会不停的循环,进而程序一直保持运行的状态。RunLoop源码:

void CFRunLoopRun(void) {    /* DOES CALLOUT */
    int32_t result;
    do {
        result = CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
        CHECK_FOR_FORK();
    } while (kCFRunLoopRunStopped != result && kCFRunLoopRunFinished != result);
}

RunLoop 与线程的关系

首先,iOS 开发中能遇到两个线程对象: pthread_t 和 NSThread。过去苹果有份[文档](http://www.fenestrated.net/~macman/mirrors/Apple Technotes (As of 2002)/tn/tn2028.html)标明了 NSThread 只是 pthread_t 的封装,但那份文档已经失效了,现在它们也有可能都是直接包装自最底层的 mach thread。苹果并没有提供这两个对象相互转换的接口,但不管怎么样,可以肯定的是 pthread_t 和 NSThread 是一一对应的。比如,你可以通过 pthread_main_np() 或 [NSThread mainThread] 来获取主线程;也可以通过 pthread_self() 或 [NSThread currentThread] 来获取当前线程。CFRunLoop 是基于 pthread 来管理的。

苹果不允许直接创建 RunLoop,它只提供了两个自动获取的函数:CFRunLoopGetMain() 和 CFRunLoopGetCurrent()。 这两个函数内部的逻辑大概是下面这样:

/// 全局的Dictionary,key 是 pthread_t, value 是 CFRunLoopRef
static CFMutableDictionaryRef loopsDic;
/// 访问 loopsDic 时的锁
static CFSpinLock_t loopsLock;

/// 获取一个 pthread 对应的 RunLoop。
CFRunLoopRef _CFRunLoopGet(pthread_t thread) {
    OSSpinLockLock(&loopsLock);

    if (!loopsDic) {
        // 第一次进入时,初始化全局Dic,并先为主线程创建一个 RunLoop。
        loopsDic = CFDictionaryCreateMutable();
        CFRunLoopRef mainLoop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, pthread_main_thread_np(), mainLoop);
    }

    /// 直接从 Dictionary 里获取。
    CFRunLoopRef loop = CFDictionaryGetValue(loopsDic, thread));

    if (!loop) {
        /// 取不到时,创建一个
        loop = _CFRunLoopCreate();
        CFDictionarySetValue(loopsDic, thread, loop);
        /// 注册一个回调,当线程销毁时,顺便也销毁其对应的 RunLoop。
        _CFSetTSD(..., thread, loop, __CFFinalizeRunLoop);
    }

    OSSpinLockUnLock(&loopsLock);
    return loop;
}

CFRunLoopRef CFRunLoopGetMain() {
    return _CFRunLoopGet(pthread_main_thread_np());
}

CFRunLoopRef CFRunLoopGetCurrent() {
    return _CFRunLoopGet(pthread_self());
} 

从上面的代码可以看出,线程和 RunLoop 之间是一一对应的,其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop,如果你不主动获取,那它一直都不会有。RunLoop 的创建是发生在第一次获取时,RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop(主线程除外)。

RunLoop 对外的接口

在 CoreFoundation 里面关于 RunLoop 有5个类:

CFRunLoopRef CFRunLoopModeRef CFRunLoopSourceRef CFRunLoopTimerRef CFRunLoopObserverRef

其中 CFRunLoopModeRef 类并没有对外暴露,只是通过 CFRunLoopRef 的接口进行了封装。他们的关系如下: RunLoop_0.png

可以看出,一个RunLoop里面可以有多个mode,每个mode又可以多个source,observer,timer。可是每次RunLoop只能指定一个mode运行,如果想要切换mode,就必须先退出RunLoop,然后重新指定mode运行,这样做的目的就是避免mode之间相互影响

CFRunLoopSourceRef

创建RunLoop时,系统默认注册了五种mode:

1. kCFRunLoopDefaultMode: 默认 mode,通常主线程在这个 mode 下运行
2. UITrackingRunLoopMode: 追踪mode,保证Scrollview滑动顺畅不受其他 mode 影响
3. UIInitializationRunLoopMode: 启动程序后的过渡mode,启动完成后就不再使用
4: GSEventReceiveRunLoopMode: Graphic相关事件的mode,通常用不到
5: kCFRunLoopCommonModes: 占位用的mode,作为标记kCFRunLoopDefaultMode和UITrackingRunLoopMode用
CFRunLoopTimerRef

基于时间的触发器,它和 NSTimer 是toll-free bridged 的,可以混用。其包含一个时间长度和一个回调(函数指针)。当其加入到 RunLoop 时,RunLoop会注册对应的时间点,当时间点到时,RunLoop会被唤醒以执行那个回调

CFRunLoopSourceRef

事件产生的地方,分为Source0Source1两种

Source0: 只包含了一个回调(函数指针),它并不能主动触发事件。使用时,你需要先调用 CFRunLoopSourceSignal(source),将这个 Source 标记为待处理,然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop,让其处理这个事件 Source1: 包含了一个 mach_port 和一个回调(函数指针),被用于通过内核和其他线程相互发送消息。这种 Source 能主动唤醒 RunLoop 的线程

CFRunLoopObserverRef

观察者,每个 Observer 都包含了一个回调(函数指针),当 RunLoop 的状态发生变化时,观察者就能通过回调接受到这个变化。可以观测的时间点有以下几个:

typedef CF_OPTIONS(CFOptionFlags, CFRunLoopActivity) {
    kCFRunLoopEntry         = (1UL <&lt; 0), // 即将进入Loop
    kCFRunLoopBeforeTimers  = (1UL <&lt; 1), // 即将处理 Timer
    kCFRunLoopBeforeSources = (1UL <&lt; 2), // 即将处理 Source
    kCFRunLoopBeforeWaiting = (1UL <&lt; 5), // 即将进入休眠
    kCFRunLoopAfterWaiting  = (1UL <&lt; 6), // 刚从休眠中唤醒
    kCFRunLoopExit          = (1UL <&lt; 7), // 即将退出Loop
};

上面的 Source/Timer/Observer 被统称为 mode item,一个 item 可以被同时加入多个 mode。但一个 item 被重复加入同一个 mode 时是不会有效果的。如果一个 mode 中一个 item 都没有,则 RunLoop 会直接退出,不进入循环。

RunLoop 的内部逻辑

根据苹果在文档里的说明,RunLoop 内部的逻辑大致如下:

1432798974517485.png

实际上 RunLoop 就是这样一个函数,其内部是一个 do-while 循环。当你调用 CFRunLoopRun() 时,线程就会一直停留在这个循环里;直到超时或被手动停止,该函数才会返回。

RunLoop 的核心就是一个 mach_msg(),当一个RunLoop处理完事件后,即将进入休眠时,会经历下面几步:

  1. 指定一个将来唤醒自己的mach_port端口

  2. 调用mach_msg来监听这个端口,保持mach_msg_trap状态

  3. 由另一个线程(比如有可能有一个专门处理键盘输入事件的loop在后台一直运行)向内核发送这个端口的msg后,mach_msg_trap状态被唤醒,RunLoop继续运行

mach相关方法涉及到内核,这里不做深入。

常说的AFNetworking常驻线程保活是什么原理? 我们知道,当子线程中的任务执行完毕之后就被销毁了,那么如果我们需要开启一个子线程,在程序运行过程中永远都存在,那么我们就会面临一个问题,如何让子线程永远活着,答案就是给子线程开启一个RunLoop,下面是AFNetworking相关源码:

+ (void)networkRequestThreadEntryPoint:(id)__unused object {
    @autoreleasepool {
        [[NSThread currentThread] setName:@"AFNetworking"];
        NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
        [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
        [runLoop run];
    }
}

+ (NSThread *)networkRequestThread {
    static NSThread *_networkRequestThread = nil;
    static dispatch_once_t oncePredicate;
    dispatch_once(&oncePredicate, ^{
        _networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
        [_networkRequestThread start];
    });
    return _networkRequestThread;
}

RunLoop 启动前内部必须要有至少一个 Timer/Source,所以 AFNetworking 在 [runLoop run] 之前先创建了一个新的 NSMachPort 添加进去了。通常情况下,调用者需要持有这个 NSMachPort (mach_port) 并在外部线程通过这个 port 发送消息到 loop 内;但此处添加 port 只是为了让 RunLoop 不至于退出,并没有用于实际的发送消息。

事件响应

当一个事件(触摸/锁屏/摇晃等)发生后,首先由 SpringBoard 接收,随后用 mach port 转发给需要的App进程,从而触发进程的Source1 (基于 mach port ,提前注册用来接收系统事件的Source)的回调_UIApplicationHandleEventQueue(),把事件包装成 UIEvent 进行处理或分发(之后的事件分发处理,可以看从用户点击屏幕到程序作出反应之间都发生了什么? --- iOS事件响应)。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的

这里有一点值得注意,当我们点击一个按钮后,进行断点调试可以发现调用的函数栈里显示的是Source0:

_UIApplicationHandleEventQueue() 会把 IOHIDEvent 处理并包装成 UIEvent 进行处理或分发,其中包括识别 UIGesture/处理屏幕旋转/发送给 UIWindow 等。通常事件比如 UIButton 点击、touchesBegin/Move/End/Cancel 事件都是在这个回调中完成的。 1487819244561630.png 原因:首先是由那个Source1 接收事件,之后在回调内触发的 Source0,Source0 再触发的 _UIApplicationHandleEventQueue()进行事件分发和处理。所以UIButton事件看到是在 Source0 内的。

线程

RunLoop的寄生于线程:一个线程只能有唯一对应的RunLoop,但这个根RunLoop里可以嵌套子RunLoop,主线程的RunLoop自动创建,子线程的RunLoop默认不创建,在子线程中调用NSRunLoop.current获取RunLoop对象的时候,就会创建RunLoop

界面刷新

当在操作 UI 时,比如改变了 Frame、更新了 UIView/CALayer 的层次时,或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后,这个 UIView/CALayer 就被标记为待处理,并被提交到一个全局的容器去。苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件,回调去执行一个很长的函数:

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整,并更新 UI 界面。

乔布斯.jpg

收藏
0
sina weixin mail 回到顶部