Runloop是什么?
在app启动之后,是什么在管理着任务的运行,当你的手点击屏幕之后,应用程序是如何识别到你的点击,并且进行对应的响应,这些都是runloop的运行机制在起着作用。本文将深入浅出的介绍runloop。
Runloop就是一个对象,这个对象管理了其需要处理的事件和消息,并提供了一个入口函数来执行一个event loop的逻辑(线程在没有处理消息是,休眠以避免资源占用,在有消息到来时立刻被唤醒)。线程执行了这个函数之后,就会一直处于这个函数内部
“接收消息->等待->处理”的循环中,直到这个循环结束(比如传入quit消息),函数返回。
线程和RunLoop是一一对应的。当我们运行一个应用程序,里面哪怕没有任何界面和功能的时候,系统都会帮我们自动起一个主线程的runloop。
其他线程的runloop会自动帮我们创建么?不会,其他线程的Runloop是懒加载的,线程和RunLoop是一一对应的,其关系是保持在一个全局的Dictionary里,线程刚创建是没有RunLoop,如果你不去主动获取,那它就一直不会有,RunLoop的创建是在第一次获取时,RunLoop的销毁是在线程结束时,你只能在一个线程的内部获取其RunLoop。
Runloop运行原理
Runloop的基本概念与结构:
一个RunLoop包含若干个mode,每个mode又包含若干个Source/Timer/Observer。每次调用RunLoop的主函数时,只能指定期中一个mode,这个mode被称作currentMode,如果需要切换Mode,只能退出loop,再重新指定一个Mode进入。这样做主要是为了分隔开不同组的Source/Timer/Observer,让其互不影响。
Source有两个版本:Source0 和 Source1
-
Source0
应用内事件 -
Source1
基于mach_port的,来自系统内核或者其他进程或者线程的事件 -
timer
是基于时间的触发器,它和 NSTimer 是toll-free bridged 的,可以混用。其包含一个时间长度和一个回调(函数指针)。当其加入到 RunLoop 时,RunLoop会注册对应的时间点,当时间点到时,RunLoop会被唤醒以执行那个回调。 -
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运行模式的介绍
OC/swift:介绍-
NSRunLoopCommonModes/common:公有mode,
-
NSDefaultRunloopMode/’default’:默认的运行模式,通常主线程是在这个Mode下运行的。
-
UITrackingRunLoopMode/tracking:手势滑动时的模式,比如scrollView滑动的时候。
-
NSEventTrackingRunLoopMode/eventTracking:拖动事件发生的时候,比如鼠标滑动。感觉是mac开发的模式
-
NSModalPanelRunLoopMode/modalPanel:当等待来自模态面板的输入时设置的模式,例如保存或打开面板。感觉是mac开发的模式
-
NSRunLoopCommonModes是干嘛用的?一个 Mode 可以将自己标记为”Common”属性(通过将其 ModeName 添加到 RunLoop 的 “commonModes” 中)。每当 RunLoop 的内容发生变化时,RunLoop 都会自动将 commonModeItems 里的 Source/Observer/Timer 同步到具有 “Common” 标记的所有Mode里。通俗的讲,当你想把一个事件添加到不同的mode当中去的时候,一个一个添加,很麻烦,这时候直接添加到NSRunLoopCommonModes当中即可。因为系统会帮我们自动同步过去。NSRunLoopCommonModes默认已经有NSDefaultRunloopMode、UITrackingRunLoopMode。
Runloop是如何运行与处理事件的?
先看下图
别看这个这么复杂,其实很好理解,我把它分为2部分,其中一部分是runloop就是通知外部Observer自己的各种状态,另外一部分是事件处理,先处理source0,处理完休眠等待,source1就是外部的唤醒事件,然后这个事件会转成source0处理(跳回2)。
下面是runloop的源码:
/// 用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);
}
可以看到,实际上 RunLoop 就是这样一个函数,其内部是一个 do-while 循环。当你调用 CFRunLoopRun() 时,线程就会一直停留在这个循环里;直到超时或被手动停止,该函数才会返回。
Runloop的接口整理与解释
有一些功能和接口并没有在RunLoop中暴露,但是可以用CFRunloop实现,RunLoop是对其的封装,我以CFRunLoop接口为例
//
class var current: RunLoop { get } //当前的runloop
var currentMode: RunLoop.Mode? { get }//当前的运行中的mode
class var main: RunLoop { get }//主线程对应的runloop
//
func limitDate(forMode mode: RunLoop.Mode) -> Date?//下一次运行的时间
func getCFRunLoop() -> CFRunLoop//当前runloop的cfRunloop对象
//add & remove
func add(_ timer: Timer,forMode mode: RunLoop.Mode)
func add(_ aPort: Port,forMode mode: RunLoop.Mode)
func remove(_ aPort: Port,forMode mode: RunLoop.Mode)
//-run runloop
func run()
//指定的日期前运行一次
func run(mode: RunLoop.Mode,before limitDate: Date) -> Bool
//在指定日期到来前,一直运行runloop
func run(until limitDate: Date)
//运行循环一次或直到指定日期,仅接受指定模式的输入
func acceptInput(forMode mode: RunLoop.Mode,before limitDate: Date)
//-Scheduling and Canceling Tasks
func perform(_ block: @escaping @Sendable () -> Void)
func perform(inModes modes: [RunLoop.Mode],
block:@escaping @Sendable () ->Void)
func perform(
_ aSelector: Selector,
target: Any,
argument arg: Any?,
order: Int,
modes: [RunLoop.Mode]
)
func cancelPerform(
_ aSelector: Selector,
target: Any,
argument arg: Any?
)
func cancelPerformSelectors(withTarget target: Any)
//Scheduling Combine Publishers
func schedule(
options: RunLoop.SchedulerOptions?,
_ action: @escaping () -> Void
)
func schedule(
after date: RunLoop.SchedulerTimeType,
tolerance: RunLoop.SchedulerTimeType.Stride,
options: RunLoop.SchedulerOptions?,
_ action: @escaping () -> Void
)
func schedule(
after date: RunLoop.SchedulerTimeType,
interval: RunLoop.SchedulerTimeType.Stride,
tolerance: RunLoop.SchedulerTimeType.Stride,
options: RunLoop.SchedulerOptions?,
_ action: @escaping () -> Void
) -> Cancellable
var minimumTolerance: RunLoop.SchedulerTimeType.Stride { get }
var now: RunLoop.SchedulerTimeType { get }
Runloop的应用:
iOS系统在应用程序中的应用
- AutoreleasePool
自动释放池的销毁和创建依赖与runloop的通知,即将进入runloop的时候创建自动释放池,准备进入休眠的时候调用_objc_autoreleasePoolPop释放旧的池,调用_objc_autoreleasePoolPush创建新池,在即将退出runloop的通知力,销毁自动释放池
- 事件响应
苹果注册了一个 Source1 (基于 mach port 的) 用来接收系统事件,其回调函数为 __IOHIDEventSystemClientQueueCallback()。
当一个硬件事件触发后,首先由IOKIT.framework生成一个IOHIDEvent事件并由storyboard接受,随后用mach port转给需要的App进程,随后苹果注册的那个Source1就会回调,并调用UIApplicationHandleEventQueue()进行应用内部分发。关于应用内的事件分发和响应者链可以参考这篇文档:事件处理
- 手势识别
当上面的UIApplicationHandleEventQueue识别了个手势时,其首先会调用cancel将当前的touchesBegin/move/end系列回调打断,随意将此手势标记为待处理
苹果注册了个observer回调监测Loop即将进入休眠时间,这个Observer的回调函数是_UIGestureRecognizerUpdateObserver(),其内部会获取所有刚被标记为待处理的 GestureRecognizer,并执行GestureRecognizer的回调。
- 界面更新
当操作UI时,改变了Frame,更新了UIView/CALayer的层次时,setNeedsLayout/setNeedsDisplay,这个UIView/CALayer就会被标记为待处理,并被提交到一个全局的容器中去。
苹果注册了一个 Observer 监听 BeforeWaiting(即将进入休眠) 和 Exit (即将退出Loop) 事件,回调去执行一个很长的函数:
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。这个函数里会遍历所有待处理的 UIView/CAlayer 以执行实际的绘制和调整,并更新 UI 界面。
自己运用Runloop可以做的事情
- 线程保活
当一个子线程做完了所有的事情后,线程会被销毁,那么该如何让一个线程一直在运行而不被销毁呢,我们可以让runloop在线程中运行,没有什么事情的时候休眠,必要的时候唤醒它处理事件,比如AFNetworking
[[NSThread currentThread] setName:@"AFNetworking"];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
RunLoop 启动前内部必须要有至少一个 Timer/Observer/Source,所以 AFNetworking 在 [runLoop run] 之前先创建了一个新的 NSMachPort 添加进去了。
当需要这个后台线程执行任务时,AFNetworking 通过调用 [NSObject performSelector:onThread:..] 将这个任务扔到了后台线程的 RunLoop 中。
- 监控卡顿A
通过监控主线程的RunLoop的状态来判断是否会出现卡顿
iOS 之如何利用 RunLoop 原理去监控卡顿?
面试题以及答案整理
如果你搞懂了上面的原理,那么基本遇到任何问题都能回答上来,我这里还是列举一些问题,大家可以以此来看看自己对于这些知识的掌握程度。
参考资料
深入理解RunLoop: blog.ibireme.com/2015/05/18/…
iOSRunLoop详解:juejin.cn/post/684490…
基于runloop的线程保活、销毁与通信:www.jianshu.com/p/4d5b6fc33…