RunLoop学习总结

发表于 更新于 分类于

开始

很久之前就看了一次YY的文章，没看懂。后来又看了sunny的视频和叶孤城的直播的视频，找了很多资料，对RunLoop也越来越清晰，然后又看了两三次YY的文章，虽然还没完全看懂，不得不说写的非常好，帮助很大。还有官方文档，学到了很多东西。还有就是github上的一些demo，文中一些代码别人写过了，我就直接拿过来了。文中一些结论也是取自大神的文章或者视频。非常感谢这些前辈大神们的分享吧！！

什么是RunLoop

RunLoop其实就是一种处理事件、消息的机制被面向对象化，它就是一个对象。其实它的本质就是一个do-while循环

1
2
3
4
do {
    //如果有事件/消息，就处理
	//没事件/消息或者都处理完了就沉睡
} while(1)

NSRunloop和CFRunloop

NSRunLoop是对CFRunLoop的封装，使之更面向对象化。我们一般在NSRunLoop层面上操作。CFRunLoop基于C语言，从属于CoreFoundation(开源)。

官方文档里对CFRunLoop的解释很好，它建立任务来监测着输入源(事件源，事件/消息)和准备好处理输入源的时候调度管理，输入源包括用户输入的设备，网络连接，周期性或者延迟的事件，还有异步的回调等。

RunLoop的结构组成

一个RunLoop可以监测三个对象，Sources, Timers, Observers，如图

RunLoop

图来自YY的文章，这个图很棒

其实是一个RunLoop对象可以包含一个或者多个Mode，这个Mode可以说是一种模式，一种配置。而Mode又包含着输入源（事件源）Source，观察者Observer，和计时器Timer和其他一些信息。

CFRunLoopMode

Mode决定了RunLoop在什么时候处理什么事情，在某个Mode在某个时候能做什么不能做什么，在某个Mode某个时候只能做什么。
切换Mode需要先推出RunLoop再重新进入。

Mode有几种

  • DefaultMode，CFRunLoop的是kCFRunLoopDefaultMode，NSRunLoop的是NSDefaultRunLoopMode，这是默认的mode，即APP平常的状态
  • UITrackingRunLoopMode，追踪scrollView滑动的状态，当有scrollView滑动的时候RunLoop会切换到该mode下，滑动结束再切换到其他mode
  • UIInitializationRunLoopMode，这个是私有的，在APP启动时到显示第一个界面期间会进入这个mode
  • NSRunLoopCommonModes，这个是Mode集合，自定义或者若干个集合，默认是包含了defaultMode和trackingMode
  • GSEventReceiveRunLoopMode: 接受系统事件的内部 Mode，通常用不到。

这里先说一个例子，例如我们创建的NSTimer对象在运行时碰到有scrollView的空间滑动的时候是默认不会继续计时的

1
2
3
4
5
6
    [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(tiktok) userInfo:nil repeats:YES];
    
- (void)tiktok
{
    NSLog(@"%d",self.count++);
}

defaultMode

那是因为用scheduleTime…这个方法，timer默认被添加到了RunLoop的defaultMode，而滑动tableView的时候RunLoop切换到了trackingMode所以停止了。

解决方法就是把timer添加到当前RunLoop的UITrackingRunLoopMode或者NSRunLoopCommonModes

1
2
3
4
//只要添加一句
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:UITrackingRunLoopMode];
//或者
//[[NSRunLoop currentRunLoop] addTimer:timer NSRunLoopCommonModes];

UITrackingRunLoopMode

Mode的结构

CFRunLoopMode是一个struct，最主要是Source、Timer和Observer，这些被称为mode item，还有一些其他信息，例如name，就是指上面的defaultMode或者trackingMode的名字，还有一些线程锁标志信息等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct __CFRunLoopMode {
    //Mode的名字
    CFStringRef _name;
    
    //Source就两个
    CFMutableSetRef _sources0;
    CFMutableSetRef _sources1;
    
    //Observer数组
    CFMutableArrayRef _observers;
    
    //Timer数组
    CFMutableArrayRef _timers;
    
    //还有其他的一些信息
    //.....
};

CFRunLoopSource

输入源(input source)是指用户的操作事件（例如点击屏幕）或者网络端口接收到的信息等。而一个CFRunLoopSource对象就是跑在RunLoop上输入源的抽象概念，Source可以说是用户操作的事件、消息和RunLoop的中间层。

有两种Source

  • Source0，被APP所管理，处理内部事件，如UIEvent、CFSocket
  • Source1，被RunLoop和内核所管理，由Mach port驱动,如CFMachPort、CFMessagePort
    这里已经涉及到很底层的东西了，查了下Mach port，很底层，太少资料，大概了解到一点是用来通信的通道，端口，这个还有待研究

CFRunLoopObserver

这个就是观察者，同来用来接收各种回调(callbakcs)。一个Observer一次只能被一个RunLoop注册。当RunLoop的状态切换的时候Observer可以观察到

