RunLoop相关知识

  RunLoop,翻译过来是运行环路。我们在创建命令行项目和创建ios项目时,发现命令行项目当最后一行代码执行完后项目就自动退出了,而ios项目确可以一直运行,知道用户手动点击退出按钮。这就是因为ios项目在main函数中自动创建了runLoop,从而可以使项目可以一直响应用户的操作。

int main(int argc, char * argv[]) {
    @autoreleasepool {
       //这行代码 会自动创建主线程的RunLoop      
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

  我们可以将这个过程我们可以简化成:

  

我们从这个过程可以看出RunLoop的基本作用
 保持程序的持续运行
 处理App中的各种事件(比如触摸事件、定时器事件等)
 节省CPU资源,提高程序性能:该做事时做事,该休息时休息
  ......

我们平时开发中,涉及到RunLoop的挺多的,比如说定时器、手势识别、网络请求等等,

  

一、RunLoop的结构

iOS中有2套API来访问和使用RunLoop:

①Foundation:NSRunLoop,它是基于 CFRunLoopRef 的封装,提供了面向对象的 API,但是这些 API 不是线程安全的。

②Core Foundation:CFRunLoopRef,它提供了纯 C 函数的 API,所有这些 API都是线程安全的。(CFRunLoopRef是开源的)

两者关系:

  所以我们获取RunLoop对象也有两种方法:

Foundation
[NSRunLoop currentRunLoop]; // 获得当前线程的RunLoop对象
[NSRunLoop mainRunLoop]; // 获得主线程的RunLoop对象

Core Foundation
CFRunLoopGetCurrent(); // 获得当前线程的RunLoop对象
CFRunLoopGetMain(); // 获得主线程的RunLoop对象

  因为CFRunLoopRef是开源的,所以我们可以通过它来看一下它的实现结构。来到CFRunLoop.c文件中,找到了RunLoop的结构体定义:

//已剔除非必要部分
struct
__CFRunLoop { pthread_t _pthread; CFMutableSetRef _commonModes; CFMutableSetRef _commonModeItems; CFRunLoopModeRef _currentMode; CFMutableSetRef _modes; };

  这里的Set和数组类似,只不过数组是有序的,而set是无序的,都是用来存放数据的,所以 CFMutableSetRef可以理解成可变数组,也就是说在一个RunLoop对象中,存储着一个线程对象,三个可变数组,一个当前模式。那么CFRunLoopModeRef又是什么呢?

  我们找到了它的定义:  

typedef struct __CFRunLoopMode *CFRunLoopModeRef;
//剔除了其他无关属性
struct __CFRunLoopMode {
    CFStringRef _name;
    CFMutableSetRef _sources0;
    CFMutableSetRef _sources1;
    CFMutableArrayRef _observers;
    CFMutableArrayRef _timers;
};

  所以RunLoop的结构是这样的:

  _pthread就是RunLoop对应的线程,每条线程都有唯一的一个与之对应的RunLoop对象。

  _commonModeItems和_commonModes是用来存放某些特定模式和模式内事件的,接下来会讲到。

  _currentMode,RunLoop当前所处的模式,当前模式是从_modes里面选择的。

  _modes:RunLoop的运行模式,一共有五种,但是我们经常用的就两三种:

- kCFRunLoopDefaultMode, App的默认运行模式,通常主线程是在这个运行模式下运行
- UITrackingRunLoopMode, 跟踪用户交互事件(用于 ScrollView 追踪触摸滑动,保证界面滑动时不受其他Mode影响)页面滚动式所处的模式
- kCFRunLoopCommonModes, 伪模式,不是一种真正的运行模式
- UIInitializationRunLoopMode:在刚启动App时第进入的第一个Mode,启动完成后就不再使用
- GSEventReceiveRunLoopMode:接受系统内部事件,通常用不到

  我们上面提到的_commonModeItems和_commonModes就是存放kCFRunLoopCommonModes这种模式的数据的。CommonModes其实并不是一种真正的模式,而是指可以在标记为Common Modes的模式下运行的伪模式。 目前被标记为Common Modes的模式: kCFRunLoopDefaultMode,UITrackingRunLoopMode,简单来说目前kCFRunLoopCommonModes就是指kCFRunLoopDefaultMode+UITrackingRunLoopMode。比如,我们经常遇到在tableview添加定时器后,当tableview滚动后timer就不响应了。

  这是因为tableview滚动式处在UITrackingRunLoopMode模式下的,而定时器默认是处在kCFRunLoopDefaultMode下的,所以当模式切换后,RunLoop就无法响应之前模式的时间了,故而无法响应定时器时间。所以我们的方案是将定时器添加到RunLoop的kCFRunLoopCommonModes模式下,这样无论是否滑动tableview都可以响应定时器事件了。

  这里还需要注意的一点是:如果需要切换 Mode,只能退出Loop,再重新指定一个 Mode 进入。这样做主要是为了分隔开不同组的 Source/Timer/Observer,让其互不影响。

  接下来,我们再来看一下这个RunLoop中的模式指的是什么?有什么作用?

  我们前面通过源码,看到了CFRunLoopMode的结构,里面有sources0、sources1、timer、observers,其实这里面就存储着app要处理的种种事情,它们分别负责不同的工作。它们的分工是这样的:(个人认为sources0和sources1其实是一个整体,当事件发生时sources1先去获取这个时间,涉及不到端口或内核或其他线程的事情的话就交给sources0处理,其余的自己处理)

sources0:只包含了一个回调(函数指针),它并不能主动触发事件,比如点击事件等操作都是通过sources0处理的。

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

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

observers:是观察者,当 RunLoop 的状态发生变化时,观察者就能通过回调接受到这个变化。

  RunLoop的状态有一下几种:

  需要注意的一点是:如果Mode里没有任何Source0/Source1/Timer/Observer,RunLoop会立马退出

 

二、RunLoop与线程

  关于RunLoop与线程的关系,我们可以总结以下几点:

每条线程都有唯一的一个与之对应的RunLoop对象

线程刚创建时并没有RunLoop对象,RunLoop会在第一次获取它时创建
主线程的RunLoop已经自动获取(创建),子线程默认没有开启RunLoop,子线程没有开启RunLoop的话就跟命令行项目一样,任务执行完就会结束

RunLoop保存在一个全局的Dictionary里,线程作为key,RunLoop作为value

RunLoop会在线程结束时销毁

  接下来,我们通过源码来验证:

  当我们获取线程的Runloop的时候,发现RunLoop没有获取到话,都会调用__CFRunLoopGet0, 并把线程作为参数传递

  

  继续,跳转至__CFRunLoopGet0,如下:

  发现,RunLoop与线程的关系是一对一的,并且用了个全局字典保存了起来,线程作为key,RunLoop作为value。

我们发现如果线程没有启用RunLoop后会执行完马上销毁:

添加RunLoop后,发现还是运行完就销毁:这是因为如果Mode里没有任何Source0/Source1/Timer/Observer,RunLoop会立马退出

 

所以我们需要往Model中添加一个数据:

发现确实执行完后,线程阻塞了,一直没有被销毁,这是因为当runtime创建后,如果没有被事件唤醒后它就一直在休眠,cpu就不会继续处理事情,所以阻塞在这。

三、RunLoop的运行逻辑 

  我们在了解RunLoop的结构以及与线程的关系后,我们再来看一下RunLoop的运行流程: 

 

  接下来,我们通过源码来看一下RunLoop是如何处理这些事件的?

关于入口的查找,我们可以现在touchesBegan:方法中打个断点,查看程序是怎么执行到这的:

//RunLoop入口
SInt32 CFRunLoopRunSpecific(CFRunLoopRef rl, CFStringRef modeName, CFTimeInterval seconds, Boolean returnAfterSourceHandled) {     /* DOES CALLOUT */
    //通知Observers 进入RunLoop
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopEntry);
    
    //RunLoop的具体运行
    result = __CFRunLoopRun(rl, currentMode, seconds, returnAfterSourceHandled, previousMode);
    
    //通知Observers 退出RunLoop
    __CFRunLoopDoObservers(rl, currentMode, kCFRunLoopExit);
    return result;
}

//RunLoop的具体运行
static int32_t __CFRunLoopRun(CFRunLoopRef rl, CFRunLoopModeRef rlm, CFTimeInterval seconds, Boolean stopAfterHandle, CFRunLoopModeRef previousMode) {
    
    int32_t retVal = 0;
    do {
        //通知Observers 即将处理Timers
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeTimers);
        //通知Observers 即将处理Sources
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeSources);
         //处理Block
        __CFRunLoopDoBlocks(rl, rlm);
        
        //处理Sources0
        if (__CFRunLoopDoSources0(rl, rlm, stopAfterHandle)) {
            //处理Block
            __CFRunLoopDoBlocks(rl, rlm);
        }
        
        Boolean poll = sourceHandledThisLoop || (0ULL == timeout_context->termTSR);
        
        // 如果当前是主线程的runloop,并且主线程有事情需要处理,则跳转至handle_msg处理,即跳过休眠  这条指令网上大部分说法是指判断Sources1中是否有事情处理,个人觉得这个说法不太对,这篇文章中有正面:资料
        if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) {
            goto handle_msg;
        }
    
        //通知Observers 即将休眠
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopBeforeWaiting);
        //开始休眠
        __CFRunLoopSetSleeping(rl);
        
        //等待别的消息来唤醒当前线程  如果没有消息就会一直在这休眠 阻塞在这 cpu不工作  有消息的话则唤醒执行
        __CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);
        
        //结束休眠
        __CFRunLoopUnsetSleeping(rl);
        //通知Observers 结束休眠
        __CFRunLoopDoObservers(rl, rlm, kCFRunLoopAfterWaiting);

