逃不出的圈子 — RunLoop

原文

RunLoop,顾名思义就是跑圈,相信每个iOS开发者都听闻过,但是好多人都是一知半解,毋庸置疑,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在这机制的关键在于:如何管理事件/消息,如何让线程在没有处理消息时休眠以避免资源占用、在有消息到来时立刻被唤醒

要了解这种机制,我们只有进一步分析源代码了。我们先看看RunLoop相关的API:

  • CFRunLoopRef:CoreFoundation 框架内的,基于C语言

  • NSRunLoop:基于CFRunLoopRef的进一步封装,提供了面向对象的 API

所以我们下面都是基于对CFRunLoopRef的源码分析,在 CoreFoundation 里面关于 RunLoop 有5个类:

CFRunLoopRef //就是RunLoop,提供CFRunLoopGetMain()和CFRunLoopGetCurrent()
CFRunLoopModeRef //RunLoop运行模式
CFRunLoopSourceRef //RunLoop里面内容 -- 事件源,输入源
CFRunLoopTimerRef //RunLoop里面内容 -- 定时器
CFRunLoopObserverRef //RunLoop里面内容 -- 观察者

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

CFRunLoopModeRef

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

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

当scroll滑动时,同页面上的定时器为什么会暂停?

这个问题在这里就能得到解释了,当你用

func scheduledTimer(withTimeInterval interval: TimeInterval, repeats: Bool, block: @escaping (Timer) -> Swift.Void) -> Timer

创建一个timer时,系统默认把timer添加到kCFRunLoopDefaultMode模式中,但是当页面滚动的时候,RunLoop的Mode会自动切换成UITrackingRunLoopMode模式,因此timer失效,当停止滑动,RunLoop又会切换回NSDefaultRunLoopMode模式,因此timer又会重新启动了。

kCFRunLoopCommonModes的存在就是来解决这个问题的,RunLoop运行时,会把kCFRunLoopCommonModes中的资源下发到每一个NSDefaultRunLoopMode和UITrackingRunLoopMode中,所以

let timer = Timer.init(timeInterval: 1, repeats: true) { }
RunLoop.main.add(timer, forMode: .commonModes)

怎么在tableview滑动时延迟加载图片来提高流畅度?

这个问题也是同理,把加载图片放入NSDefaultRunLoopMode模式中就可以避免了:

[self.imageView performSelector:@selector(setImage:) withObject:[UIImage imageNamed:@"abc"] afterDelay:2.0 inModes:@[NSDefaultRunLoopMode]];

CFRunLoopSourceRef

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

  • Source0: 只包含了一个回调(函数指针),它并不能主动触发事件。使用时,你需要先调用 CFRunLoopSourceSignal(source),将这个 Source 标记为待处理,然后手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop,让其处理这个事件

  • Source1: 包含了一个 mach_port 和一个回调(函数指针),被用于通过内核和其他线程相互发送消息。这种 Source 能主动唤醒 RunLoop 的线程

CFRunLoopTimerRef

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

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" };

其中最重要就是,休眠与唤醒之间的切换,核心代码:

/// 用DefaultMode启动
void CFRunLoopRun(void) {
    CFRunLoopRunSpecific(CFRunLoopGetCurrent(), kCFRunLoopDefaultMode, 1.0e10, false);
}
 
/// 用指定的Mode启动,允许设置RunLoop超时时间
int CFRunLoopRunInMode(CFStringRef modeName, CFTimeInterval seconds, Boolean stopAfterHandle) {
    return CFRunLoopRunSpecific(CFRunLoopGetCurrent(), modeName, seconds, returnAfterSourceHandled);
}
 
