内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

关于runloop 好多人都理解错了

2018-05-15 16:56 出处:清屏网 人气: 评论(0

跟多数开发者一样,我也曾经迷惑于runloop,最初只了解可以通过runloop一些监听事件的通知来做一些事情,优化性能。关于runloop源码的基础知识,本文不做论述,可以参考众神的文章:

本文主要内容:

  • 指出广泛传播runloop文章中错误
  • 通过代码论证错误
  • 通过demo论证错误

runloop解读文章中的错误

本人也看着众神的文章才对runloop有了比较深入了解,最近自己终于利用零零星星的时间把runloop源码也看了一遍,才发现好多人都误解了runloop!!就拿下面这张好多文章中都提及的图片和流程来说:

摘自《深入理解RunLoop》

这是runloop运行流程图,但其实这个图里面有两个错误,请看下面标注图:

错误标注图

  • 第一个错误 “source0(port)” 应该是作者笔误,图中错误将source1 (基于port)写成source0;

  • 第二个错误 "5. 如果有source1,跳到第9步" 从图和作者的代码注释中都能看出是理解有错误,这里也正是本文重点描述的内容

先说结论,再逐步验证:

这里其实判断的是 主线程是否有需要处理的事件,如果没有则调到第9步,这里跟source1没有关系!

所以应该改成“5. 如果当前是主线程的runloop,并且主线程有事儿,跳到第9步”

源码论证

我们直接上源码(版本CF-1151.16)分析一下,直接看这句话对应的代码(有精简):

if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime)
{
      msg = (mach_msg_header_t *)msg_buffer;
      if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) 
      {
              goto handle_msg;
      }
}

可以看出跳转到第9步(goto handle_msg)的逻辑是判断__CFRunLoopServiceMachPort函数的返回值是否为真,而这个if对应的就是上文描述“如果有source1”,那么这句话是这个意思吗? 起初我也是这么认为的,直到我看到了后面下一段第7步“休眠”的代码:

// 第七步,进入循环开始不断的读取端口信息,如果端口有唤醒信息则唤醒当前runLoop

__CFPortSet waitSet = rlm->_portSet;

...

...


if (kCFUseCollectableAllocator) 
{
    memset(msg_buffer, 0, sizeof(msg_buffer));
}

// waitSet 为所有需要监听的port集合, TIMEOUT_INFINITY表示一直等待
msg = (mach_msg_header_t *)msg_buffer;
__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy);

这里面出现了上面的一样的__CFRunLoopServiceMachPort方法, 单拎出来比对下,

__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)

__CFRunLoopServiceMachPort(waitSet, &msg, sizeof(msg_buffer), &livePort, poll ? 0 : TIMEOUT_INFINITY, &voucherState, &voucherCopy)

比较后发现,参数中第一个参数和倒数第三个参数不同。我们通过__CFRunLoopServiceMachPort的源码来分析下,其中重点关注:

  • livePort的赋值用于函数外部使用;
  • __CFRunLoopServiceMachPort方法中mach_msg的参数MACH_RCV_MSG表示在接收消息;
  • __CFRunLoopServiceMachPort参数timeout对于二者入参分别是0和TIMEOUT_INFINITY,分别表示查询到立刻返回和一直等待有消息再返回;
static Boolean __CFRunLoopServiceMachPort(mach_port_name_t port, mach_msg_header_t **buffer, size_t buffer_size, mach_port_t *livePort, mach_msg_timeout_t timeout, voucher_mach_msg_state_t *voucherState, voucher_t *voucherCopy) 
{
      Boolean originalBuffer = true;
      kern_return_t ret = KERN_SUCCESS;

      for (;;) 
      { /* In that sleep of death what nightmares may come ... */
          mach_msg_header_t *msg = (mach_msg_header_t *)*buffer;
          msg->msgh_bits = 0;
          msg->msgh_local_port = port;
          msg->msgh_remote_port = MACH_PORT_NULL;
          msg->msgh_size = buffer_size;
          msg->msgh_id = 0;
          if (TIMEOUT_INFINITY == timeout) { CFRUNLOOP_SLEEP(); } else { CFRUNLOOP_POLL(); }

          ret = mach_msg(msg, MACH_RCV_MSG|(voucherState ? MACH_RCV_VOUCHER : 0)|MACH_RCV_LARGE|((TIMEOUT_INFINITY !=       timeout) ? MACH_RCV_TIMEOUT : 0)|MACH_RCV_TRAILER_TYPE(MACH_MSG_TRAILER_FORMAT_0)|MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_AV), 0, msg->msgh_size, port, timeout, MACH_PORT_NULL);

          // Take care of all voucher-related work right after mach_msg.
          // If we don't release the previous voucher we're going to leak it.
          voucher_mach_msg_revert(*voucherState);

          // Someone will be responsible for calling voucher_mach_msg_revert. This call makes the received voucher the current one.
          *voucherState = voucher_mach_msg_adopt(msg);
          if (voucherCopy) 
          {
               if (*voucherState != VOUCHER_MACH_MSG_STATE_UNCHANGED) 
                {
                  *voucherCopy = voucher_copy();
                } 
              else
               {
                  *voucherCopy = NULL;
               }
         }

         CFRUNLOOP_WAKEUP(ret);
          if (MACH_MSG_SUCCESS == ret)
           {
                  *livePort = msg ? msg->msgh_local_port : MACH_PORT_NULL;
                  return true;
          }

          if (MACH_RCV_TIMED_OUT == ret) 
            {
                  if (!originalBuffer) free(msg);
                  *buffer = NULL;
                  *livePort = MACH_PORT_NULL;
                  return false;
            }

          if (MACH_RCV_TOO_LARGE != ret) break;

          buffer_size = round_msg(msg->msgh_size + MAX_TRAILER_SIZE);
          if (originalBuffer) *buffer = NULL;
          originalBuffer = false;
          *buffer = realloc(*buffer, buffer_size);
      }

      HALT;
      return false;
}

