RunLoop

最新推荐文章于 2024-06-06 17:43:25 发布

Quarts

最新推荐文章于 2024-06-06 17:43:25 发布

阅读量113

点赞数

分类专栏： iOS RunLoop

本文链接：https://blog.csdn.net/qq_29092185/article/details/105692910

版权

iOS 同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

RunLoop

1 篇文章 0 订阅

订阅专栏

RunLoop 是 Event Loop 模型的一种实现。一般来讲，一个线程一次只能执行一个任务，执行完成后线程就会退出。Event Loop 用于让线程能随时处理事件但并不退出，其代码逻辑是这样的：

function loop() {
	initialize();
	do {
		var message = get_next_message();
		process_message(message);
	} while(message != quit);
}

所以，RunLoop 实际上就是一个对象，这个对象管理了其需要处理的事件和消息，并提供一个入口函数来执行上面 Event Loop 的逻辑。线程执行了这个函数后，就会处于函数内 “接收消息 -> 处理事件 -> 等待消息” 的循环中，直到这个循环结束(比如传入 quit 消息)，函数返回。

在 OSX/iOS 系统中，提供了两个 RunLoop 类：CFRunLoopRef 和 NSRunLoop。
CFRunLoopRef：属于 Core Foundation 框架，提供了纯 C 函数的 API，这些 API 都是线程安全的。
NSRunLoop：属于 Foundation 框架，是基于 CFRunLoopRef 的封装，提供了面向对象的API，但这些 API 不是线程安全的。

CFRunLoopRef 的代码是开源的，所以这里源码部分主要以 CFRunLoopRef 来讲。

RunLoop 与线程的关系

CFRunLoopRef 是基于 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 的创建是发生在第一次获取时(App启动时，主线程的 RunLoop 会自动创建)，RunLoop的销毁是发生在线程的结束时。你只能从一个线程的内部获取其 RunLoop(主线程除外)。

RunLoop 相关的类

在 Core Foundation 中，有关 RunLoop 的类有5个：CFRunLoopRef、CFRunLoopModeRef、CFRunLoopSourceRef、CFRunLoopTimerRef 和 CFRunLoopObserverRef。
CFRunLoopModeRef：是行为模式。一个 RunLoop 包含若干个 Mode，一个 Mode 又包含多个 Source/Timer/Observer。它们的关系如下：
每次调用 RunLoop 的主函数时，只能指定其中一个 Mode。如果需要切换Mode，只能退出Loop，再重新指定一个Mode进入。这样做主要是为了分隔开不同组的 Source/Timer/Observer，让其互相不受影响。
CFRunLoopSourceRef：是事件产生的地方。Source 有两个版本：Source0 和 Source1。

Source0 只包含了一个回调(函数指针。诸如 UIEvent ，performSelector)，它并不能主动触发。使用时，需先调用 CFRunLoopSourceSignal(source)，将这个 source 标记为待处理，然后再手动调用 CFRunLoopWakeUp(runloop) 来唤醒 RunLoop，让其处理这个事件。
Source1 包含了一个 mach_port 和一个回调(函数指针)。被用于通过内核和其他线程相互发送消息，这种 Source 能主动唤醒 RunLoop。如何应用？？？
CFRunLoopTimerRef：是基于时间的触发器。它和 NSTimer 是 toll-free bridge 的，两者可以混用。其包含一个时间长度和一个回调(函数指针)。当其加入到 RunLoop 时，RunLoop 会注册对应的时间点，当时间点到时，RunLoop 就会被唤醒执行那个回调。RunLoop 为了节省资源并不会非常准确的在时间点到达的时候触发回调，如果一个任务执行时间较长，那么当错过一个时间点后只能等到下个时间点执行，并不会延后执行(NSTimer 提供了一个 tolerance 属性用于设置宽容度，如果确实想要使用 NSTimer 并且希望尽可能的准确，则可以设置此属性)。 RunLoop 怎么节省资源？？？
CFRunLoopObserverRef是观察者。每个 Observer 都包含了一个回调(函数指针)，当 RunLoop 的状态发生改变时，Observer 就能通过回调接收到这个变化。可以观测的状态有以下几个：

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

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

RunLoop 的 Mode

CFRunLoopMode 和 CFRunLoop 的结构大致如下：

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

struct __CFRunLoop {
	CFMutableSetRef _commonModes; 	   // Set
	CFMutableSetRef _commonModeItems;  // Set<Source/Observer/Timer>
	CFRunLoopModeRef _currentMode;     // Current RunLoop Mode
	CFMutableSetRef _modes; 		   // Set
	...
};