这个是RunLoop的状态

1
2
3
4
5
6
7
8
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
};

然后我们来测试一下，创建一个Observer来观察RunLoop的状态

1
2
3
4
5
6
7
8
9
//创建一个Observer，观察RunLoop的所有状态
//这里打印出来的数字是上面struct的数字X的2^X
CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(CFAllocatorGetDefault(), kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
       NSLog(@"RunLoop状态-%zd", activity);
   });
   
   CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);
   //注意CF对象要释放
   CFRelease(observer);

然后查看打印

2016-07-05_22:57:57.jpg

后面的数字即刚才RunLoop的状态，对比struct可以看出，APP一运行就先进入RunLoop，然后2/4切换，即处理Source和Timer然后是32，即将进入睡眠状态，再64，即将从睡眠状态中醒来…然后循环两三次到最后32，即将进入睡眠状态，这就是一个APP打开的时候然后没给任何动作

接下来我滑动一下tableView，来看一下打印

2016-07-05_23:20:51.jpg

先醒过来，处理Source和Timer，然后有个128（即对应上面的2^7)，即将退出RunLoop，这是意料之中，因为我滑动tableView把mode切换到了trackingMode，而切换Mode的时候需要先退出mode再从新进入，等松开手后最终状态又变成32，睡眠状态

这也很符合刚开始的do-while循环，一有事件/消息处理就处理，不然就进入睡眠

RunLoop和线程的关系

线程和 RunLoop 之间是一一对应的，其关系是保存在一个全局的 Dictionary 里。线程刚创建时并没有 RunLoop，如果你不主动获取，那它一直都不会有。RunLoop 的创建是发生在第一次获取时，RunLoop 的销毁是发生在线程结束时。你只能在一个线程的内部获取其 RunLoop（主线程除外）。(直接取自YY的结论)

RunLoop和Autorelease Pool

UIkit通过RunLoopObserver在RunLoop两次Sleep间对Autorelease Pool进行Pop和Push将这次Loop中产生的Aotorelease对象释放

应用

tableView滑动后再加载图片

当一个tableView或者collectionView（这两个都是继承自scrollView)里面放了很多图片的时候并且要加载的时候，有一个优化的措施就是在滑动的时候不加载，在滑动完了之后再开始加载。

1
2
UIImage *downloadedImage = ...;
self.imageView performSelector:@selector(setImage:) withObject:downloadedImage afterDelay:0 inModes:@[NSDefaultRunLoopMode]];

(以上代码取自sunny的视频)

让setImage方法只在NSDefaultRunLoopMode里面运行，在滑动的时候进入trackingMode就不执行

还有更具体的实现可以看下这个github demo

虽然可以这样实现，但是我觉得使用性不强，我看了很多较常用的APP都没有这样实现，且当学习吧

常驻线程

1
2
[[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];
[[NSRunLoop currentRunLoop] run];

或者

1
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate distantFuture]];

监测滑动卡顿

前面说到RunLoop会一直切换状态，我们要监测的是在处理Source的时候的时间，如果时间太长，则说明有可能卡顿了

只需要另外再开启一个线程,实时计算这两个状态区域之间的耗时是否到达某个阀值,便能揪出这些性能杀手. 为了让计算更精确,需要让子线程更及时的获知主线程NSRunLoop状态变化,所以dispatch_semaphore_t是个不错的选择,另外卡顿需要覆盖到多次连续小卡顿和单次长时间卡顿两种情景,所以判定条件也需要做适当优化.将上面两个方法添加计算的逻辑如下:`

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
static void runLoopObserverCallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info)
{
    MyClass *object = (__bridge MyClass*)info;

    // 记录状态值
    object->activity = activity;

    // 发送信号
    dispatch_semaphore_t semaphore = moniotr->semaphore;
    dispatch_semaphore_signal(semaphore);
}

- (void)registerObserver
{
    CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};
    CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES, 0,&runLoopObserverCallBack,&context);
    CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);
    // 创建信号
    semaphore = dispatch_semaphore_create(0);
    // 在子线程监控时长
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        while (YES)
        {
            // 假定连续5次超时50ms认为卡顿(当然也包含了单次超时250ms)
            long st = dispatch_semaphore_wait(semaphore, dispatch_time(DISPATCH_TIME_NOW, 50*NSEC_PER_MSEC));
            if (st != 0)
            {
                if (activity==kCFRunLoopBeforeSources || activity==kCFRunLoopAfterWaiting)
                {
                    if (++timeoutCount < 5)
                        continue;
                    NSLog(@"好像有点儿卡哦");
                }
            }
            timeoutCount = 0;
        }
    });
}

以上带去取自https://github.com/suifengqjn/PerformanceMonitor

最后

写的有点糟，只是一个小总结，感觉还是有好多不懂，还是要深入学习。