RunLoop相关知识

2024-04-08 21:04:40

　　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的运行逻辑

四、RunLoop的应用

相关文章

三、RunLoop的运行逻辑　