苹果公开提供的 Mode 有两个：kCFRunLoopDefaultMode(NSDefaultRunLoopMode) 和 UITrackingRunLoopMode(其他线程只有 DefaultMode)。DefaultMode 是 App 平时所处的状态，是所有 RunLoop 的默认 Mode；TrackingMode 是追踪 ScrollView 滑动时的状态。也可以定义自己的 Mode，当我们传入一个新的 ModeName，但 RunLoop 内部没有对应的 Mode 时，RunLoop 会自动帮我们创建对应的 CFRunLoopModeRef。

当 RunLoop 运行在一个 Mode 上时，是无法接受处理其他 Mode 上的 Source/Timer/Observer 事件的。例如：当我们创建一个 Timer 并加到 DefaultMode 时，Timer会得到重复回调。但此时滑动一个 TableView 时，RunLoop 会将 Mode 切换为 TrackingMode，这时 Timer就不会被回调，并且也不会影响到滑动操作。

这里有个概念叫 “CommonModes”：一个 Mode 可以将自己标记为 “Common” 属性(通过将其 ModeName 添加到 RunLoop 的 “commonModes” 中)。在 RunLoop 的内容发生变化时，RunLoop 会自动将 _commonModeItems 里的 Source/Timer/Observer 同步到具有 “Common” 标记的所有 Mode 里。

如果我们想要 Timer 在两个 Mode 下都能得到回调，则可以将 Timer 加到两个 Mode 下，或将 Timer 加入到顶层 RunLoop 的 commonModeItems 中。RunLoop 会自动将 commonModeItems 更新到具有 “Common” 属性的 Mode 中。

RunLoop 的内部逻辑

RunLoo的内部代码整理如下：

// 用 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, 直接返回。
    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);
}

没错！就是这个 do-while 循环。其内部逻辑大致如下：

苹果用 RunLoop 实现的功能

事件响应

苹果注册了一个 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 事件都是在这个回调中完成的。

手势识别

当上面的 __UIApplicationHandleQueue() 识别了一个手势时，其首先会调用 Cancel 将当前的 touchesBegin/Move/End 系列回调打断。随后系统将对应的 UIGestureRecognizer 标记为待处理。

苹果注册了一个 Observer 监测 BeforeWaiting(Loop即将进入休眠)事件，这个 Observer 的回调函数是 __UIGestureRecognizerUpdateObserver()，其内部会获取所有被标记为待处理的 GestureRecognizer，并执行 GestureRecognizer的回调。

当有 UIGestureRecognizer 的变化(创建/销毁/状态改变)时，这个回调都会进行相应的处理。

界面更新

当在操作 UI 时，比如改变了 Frame、更新了 UIView/CALayer 的层次时，或者手动调用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay 方法后，这个 UIView/CALayer 就被标记为待处理，并被提交到一个全局容器去。

苹果注册一个 Observer 监听 BeforeWaiting(Loop即将进入休眠) 和 Exit(即将退出Loop) 事件，回调去执行： _ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。在这个函数里会遍历所有待处理的 UIView/CALayer 以执行实际的绘制和调整，并更新 UI 界面。

定时器

CADisplayLink 是一个和屏幕刷新率一致的定时器(但实际原理更复杂，和 NSTimer 并不一样，其内部实际是操作了一个 Source)。如果在两次屏幕刷新之间执行了一个长任务，那其中就会有一帧被跳过去(和 NSTimer 相似)，造成界面卡顿。Facebook 开源的 AsyncDisplayLink 就是为了解决界面卡顿的问题，其内部也用到了 RunLoop。

PerformSelector

当调用 NSObject 的 performSelector: afterDelay: 后，实际上其内部会创建一个 Timer 并添加到当前线程的 RunLoop 中。所以如果当前线程没有 RunLoop，则这个方法会失效。performSelector: onThread: 方法也相同。

AFNetworking 中 RunLoop 的运用

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

- (void)start {
	[self.lock lock];
	if([self isCancelled]) {
		[self performSelector:@selector(cancelConnection) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
	} else if([self isReady]) {
		self.state = AFOperationExecutingState;
		[self performSelector:@selector(operationDidStart) onThread:[[self class] networkRequestThread] withObject:nil waitUntilDone:NO modes:[self.runLoopModes allObjects]];
	}
	[self.lock unlock];
}