关于RunLoop基本的介绍请查看第一篇文章
以下主要介绍项目中RunLoop的实际使用

一、NSTimer优化

备注：NSTimer 定时器从RunLoop中移除的唯一方法：invalidate

第一：NSTimer在滚动时，可以继续倒计时
当在主线程中创建Timer，默认是加入主线程RunLoop中的NSDefaultRunLoopMode模式下，
而tableView在滚动的时候，主线程的RunLoop会切换到UITrackingRunLoopMode，所以导致Timer停止运行。

解决方式有两种：
（1）将Timer加入到主线程的UITrackingRunLoopMode或者NSRunLoopCommonModes
    [[NSRunLoop currentRunLoop] addTimer:self.timer forMode:UITrackingRunLoopMode]; 
或者
    [[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];


（2）在子线程创建Timer并且激活子线程的RunLoop，因为tableView滑动的时候，
    改变的是mainRunLoop的Model，并不会修改子线程的RunLoopModel模式
    （PS：具体写法与下方的一致）

第二：让子线程的NSTimer工作

/// 主线程下创建的定时器能运行
/// 由于主线程的RunLoop默认是创建了并运行的，所以在主线程创建的定时器能运行
- (void)viewDidLoad {
    [super viewDidLoad];
    
    __block int count = 0;
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
        count ++;
        NSLog(@"%d",count);
    }];
}



/// 子线程创建的定时器不运行
/// 因为子线程的RunLoop默认是没创建的
- (void)viewDidLoad {
    [super viewDidLoad];
    
    [self performSelectorInBackground:@selector(childrenThread) withObject:nil];
}

- (void)childrenThread {
    __block int count = 0;
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
        count ++;
        NSLog(@"%d",count);
    }];
}


/// 解决方法：
- (void)childrenThread {
    __block int count = 0;
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
        count ++;
        NSLog(@"%d",count);
    }];
    
    /// 获取子线程的RunLoop， 并且将self.timer加入到RunLoop中
    [[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSDefaultRunLoopMode];
    /// 启动RunLoop
    [[NSRunLoop currentRunLoop] run];
}

二、线程保活

三、卡顿检测

强烈建议先看iOS卡顿监控文章，之后再看
iOS开发优化篇之卡顿检测，第一篇是对于基础卡顿检查做论述，而第二篇更是在第一篇的基础上完善
笔者也是反复看了几遍才稍微了解，在代码处写了很多的注释，此处只做几个点的说明，查看的更多注释请下载DEMO
链接: https://pan.baidu.com/s/1LYIlOltpcr9ZXCQ5nm3Pag 密码: e2gc

这里还有一个好用的第三方库，可以手机Crash以及实时获取各线程的调用堆栈：PLCrashReporter

首先明确的一点的是，RunLoop调用方法是主要在两个阶段

• kCFRunLoopBeforeSources和kCFRunLoopBeforeWaiting之间
• kCFRunLoopAfterWaiting之后
  也就是说卡顿是发生在这两个阶段

对于iOS卡顿监控文章，很重要的一点，在监控RunLoop状态回调的函数中，对信号量发起信号，信号量+1

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

然后通过判断MainRunLoop停留在kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 是否超过设置的阈值，从而判断是否发生卡顿。（）

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

这种方案从理论上是可行的，但是运行iOS卡顿监控文章的DEMO，发现不起作用，不能捕获tableview的卡顿。是因为滚动引发的Sources事件总是被快速的执行完成，然后进入到kCFRunLoopBeforeWaiting状态下，所以发生卡顿的时候，MainRunLoop是处于kCFRunLoopBeforeWaiting下，完美避过了卡顿检查的条件。

于是请看第二篇文章iOS开发优化篇之卡顿检测，这能完美的处理当发生卡顿时，RunLoop处于kCFRunLoopBeforeWaiting下的检测卡顿现象(通过子线程ping主线程)。

检测一：在kCFRunLoopBeforeWaiting 状态时，往主线程发起修改数据的请求，然后阻塞当前子线程，当过了等待时间阀值如果主线程没响应，则判定主线程卡顿

检测二：MainRunLoop处于kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 下处理事件停留的时间，如果连续多次超过阀值则认为卡顿

     /**
        必须提醒：RunLoop的作用是线程保活，让程序可持续运行，
        也就是可以一直监听系统的事件输入：比如用户的屏幕交互、定时器、网络请求返回接收等等
        而RunLoop进入休眠，只能是说明没有新的输入源进入，但不代表程序没有代码在运行
     
        即将进入休眠状态 : kCFRunLoopBeforeWaiting
     */


/// 记录runloop的状态切换，并且发送信号dispatch_semaphore_signal(SHAREDMONITOR.semphore)
static void lxdRunLoopObserverCallback(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void * info) {
    SHAREDMONITOR.currentActivity = activity;
    /// 处理kCFRunLoopBeforeSources、kCFRunLoopAfterWaiting状态下的
    dispatch_semaphore_signal(SHAREDMONITOR.semphore);
}