从代码中我们可以大概看出,休眠时调用这个方法的作用就是监听判断waitSet中所有port,如果这些port中有一个出现消息,就唤醒了跳出休眠,并且将唤醒的port赋值给livePort。对于上面的mach_msg,我们在程序运行时打断点一定经常遇到,如下图,当runloop处于休眠时,就是下面的状态,也就是上面代码中mach_msg的timeout入参为TIMEOUT_INFINITY时阻塞式等待的情况:

阻塞等待消息堆栈

下面的代码也验证了livePort用来判断是哪种激励将休眠唤醒,通过livePort来判断是进行哪种处理:

if (MACH_PORT_NULL == livePort)
{
      CFRUNLOOP_WAKEUP_FOR_NOTHING();
}
else if (livePort == rl->_wakeUpPort)
{
      CFRUNLOOP_WAKEUP_FOR_WAKEUP();
}
else if (rlm->_timerPort != MACH_PORT_NULL && livePort == rlm->_timerPort)
{
      // 处理timer
}
else if (livePort == dispatchPort) 
{
      ......
      // 处理主线程队列中事件
      __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(msg);
      ......
}
else 
{
      ......
      // 处理Source1
      sourceHandledThisLoop = __CFRunLoopDoSource1(rl, rlm, rls, msg, msg->msgh_size, &reply) || sourceHandledThisLoop;
      ......
}

通过上面对__CFRunLoopServiceMachPort的源码分析:我们基本确定了,第5步对应的代码

if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) 
{
      goto handle_msg;
}

其实__CFRunLoopServiceMachPort在等的是dispatchPort这个端口的消息,而这个端口是什么呢? 我们顺着源码向前找:

mach_port_name_t dispatchPort = MACH_PORT_NULL;
Boolean libdispatchQSafe = pthread_main_np() && ((HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && NULL == previousMode) || (!HANDLE_DISPATCH_ON_BASE_INVOCATION_ONLY && 0 == _CFGetTSD(__CFTSDKeyIsInGCDMainQ)));

if (libdispatchQSafe && (CFRunLoopGetMain() == rl) && CFSetContainsValue(rl->_commonModes, rlm->_name)) 
  dispatchPort = _dispatch_get_main_queue_port_4CF();

我们重点看if判断中的 (CFRunLoopGetMain() == rl),其中rl表示当前的runloop,查看CFRunLoopGetMain()源码可知返回的是主线程的runloop,所以这里判断就是当前runloop是否是主线程的runloop,这时我们再回到下面跳转到handle_msg那段代码:

if (MACH_PORT_NULL != dispatchPort && !didDispatchPortLastTime) 
{
      msg = (mach_msg_header_t *)msg_buffer;
      if (__CFRunLoopServiceMachPort(dispatchPort, &msg, sizeof(msg_buffer), &livePort, 0, &voucherState, NULL)) 
      {
            goto handle_msg;
      }
}

我们可以看到判断是否跳转之前先判断dispatchPort有没有消息,而再之前的条件必须满足MACH_PORT_NULL != dispatchPort,也就是前面必须对dispatchPort有所赋值,才会进行下面的判断和跳转逻辑。所以这里可以小总结一下重要的结论:

  • 只有当前运行的runloop是主线程的runloop时,才会对dispatchPort赋值;
  • 如果dispatchPort没有赋值,则不会进行是否“goto handle_msg”的逻辑判断;
  • dispatchPort赋予的值是主线程队列对应的port;
  • 如果当前运行的runloop不是主线程的runloop,那么原图中的第5步就不会存在,也就是多子线程图中不存在第5步;

综上,终于来到我们理论的总结:原图中第5步的应该由"5. 如果有source1,调到第9步"改成“5. 如果当前是主线程的runloop,并且主线程有事儿,跳到第9步”。 所以最终整体流程应该是:

