最近看了 sunny 大神 runloop 视频,做的学习笔记
上百度云地址:
链接: http://pan.baidu.com/s/1mhGECoK 密码: dv7w
命令模式与事件驱动模式
命令模式,从前往后调用
int main(int argc, char * argv[]) {
NSLog(@"hello world");
return 0;
}
事件驱动模式: iOS runloop vs android looper message handler
int main(int argc, char * argv[]) {
while (AppIsRunning) {
id whoWakesMe = SleepForWakingUp;
id event = GetEvent(whoWakesMe);
HandleEvent(event);
}
return 0;
}
什么是 Runloop
就如 Runloop 名字一样,它是一种循环.可以在循环中睡眠也可以被数据源消息唤醒.app 的运行离不开 runloop,比如有点击事件为什么有响应,在没有工作时候,手机为什么能够比较省点,这都是 runloop 带来的好处.当 app 启动时候,会启动一个主线程,并且启动主线程的 runloop, 每个线程都有一个runloop, 但是只有主线程的runloop是默认开启的,其他子线程需要调用NSRunLoop *runloop = [NSRunLoop currentRunLoop]; 获取runloop的同时就会创建runloop.一个线程可以创建多个runloop,但是可以支持嵌套模式(在 tracking mode 时候体现).也就是一个线程只有一个根runloop.
runloop 主要作用
- 使mainThread(app) 一直运行, 并接受用户输入等事件源,给 thread 发送的事件
- 可以决定程序什么时候处理事件
- 调用方面解耦(比如用户划屏幕,会产生 n 个事件,但是用户不可能等待事件被执行完了再进行下一步的动作,也就是会将此系列的事件丢到一个 message queue 中,每次从消息队列中调取,因此实现主调方和被调方的解耦)
- runloop 会在线程空闲时候,使线程进入sleep 状态,省电
日常中使用的可能与 runloop 相关的有以下几个方面
- NSTimer 完全依赖 runloop 运行
- UIEvent 事件的产生到分发给相应的事件处理函数都通过 runloop (souece0)
- Autorelease自动释放池,需要监听 runloop 的状态来进行push 和 pop 操作进行释放变量
- NSObject 的performSelector(delay), performSelectorOnMainThread,performSelectorOnThread(Thread perform addition)
- CA 层的CADisplayLink(每一帧有一个回调),CATransition,CAAnimation
- dispatch_get_main_queue 分发的事件在 Main RunLoop 去执行
- NSURLConnection - AFNetworking 2.x 的 delegate
- NSPort 描述通讯信道的抽象类(source1)
实例1
新建应用,在页面捕获点击事件
如图所示:APP启动,start-->main.m进入-->Graphics Services(处理硬件交互的服务,比如用户点击屏幕)-->RunLoop(CFRunLoop开头的)-->Handle event
runloop 中定义的6种函数
static void __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__();
static void __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__();
几乎所有的函数都是从以上6中函数中调起.比如上图中就是调用的
static void __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__();
static void __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__()
然后开始调用event
runloop 的构成
- RunLoop跟Thread是一一绑定的(也就是之前说的一个Thread里只有一个根runloop但是可以嵌套N个)
- CFRunLoopMode:RunLoop必须在系统定义的几种模式下运行
CFRunLoopTimer
CFRunLoopTimer包括以下几种常见方法的封装
CFRunLoopSource
source是RunLoop的数据源(输入源)的抽象类(protocol)
RunLoop定义了两个version的Source:
- source0:处理App内部事件,App自己负责管理(出发),如UIEvent、CFSocket
- source1:由RunLoop和内核管理，Mach Port(进程间通讯端口)驱动，如CFMachPort、CFMessagePort
CFRunLoopObserver
Runloop 向外部告知当前 runloop 的状态(可以自行注册 Observer 来获取 runloop 进入各种状态的通知),系统不分行为也是注册了observer,典型例子就是 AutoReleasePool
kCFRunLoopEntry = (1UL << 0),// 即将进入Loop
kCFRunLoopBeforeTimers = (1UL << 1),// 即将处理 Timer
kCFRunLoopBeforeSources = (1UL << 2),// 即将处理 Source
kCFRunLoopBeforeWaiting = (1UL << 5),// 即将进入休眠
kCFRunLoopAfterWaiting = (1UL << 6),// 刚从休眠中唤醒
kCFRunLoopExit = (1UL << 7),// 即将退出Loop
kCFRunLoopAllActivities = 0x0FFFFFFFU//所有状态
RunLoopObserver与Autorelease Pool
大家面试的时候可以问问面试者这个问题，autorelease的对象到底在什么时候释放？
根据孙源大神测试，AutoreleasePool通常在RunLoop两次Sleep之间释放.需要深入理解可以看孙大神的 blog:
http://blog.sunnyxx.com/2014/10/15/behind-autorelease/
CFRunLoopMode
- RunLoop在同一时间只能且必须在一种特定的Mode下Run
- 更换Mode时，需要停止当前RunLoop,然后重启新的RunLoop
- Mode是iOS App流畅滑动的关键（因为在滑动时的Mode跟平时运行的Mode是不一样，从而避免干扰）
- 也可以基于系统的Mode创建自己的Mode（也是基本不会发生的）
系统定义的Mode有以下几种：
- CFRunLoopDefaultMode: 这个是默认 Mode，也是空闲状态。主线程通常在这个 Mode 下运行的。
- UITrackingRunLoopMode: ScrollView滚动时候的模式。
- UIInitializationRunLoopMode: 在刚启动程序时进入的第一个 Mode，私有，启动完成后就不再使用。
- GSEventReceiveRunLoopMode: 接受系统事件的内部的Mode，这个Mode由GraphicsServices调用在CFRunLoopRunSpecific前面。通常用不到。
- CFRunLoopCommonModes: 这是一个数组，默认包括了第1和第2种模式，可以添加自己的Mode。
UITrackingRunLoopMode与NSTimer
下面的方法Timer被添加到NSDefaultRunLoopMode，在滑动Scrollview的时候系统会切换至UITrackingRunLoopMode，Timer就会暂时停止.
[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerTick:) userInfo:nil repeats:YES];
当存在 tableView/scrollView 滑动时,若不希望Timer被滑动影响，需添加到NSRunLoopCommonMode.
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerTick:) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop]addTimer:timer forMode:NSRunLoopCommonModes];
下图表示App在滑动时的Mode切换
RunLoop与dispatch_get_main_queue()
前面有说到GCD跟RunLoop有关系，其实本身GCD跟RunLoop是没有关系的，但是如果把queue填成main_queue就有关系了，关系只在于调起的过程是在RunLoop.GCD的主线程就是App的主线程，所以在GCD牵扯的主线程会转交给RunLoop去调起.
RunLoop的挂起与唤醒
在App运行时，在Debug栏里按下暂停，会出现以下堆栈
这就是RunLoop的睡眠状态，与刚刚说的MachPort有关系，图片里面上边的两个mach_msg会指定一个端口发给内核一个消息，这会儿就是正在等待接收信息的状态，也就是等待唤醒，内核此刻将其挂起（不是传统意义的挂起，还在内存里，其实就是睡眠状态，等个闹钟，或者有人叫醒）
等待到唤醒的过程：(类似于NSNotificationCenter,在收到Post时唤醒进行处理)
- 指定用于唤醒的mach_port端口
- 调用mach_msg监听唤醒端口，被唤醒前，系统内核将此线程挂起，停留在mach_msg_trap状态
- 由另一个线程（或另一个进程中的某个线程）向内核发送这个端口的msg后，trap状态被唤醒，RunLoop继续运行
RunLoop迭代执行顺序（伪代码）
//设定过期时间
SetupThisRunLoopRunTimeOutTimer(); //by GCD timer
do{
//通知Observer要跑timer跟source
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks();
//运行到此刻，去检测当前加到消息队列source0的消息，此方法遍历source0去执行
__CFRunLoopDoSource0();
//询问GCD有没有分到主线程的东西需要调用
CheckIfExistMessageInMainDispatchQueue(); //GCD
//通知Observer要进入睡眠
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
//此刻获取到是哪个端口把我叫醒
var wakeUpPort = SleepAndWaitForWakingUpPorts();
// mach_msg_trap
// Zzz...
// Received mach_msg, wake up!
//通知Observer我要醒了~
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
//Handler msgs
if(wakeUpPort == timerPort){
//如果是timer唤醒就去执行timer
__CFRunLoopDoTimer();
}else if(wakeUpPort == mainDispatchQueuePort){
//GCD需要我，就去调GCD的事件
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE();
}else{
//比如说网络来数据了就会用这个端口唤醒，然后做数据处理
__CFRunloopDoSource1();
}
__CFRunLoopDoBlocks();
}while (!stop && !timeOut);//如果没被外部干掉或者时间没到，继续循环
或者下面的伪代码
int __CFRunLoopRun()
{
//通知即将进入runloop
__CFRunLoopDoObservers(KCFRunLoopEntry);
do {
// 通知将要处理timer和source
__CFRunLoopDoObservers(kCFRunLoopBeforeTimers);
__CFRunLoopDoObservers(kCFRunLoopBeforeSources);
__CFRunLoopDoBlocks();
//处理非延迟的主线程调用
__CFRunLoopDoSource0();
//处理UIEvent事件
//GCD dispatch main queue
CheckIfExistMessagesInMainDispatchQueue();
// 即将进入休眠
__CFRunLoopDoObservers(kCFRunLoopBeforeWaiting);
// 等待内核mach_msg事件
mach_port_t wakeUpPort = SleepAndWaitForWakingUpPorts();
// Zzz...
// 从等待中醒来
__CFRunLoopDoObservers(kCFRunLoopAfterWaiting);
// 处理因timer的唤醒
if (wakeUpPort == timerPort)
__CFRunLoopDoTimers();
// 处理异步方法唤醒,如dispatch_async
else if (wakeUpPort == mainDispatchQueuePort)
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__()
// UI刷新,动画显示
else
__CFRunLoopDoSource1();
// 再次确保是否有同步的方法需要调用
__CFRunLoopDoBlocks();
} while (!stop && !timeout);
//通知即将退出runloop
__CFRunLoopDoObservers(CFRunLoopExit);
}
其中var wakeUpPort = SleepAndWaitForWakingUpPorts();这句伪代码可以看作是RunLoop的核心。内部实现简化为这样：先调用__CFRunLoopServiceMachPort()——> 里面会调用mach_msg()函数 然后会卡在这里，等待接收消息来唤醒RunLoop。直到下面的某个条件被触发才被唤醒：
- time_out 超时时间到了
- 有一个Source事件
- timer的时间到了
RunLoop 调用mach_msg()函数去接收消息，如果没有其他 mach_port 发送消息过来，内核就会将线程置于等待状态，直到接收到msg。就好比我们在一个函数中，调用了scanf()函数来接收输入一样，只有收到了输入信息，代码才能继续向下执行，否则会一直卡在那里。
AFNetworking2.x中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 启动前内部必须要有至少一个 Timer/Observer/Source，所以 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]) {
...
}
当需要这个后台线程执行任务时，AFNetworking 通过调用 [NSObject performSelector:onThread:..] 将这个任务扔到了后台线程的 RunLoop 中。
一个TableView延迟加载图片的新思维
这个问题是有的TableView有大量图片（比如头像）加载，在滑动的时候，请求网络，下载完图片之后设置的时候会卡，往常的解决方案一般是添加delegate之类的，检测什么时候滑动结束什么时候去设置图片
在知道RunLoop之后，可以采用下面的方案，在DefaultMode去做，这样滑动的时候就不会调用设置图片方法.
UIImage *downLoadImage = ...;
[self.avatarImageView performSelector:@selector(setImage:)
withObject:downloadImage
afterDelay:0
inModes:@[NSDefaultRunLoopMode]];