//handle_msg
handle_msg:;
        if (被timer唤醒) {
            //处理Timers
           __CFRunLoopDoTimers(rl, rlm, mach_absolute_time())
        }
        else if (被gcd唤醒) {
            //处理gcd
            __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
        } else {//被sources1唤醒
            //处理Sources1
            __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply)
        }
        //处理Block
        __CFRunLoopDoBlocks(rl, rlm);
        
        //处理返回值
        if (sourceHandledThisLoop && stopAfterHandle) {
            retVal = kCFRunLoopRunHandledSource;
        } else if (timeout_context->termTSR < mach_absolute_time()) {
            retVal = kCFRunLoopRunTimedOut;
        } else if (__CFRunLoopIsStopped(rl)) {
            __CFRunLoopUnsetStopped(rl);
            retVal = kCFRunLoopRunStopped;
        } else if (rlm->_stopped) {
            rlm->_stopped = false;
            retVal = kCFRunLoopRunStopped;
        } else if (__CFRunLoopModeIsEmpty(rl, rlm, previousMode)) {
            retVal = kCFRunLoopRunFinished;
        }
        
    } while (0 == retVal);

    return retVal;
}

  简化成流程图 则是:

  

 

四、RunLoop的应用

控制线程生命周期(线程保活),比较经典的就是AFNetworking案例;

解决NSTimer在滑动时停止工作的问题,这个是我们平时开发中遇到过的;

滚动视图流畅性优化

App卡顿监测

阻止App崩溃

 

 

 

 

 

 相关参考资料:

RunLoop源码解析

RunLoop

posted @ 2019-05-09 13:36  高晓牛  阅读(649)  评论(0编辑  收藏  举报