1. 通知observer run loop被触发
  2. 如果有timers事件的话,通知observer
  3. 如果有source0要处理的话,通知observer
  4. 触发所有的准备完毕的source0
  5. 如果当前是主线程的runloop,并且主线程有事儿,跳到第9步
  6. 通知Observer runloop将进入sleep状态
  7. mach进入sleep和监听状态
  8. 通知observer,runloop被woke up
  9. 如果runloop是被唤醒,CFRUNLOOP_WAKEUP_FOR_WAKEUP
  10. 如果用户定义的timer被触发,处理event并重启RunLoop
  11. 如果dispatchPort,处理主线程
  12. 如果一个source1被触发,__CFRunLoopDoSource1
  13. 继续循环或通知observer runloop将要exited。

demo论证

最后我们再用demo来佐证一下,demo中我会首先则监听主线程的runloop,然后再在子线程监听子线程的runloop,打印监听的事件。

先看下demo中的主要代码:

// 添加主线程runloop监听者
[self addMainObserver];

// 添加子线程runloop监听者
[self addOtherObserver];

// 此处使用sleep是为了避免使用timer造成runloop的timer事件的干扰。
sleep(3);
dispatch_async(dispatch_get_main_queue(), ^{

    CGFloat randomAlpha = (arc4random() % 100)*0.01;
    [self.view setBackgroundColor:[UIColor colorWithWhite:0.5 alpha:randomAlpha]];
});
...
...

// 添加子线程runloop监听者
- (void)addOtherObserver
{
      [NSThread detachNewThreadWithBlock:^{

      _timer = [NSTimer scheduledTimerWithTimeInterval:3 repeats:NO block:^(NSTimer * _Nonnull timer) 
      {
            NSLog(@"###cmm子线程###timer时间到");
      }];

      CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {
      switch (activity) {
            case kCFRunLoopEntry:
            NSLog(@"###cmm子线程###进入kCFRunLoopEntry");
            break;

            case kCFRunLoopBeforeTimers:
            NSLog(@"###cmm子线程###即将处理Timer事件");
            break;

            case kCFRunLoopBeforeSources:
            NSLog(@"###cmm子线程###即将处理Source事件");
            break;

            case kCFRunLoopBeforeWaiting:
            NSLog(@"###cmm子线程###即将休眠");
            break;

            case kCFRunLoopAfterWaiting:
            NSLog(@"###cmm子线程###被唤醒");
            break;

            case kCFRunLoopExit:
            NSLog(@"###cmm子线程###退出RunLoop");
            break;

            default:
            break;
        }
    });

      CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);

      [[NSRunLoop currentRunLoop] addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
      CFRunLoopRun();
   }];
}

// 添加主线程runloop监听者

- (void)addMainObserver
{
      CFRunLoopObserverRef observer = CFRunLoopObserverCreateWithHandler(kCFAllocatorDefault, kCFRunLoopAllActivities, YES, 0, ^(CFRunLoopObserverRef observer, CFRunLoopActivity activity) {

      switch (activity) {

            case kCFRunLoopEntry:
            NSLog(@"###cmm###进入kCFRunLoopEntry");
            break;

            case kCFRunLoopBeforeTimers:
            NSLog(@"###cmm###即将处理Timer事件");
            break;

            case kCFRunLoopBeforeSources:
            NSLog(@"###cmm###即将处理Source事件");
            break;

            case kCFRunLoopBeforeWaiting:
            NSLog(@"###cmm###即将休眠");
            break;

            case kCFRunLoopAfterWaiting:
            NSLog(@"###cmm###被唤醒");
            break;

            case kCFRunLoopExit:
            NSLog(@"###cmm###退出RunLoop");
            break;

            default:
            break;
           }
      });

      CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode);

      _timer1 = [NSTimer scheduledTimerWithTimeInterval:3 repeats:NO block:^(NSTimer * _Nonnull timer) {
      NSLog(@"###cmm###timer时间到");
    }];
}

结合刚才整理的runloop的整体流程分析一下预期的打印结果应该是:

  • 主线程中,如果有事儿需要处理, “即将处理timer事件”-->"即将处理source事件"-->下一个循环的"即将处理timer事件"-->"即将处理source事件",这里没有经过“即将休眠”,就是因为主线程有事儿,进入“goto handle_msg”,直接跳过休眠阶段。
  • 子线程在主线程runloop处理事儿的时候,并没有打印结果变化,说明并没有触发这个goto条件。

demo跑起来~~~

我们在主线程的代码中打断点,查看堆栈和日志如下图:

堆栈和日志

可以发现,如我们所料:主线程的runloop在即将处理source事件后,直接跳到了 “__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__” ,也就是跳过了休眠,直接到了handle_msg对应的 else if (livePort == dispatchPort) 分支。另外我们可以在日志中发现此时子线程的runloop已经启动,并处于休眠状态。

然后我们注意下下图:

日志

如图中箭头处,在我们程序跳过断点继续执行后,并没有子线程的相关打印,说明此时子线程的runloop并不会管主线程那部分代码。

完结。

分享给小伙伴们:
本文标签: runloop

相关文章

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

CopyRight © 2015-2016 QingPingShan.com , All Rights Reserved.

清屏网 版权所有 豫ICP备15026204号