/**
    必须提醒：RunLoop的作用是线程保活，让程序可持续运行，
    也就是可以一直监听系统的事件输入：比如用户的屏幕交互、定时器、网络请求等等
    而RunLoop进入休眠，只能是说明没有新的输入源进入，但不代表程序没有代码在运行
 
    即将进入休眠状态 : kCFRunLoopBeforeWaiting
 */
/// 异步串行队列
/// 使用串行队列的作用：线程安全
/// 异步：开启新的线程
dispatch_async(lxd_event_monitor_queue(), ^{
    while (SHAREDMONITOR.isMonitoring) {
        if (SHAREDMONITOR.currentActivity == kCFRunLoopBeforeWaiting) {
            __block BOOL timeOut = YES;
            /// 在子线程向主线程发起任务，判断主线程是否阻塞
            dispatch_async(dispatch_get_main_queue(), ^{
                timeOut = NO;
                dispatch_semaphore_signal(SHAREDMONITOR.eventSemphore);
            });
            /// 阻塞当前线程，1秒
            /// 给主线程修改timeOut的值，如果过了等待时间，timeOut的值还未修改，则判定主线程阻塞
            [NSThread sleepForTimeInterval: lxd_time_out_interval];
            if (timeOut) {
                [LXDBacktraceLogger lxd_logMain];
            }
            /// 会阻塞当前线程，直到evenSemphore信号量大于0
            /// 作用：等待这个循环结束了，才执行下个循环
            dispatch_wait(SHAREDMONITOR.eventSemphore, DISPATCH_TIME_FOREVER);
        }
    }
});


/**
    Runloop主要集中在kCFRunLoopBeforeSources 和 KCFRunLoopAfterWaiting之间
    kCFRunLoopBeforeSources、kCFRunLoopAfterWaiting
 */
dispatch_async(lxd_fluecy_monitor_queue(), ^{
    while (SHAREDMONITOR.isMonitoring) {
        /// 这里还有一点很重要的：RunLoop状态流转的顺序是：kCFRunLoopBeforeWaiting --> kCFRunLoopAfterWaiting ---> kCFRunLoopBeforeTimers ---> kCFRunLoopBeforeSources ----> kCFRunLoopBeforeWaiting
        ///
        /// self.semphore 发送信号是在MainRunLoop状态切换的监控方法中
        /// 这里的判断依据是MainRunLoop停留在 kCFRunLoopBeforeSources 和 kCFRunLoopAfterWaiting 的时间，
        /// 如果连续5次超时200ms则认为是卡顿了（或者一次长停留超过5*200ms也包括在内）
        /// 以lxd_wait_interval为等待时间，如果时间到，信号号量还是等于0，那么dispatch_semaphore_wait的返回值就会大于 0
        /// 如果在时间范围内，信号量大于0，那么dispatch_semaphore_wait信号就会被激活，继续往下走，并且返回值是等于0
        long waitTime = dispatch_semaphore_wait(self.semphore, dispatch_time(DISPATCH_TIME_NOW, lxd_wait_interval));
        if (waitTime != LXD_SEMPHORE_SUCCESS) {
            /// 在超过时间范围内，信号量还是为0 ，即主线程没有响应子线程的修改timerOut的请求
            if (!SHAREDMONITOR.observer) {
                SHAREDMONITOR.timeOut = 0;
                [SHAREDMONITOR stopMonitoring];
                continue;
            }
            /// 如果主线MainRunLoop 处于 “即将处理Source” 和 “被唤醒后”
            if (SHAREDMONITOR.currentActivity == kCFRunLoopBeforeSources ||
                SHAREDMONITOR.currentActivity == kCFRunLoopAfterWaiting) {
                /// 如果连续5次循环，主线程还是没有响应，则判定主线程卡顿
                if (++SHAREDMONITOR.timeOut < 5) {
                    continue;
                }
                [LXDBacktraceLogger lxd_logMain];
                /// 这里阻塞线程5秒，主要是因为主线程目前已经是处于卡顿状态
                /// 为了避免对于同一个卡顿重复捕获，所以这里停顿了5秒时间后再开始监控
                [NSThread sleepForTimeInterval: lxd_restore_interval];
            }
        }
        SHAREDMONITOR.timeOut = 0;
    }
});
    

四、优化卡顿

案例：
一个列表中有多张大图片，滑动卡顿
diwu 大神的做法就是将Cell中加载图片的耗时操作保存起来，等到tableview没有滑动的时候，处理耗时操作，这样就能避免在滑动给的时候卡顿。但有另外一个问题，就是滑动的时候，图片位置都是空白的。对于这种情况，推荐使用iOS保持界面流畅的技巧文字中提到的方法

参考文献：

iOS卡顿监测方案总结