/// RunLoop的实现
int CFRunLoopRunSpecific(runloop, modeName, seconds, stopAfterHandle) {
    
    /// 首先根据modeName找到对应mode
    CFRunLoopModeRef currentMode = __CFRunLoopFindMode(runloop, modeName, false);
    /// 如果mode里没有source/timer/observer, 直接返回。
    if (__CFRunLoopModeIsEmpty(currentMode)) return;
    
    /// 1. 通知 Observers: RunLoop 即将进入 loop。
    __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopEntry);
  
    /// 内部函数,进入loop
    __CFRunLoopRun(runloop, currentMode, seconds, returnAfterSourceHandled) {
       
        Boolean sourceHandledThisLoop = NO;
        int retVal = 0;
        do {
 
            /// 2. 通知 Observers: RunLoop 即将触发 Timer 回调。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeTimers);
            /// 3. 通知 Observers: RunLoop 即将触发 Source0 (非port) 回调。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeSources);
            /// 执行被加入的block
            __CFRunLoopDoBlocks(runloop, currentMode);
            
            /// 4. RunLoop 触发 Source0 (非port) 回调。
            sourceHandledThisLoop = __CFRunLoopDoSources0(runloop, currentMode, stopAfterHandle);
            /// 执行被加入的block
            __CFRunLoopDoBlocks(runloop, currentMode);
 
            /// 5. 如果有 Source1 (基于port) 处于 ready 状态,直接处理这个 Source1 然后跳转去处理消息。
            if (__Source0DidDispatchPortLastTime) {
                Boolean hasMsg = __CFRunLoopServiceMachPort(dispatchPort, &msg)
                if (hasMsg) goto handle_msg;
            }
           
            /// 通知 Observers: RunLoop 的线程即将进入休眠(sleep)。
            if (!sourceHandledThisLoop) {
                __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopBeforeWaiting);
            }
           
            /// 7. 调用 mach_msg 等待接受 mach_port 的消息。线程将进入休眠, 直到被下面某一个事件唤醒。
            /// ?一个基于 port 的Source 的事件。
            /// ?一个 Timer 到时间了
            /// ?RunLoop 自身的超时时间到了
            /// ?被其他什么调用者手动唤醒
            __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort) {
                mach_msg(msg, MACH_RCV_MSG, port); // thread wait for receive msg
            }
 
            /// 8. 通知 Observers: RunLoop 的线程刚刚被唤醒了。
            __CFRunLoopDoObservers(runloop, currentMode, kCFRunLoopAfterWaiting);
            
            /// 收到消息,处理消息。
            handle_msg:
 
            /// 9.1 如果一个 Timer 到时间了,触发这个Timer的回调。
            if (msg_is_timer) {
                __CFRunLoopDoTimers(runloop, currentMode, mach_absolute_time())
            } 
 
            /// 9.2 如果有dispatch到main_queue的block,执行block。
            else if (msg_is_dispatch) {
                __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
            } 
 
            /// 9.3 如果一个 Source1 (基于port) 发出事件了,处理这个事件
            else {
                CFRunLoopSourceRef source1 = __CFRunLoopModeFindSourceForMachPort(runloop, currentMode, livePort);
                sourceHandledThisLoop = __CFRunLoopDoSource1(runloop, currentMode, source1, msg);
                if (sourceHandledThisLoop) {
                    mach_msg(reply, MACH_SEND_MSG, reply);
                }
            }
           
            /// 执行加入到Loop的block
            __CFRunLoopDoBlocks(runloop, currentMode);
           
 
            if (sourceHandledThisLoop && stopAfterHandle) {
                /// 进入loop时参数说处理完事件就返回。
                retVal = kCFRunLoopRunHandledSource;
            } else if (timeout) {
                /// 超出传入参数标记的超时时间了
                retVal = kCFRunLoopRunTimedOut;
            } else if (__CFRunLoopIsStopped(runloop)) {
                /// 被外部调用者强制停止了
                retVal = kCFRunLoopRunStopped;
            } else if (__CFRunLoopModeIsEmpty(runloop, currentMode)) {
                /// source/timer/observer一个都没有了
                retVal = kCFRunLoopRunFinished;
            }
           
            /// 如果没超时,mode里没空,loop也没被停止,那继续loop。
        } while (retVal == 0);
    }
    
    /// 10. 通知 Observers: RunLoop 即将退出。
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
}

具体流程表现为下图:

看到有些人指出图中第七步中,Source0应该改为Source1,因为只有Source1能主动唤醒RunLoop,但是这里没有强调是主动唤醒,Source0也可以通过手动来唤醒。而且这里Source0后面有标注基于port,猜测这种Source0可能是基于port 的Source1分发出来的。

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 不至于退出,并没有用于实际的发送消息。

ps.RunLoop 启动前内部就算有一个observer也是会返回的。源代码:

__CFRunLoopModeIsEmpty
{
if (NULL != rlm->_sources0 && 0 _sources0)) return false;
if (NULL != rlm->_sources1 && 0 _sources1)) return false;
if (NULL != rlm->_timers && 0 _timers)) return false;
}

注意点

  • AutoreleasePool

App启动后,苹果在主线程 RunLoop 里注册了两个 Observer:

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

第二个 Observer 监视了两个事件: BeforeWaiting(准备进入休眠) 时调用_objc_autoreleasePoolPop() 和 _objc_autoreleasePoolPush() 释放旧的池并创建新池;Exit(即将退出Loop) 时调用 _objc_autoreleasePoolPop() 来释放自动释放池。这个 Observer 的 order 是 2147483647,优先级最低,保证其释放池子发生在其他所有回调之后。

在主线程执行的代码,通常是写在诸如事件回调、Timer回调内的。这些回调会被 RunLoop 创建好的 AutoreleasePool 环绕着,所以不会出现内存泄漏,开发者也不必显示创建 Pool 了

  • GCD

GCD与RunLoop是平级合作关系,GCD的timer跟RunLoop没关系,只是调用点在RunLoop上,需要注意的是,GCD中的dispatch到mainqueue的block被分发到RunLoop.main执行

  • 事件响应

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

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

原因:首先是由那个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 界面。

参考:

IT文库 » 逃不出的圈子 — RunLoop
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址