Luoshengyang

Chromium网页渲染调度器（Scheduler）实现分析

在采用线程化渲染方式渲染网页时，Chromium依赖一个调度器协调Main线程和Compositor线程的执行，同时也通过这个调度器决定它们什么时候该执行什么操作。调度器将Main线程和Compositor线程的当前状态记录在一个状态机中，然后通过这个状态机决定下一个要执行的操作。这个操作在满足当前设置条件下是最优的，因此可以使网页渲染更快更流畅。本文接下来就分析Chromium网页调度器的实现。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

调度器实现在Chromium的CC模块中，并且运行在Compositor线程中。Compositor线程的职责是将网页的内容渲染出来。从这个角度看，调度器只不过是在调度Compositor线程的执行。不过由于要渲染的网页内容是由Main线程提供给Compositor线程的，因此调度器也会在必要的时候调度Main线程执行，使得它可以提供最新的网页内容给Compositor线程渲染。

网页是一帧一帧地渲染出来的。从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章我们学习到，Android应用程序UI的每一帧的最佳渲染时机是下一个屏幕VSync信号到来时。Chromium也不例外，它在渲染网页的时候，也是利用了屏幕的VSync信号。这一点在调度器的时间轴中可以得到体现，如图1所示：

图1 调度器时间轴

从图1可以看到，调度器并没有严格在VSync到来时就去渲染网页的下一帧，而是为网页的下一帧渲染时机设置了一个Deadline。在Deadline到来前，调度器可以调度执行其它的渲染操作。

在继续分析上述的Deadline机制之前，我们要先搞清楚网页的一帧渲染涉及到哪些操作。这些操作如图2所示：

图2 调试器调度执行的操作

图2的完整分析可以参考前面Chromium网页渲染机制简要介绍和学习计划一文。我们前面说的Deadline，是针对第6个操作ACTION_DRAW_AND_SWAP_FORCED而言的。也就是说，当VSync信号到来时，ACTION_DRAW_AND_SWAP_FORCED操作最迟必须在设置的Deadline到来时执行。

这个Deadline是怎么计算出来的呢？我们先来看网页的渲染过程。首先是Render进程进行渲染，然后交给Browser进程进行合成。因此，网页的渲染过程可以看作由两部分时间组成：estimated_draw_duration + estimated_browser_composite_time。其中，estimated_draw_duration表示Render进程的渲染时间，estimated_browser_composite_time表示Browser进程的合成时间。

假设下一个VSync到来的时间为frame_time，VSync信号时间周期为interval，那么就可以计算出Deadline = frame_time + (interval - estimated_draw_duration - estimated_browser_composite_time)。剩下来的时间区间[frame_time, deadline)可以用做其它事情，例如执行图2所示的第2个操作ACTION_SEND_BEGIN_MAIN_FRAME，也就是通知Main线程对CC Layer Tree进行绘制。

时间区间[frame_time, deadline)称为BEGIN_IMPL_FRAME时间。在BEGIN_IMPL_FRAME时间内，存在四个BeginImplFrameState状态，如下所示：

class CC_EXPORT SchedulerStateMachine {
 public:
  ......

  // Note: BeginImplFrameState will always cycle through all the states in
  // order. Whether or not it actually waits or draws, it will at least try to
  // wait in BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME and try to draw in
  // BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE
  enum BeginImplFrameState {
    BEGIN_IMPL_FRAME_STATE_IDLE,
    BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING,
    BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME,
    BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE,
  };

  ......

 protected:
  ......

  BeginImplFrameState begin_impl_frame_state_;
  
  ......
};

这个状态定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.h中。

调度器通过类SchedulerStateMachine描述内部的状态机。状态机的BeginImplFrameState状态记录在SchedulerStateMachine类的成员变量begin_impl_frame_state_中。

四个BeginImplFrameState状态分别为：

1. BEGIN_IMPL_FRAME_STATE_IDLE

2. BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING

3. BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME

4. BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE

它们的变迁关系如图3所示：

图3 BeginImplFrameState状态变迁

下一个VSync信号到来之前，状态机处于BEGIN_IMPL_FRAME_STATE_IDLE状态。

下一个VSync信号到来之时，调度器调用SchedulerStateMachine类的成员函数OnBeginImplFrame将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING。这时候调度器通过调用Scheduler类的成员函数ProcessScheduledActions调度计算网页中的动画，或者执行图2所示的第2个操作ACTION_SEND_BEGIN_MAIN_FRAME，也就是通知Main线程对网页内容进行绘制。

从Scheduler类的成员函数ProcessScheduledActions返回后，BeginImplFrameState状态就从BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING变为BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME。这时候调度器等待Deadline的到来。

Deadline到来之时，调度器调用SchedulerStateMachine类的成员函数OnBeginImplFrameDeadline将BeginImplFrameState状态从BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME设置为BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE。这时候调度器就会通过调用Scheduler类的成员函数ProcessScheduledActions调度执行网页的渲染操作，也就是图2所示的第6个操作ACTION_DRAW_AND_SWAP_FORCED。

从Scheduler类的成员函数ProcessScheduledActions返回后，BeginImplFrameState状态就从BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE重新变为BEGIN_IMPL_FRAME_STATE_IDLE。这时候调度器等待再下一个VSync信号的到来。

状态机除了有BeginImplFrameState状态，还有其它三个状态，分别是OutputSurfaceState、CommitState和ForcedRedrawOnTimeoutState。

OutputSurfaceState描述的是网页绘图表面的状态，如下所示：

class CC_EXPORT SchedulerStateMachine {
 public:
  ......

  enum OutputSurfaceState {
    OUTPUT_SURFACE_ACTIVE,
    OUTPUT_SURFACE_LOST,
    OUTPUT_SURFACE_CREATING,
    OUTPUT_SURFACE_WAITING_FOR_FIRST_COMMIT,
    OUTPUT_SURFACE_WAITING_FOR_FIRST_ACTIVATION,
  };

  ......

 protected:
  ......

  OutputSurfaceState output_surface_state_;
  
  ......
};

这个状态定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.h中。

网页绘图表面的状态记录在SchedulerStateMachine类的成员变量output_surface_state_中。网页绘图表面的状态有五个状态，分别是：

1. OUTPUT_SURFACE_LOST

2. OUTPUT_SURFACE_CREATING

3. OUTPUT_SURFACE_WAITING_FOR_FIRST_COMMIT

4. OUTPUT_SURFACE_WAITING_FOR_FIRST_ACTIVATION

5. OUTPUT_SURFACE_ACTIVE

它们的变迁关系如图4所示：

图4 OutputSurfaceState状态变迁

网页绘图表面最初处于OUTPUT_SURFACE_LOST状态，等到CC Layer Tree创建之后，调度器会调度图2所示的第2个操作ACTION_BEGIN_OUTPUT_SURFACE_CREATION，也就是请求Compositor线程为网页创建绘图表面，这时候网页绘图表面的状态变为OUTPUT_SURFACE_CREATING。

Compositor线程为网页创建好了绘图表面之后，就会调用SchedulerStateMachine类的成员函数DidCreateAndInitializeOutputSurface将绘图表面的状态设置为OUTPUT_SURFACE_WAITING_FOR_FIRST_COMMIT。这将会触发调度器尽快调度执行图2所示的第2个操作ACTION_SEND_BEGIN_MAIN_FRAME和第3个操作ACTION_COMMIT，也就是请求Main线程对CC Layer Tree进行绘制，并且将其同步到CC Pending Layer Tree中去。这时候绘图表面的状态变为OUTPUT_SURFACE_WAITING_FOR_FIRST_ACTIVATION，表示要尽快将CC Pending Layer Tree激活为CC Active Layer Tree。

CC Pending Layer Tree被激活之后，也就是图2所示的第5个操作ACTION_ACTIVATE_PENDING_TREE执行之后，绘图表面以后就会一直处于OUTPUT_SURFACE_ACTIVE状态。不过，在绘图表面处于OUTPUT_SURFACE_ACTIVE状态期间，如果Render进程与GPU进程之间的GPU通道断开了连接，或者GPU进程在解析Render进程发送来的GPU命令时发生了错误，那么SchedulerStateMachine类的成员函数DidLoseOutputSurface会被调用。这时候绘图表面的状态就会被设置为OUTPUT_SURFACE_LOST状态。这将会触发调度器调度执行ACTION_BEGIN_OUTPUT_SURFACE_CREATION操作，以便为网页重新创建绘图表面。

CommitState描述的是CC Layer Tree的提交状态，包括同步到CC Pending Layer Tree，以及CC Pending Layer Tree激活为CC Active Layer Tree的过程，如下所示：

class CC_EXPORT SchedulerStateMachine {
 public:
  ......

  enum CommitState {
    COMMIT_STATE_IDLE,
    COMMIT_STATE_BEGIN_MAIN_FRAME_SENT,
    COMMIT_STATE_BEGIN_MAIN_FRAME_STARTED,
    COMMIT_STATE_READY_TO_COMMIT,
    COMMIT_STATE_WAITING_FOR_ACTIVATION,
    COMMIT_STATE_WAITING_FOR_FIRST_DRAW,
  };

  ......

 private:
  ......

  CommitState commit_state_;
 
  ......
};

这个状态定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.h中。

CC Layer Tree的提交状态记录在SchedulerStateMachine类的成员变量commit_state_中。CC Layer Tree有六个提交状态，分别是：

1. COMMIT_STATE_IDLE

2. COMMIT_STATE_BEGIN_MAIN_FRAME_SENT

3. COMMIT_STATE_BEGIN_MAIN_FRAME_STARTED

4. COMMIT_STATE_READY_TO_COMMIT

5. COMMIT_STATE_WAITING_FOR_ACTIVATION

6. COMMIT_STATE_WAITING_FOR_FIRST_DRAW

它们的变迁关系如图5所示：

图5 CommitState状态变迁

CC Layer Tree的提交状态最开始时被设置为COMMIT_STATE_IDLE。当调度器调度执行图2所示的第2个操作ACTION_BEGIN_MAIN_FRAME时，CC Layer Tree的提交状态被设置为COMMIT_STATE_BEGIN_MAIN_FRAME_SENT，表示调度器已经请求Main线程对CC Layer Tree进行绘制。

在Main线程执行ACTION_BEGIN_MAIN_FRAME操作期间，CC Layer Tree有可能变为不可见，这时候调度器就会调用SchedulerStateMachine类的成员函数BeginMainFrameAborted重新设置为COMMIT_STATE_IDLE。

Main线程执行完成ACTION_BEGIN_MAIN_FRAME操作之后，调度器就会调用SchedulerStateMachine类的成员函数NotifyReadyToCommit将CC Layer Tree的提交状态设置为COMMIT_STATE_BEGIN_MAIN_FRAME_STARTED。这时候Main线程会通知Compositor线程对网页中的图片资源以纹理方式上传到GPU去，以便后面进行渲染显示。

图片资源上传完毕，调度器就会调用SchedulerStateMachine类的成员函数NotifyReadyToCommit将CC Layer Tree的提交状态设置为COMMIT_STATE_READY_TO_COMMIT，表示CC Layer Tree需要同步到CC Pending Layer Tree中去。这将会触发调度器调度执行图2所示的第三个操作ACTION_COMMIT，也就是将CC Layer Tree同步到CC Pending Layer Tree中去。

ACTION_COMMIT操作执行完成之后，CC Layer Tree的提交状态会从COMMIT_STATE_READY_TO_COMMIT变为以三个状态之一：

1. 在满足以下两个条件之一时，变为COMMIT_STATE_IDLE：

A. main_frame_before_activation_enabled被设置为true。这表示在上一个CC Pending Layer Tree被激活为CC Active Layer Tree之前，允许Main线程绘制网页的下一帧。

B. main_frame_before_draw_enabled被设置为true，但是impl_side_paiting被设置为false。main_frame_before_draw_enabled设置为true，表示在上一个CC Active Layer Tree被渲染之前，允许Main线程绘制网页的下一帧。impl_side_paiting设置为true表示Main线程在绘制网页时，实际上只是记录了网页的绘制命令。只有在impl_side_paiting设置为true的时候，才会有CC Pending Layer Tree被激活为CC Active Layer Tree的环节。因此，在impl_side_paiting等于false的情况下，main_frame_before_draw_enabled被设置为true等同于main_frame_before_activation_enabled被设置为true的情况。

2. FORCED_REDRAW_STATE_WAITING_FOR_ACTIVATION。需要满足的条件是main_frame_before_draw_enabled和impl_side_paiting均被设置为true，并且main_frame_before_activation_enabled被设置为false。这表示在上一个CC Pending Layer Tree被激活为CC Active Layer Tree之后，才允许Main线程绘制网页的下一帧。

3. COMMIT_STATE_WAITING_FOR_FIRST_DRAW。需要满足的条件是main_frame_before_activation_enabled和main_frame_before_draw_enabled均被设置为true。这表示在上一个CC Active Layer Tree第一次渲染之后，才允许Main线程绘制网页的下一帧。这实际上是给予CC Active Layer Tree更高的优先级，使得它一激活就马上进行渲染。

如果CC Layer Tree的提交状态处于FORCED_REDRAW_STATE_WAITING_FOR_ACTIVATION，那么当CC Pending Layer Tree被激活为CC Active Layer Tree之后，也就是图2所示的第5个操作ACTION_ACTIVATE_PENDING_TREE执行之后，CC Layer Tree的提交状态就变为COMMIT_STATE_IDLE。

如果CC Layer Tree的提交状态处于COMMIT_STATE_WAITING_FOR_FIRST_DRAW，那么当CC Active Layer Tree被渲染之后，也就是图2所示的第6个操作ACTION_DRAW_AND_SWAP_FORCED，或者另外一个操作ACTION_DRAW_AND_SWAP_IF_POSSIBLE执行之后，CC Layer Tree的提交状态就变为COMMIT_STATE_IDLE。

注意，只有CC Layer Tree的提交状态处于COMMIT_STATE_IDLE时，Main线程才可以绘制网页的下一帧。

ForcedRedrawOnTimeoutState描述的是网页的渲染状态，如下所示：

class CC_EXPORT SchedulerStateMachine {
 public:
  ......

  enum ForcedRedrawOnTimeoutState {
    FORCED_REDRAW_STATE_IDLE,
    FORCED_REDRAW_STATE_WAITING_FOR_COMMIT,
    FORCED_REDRAW_STATE_WAITING_FOR_ACTIVATION,
    FORCED_REDRAW_STATE_WAITING_FOR_DRAW,
  };

  ......

 private:
  ......

  ForcedRedrawOnTimeoutState forced_redraw_state_;
 
  ......
};

这个状态定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.h中。

网页的渲染状态记录在SchedulerStateMachine类的成员变量forced_redraw_state_中。网页的渲染状态有四个，分别是：

1. FORCED_REDRAW_STATE_IDLE,

2. FORCED_REDRAW_STATE_WAITING_FOR_COMMIT

3. FORCED_REDRAW_STATE_WAITING_FOR_ACTIVATION

4. FORCED_REDRAW_STATE_WAITING_FOR_DRAW

它们的变迁关系如图6所示：

图6 ForcedRedrawOnTimeoutState状态变迁

网页渲染状态最开始处于FORCED_REDRAW_STATE_IDLE状态。在渲染动画的过程中，如果某些分块（Tile）还没有光栅化好，那么CC模块就会用棋盘（Checkboard）来代替这些缺失的分块。这时候的网页渲染结果被视为DRAW_ABORTED_CHECKERBOARD_ANIMATIONS。如果网页连续渲染结果都是DRAW_ABORTED_CHECKERBOARD_ANIMATIONS的次数超出预设值，那么网页渲染状态就会被设置为FORCED_REDRAW_STATE_WAITING_FOR_COMMIT，表示要尽快执行一次图2所示的第3个操作ACTION_COMMIT，以便补充缺失的分块。

ACTION_COMMIT操作执行完成之后，如果Main线程在绘制网页时，仅仅记录了CC Layer Tree的绘制命令，也就是前面提到的impl_side_painting等于true，那么就意味着存在一个CC Pending Layer Tree，这时候网页渲染状态会被设置为FORCED_REDRAW_STATE_WAITING_FOR_ACTIVATION，表示等待CC Pending Layer Tree被激活为CC Active Layer Tree。

另一方面，ACTION_COMMIT操作执行完成之后，如果Main线程在绘制网页时，直接进行光栅化，也就是前面提到的impl_side_painting等于false，那么就意味着不会存在一个CC Pending Layer Tree，这时候网页渲染状态会被设置为FORCED_REDRAW_STATE_WAITING_FOR_DRAW，表示等待CC Active Layer Tree被渲染。

如果网页渲染状态被设置为FORCED_REDRAW_STATE_WAITING_FOR_ACTIVATION，那么当图2所示的第5个操作ACTION_ACTIVATE_PENDING_TREE执行完成之后。也就是CC Pending Layer Tree被激活为CC Active Layer Tree之后，网页渲染状态会被设置为FORCED_REDRAW_STATE_WAITING_FOR_DRAW，表示等待CC Active Layer Tree被渲染。

当CC Active Layer Tree被渲染之后，网页渲染状态就会从FORCED_REDRAW_STATE_WAITING_FOR_DRAW变为FORCED_REDRAW_STATE_IDLE状态。

理解了网页的BeginImplFrameState、OutputSurfaceState、CommitState和ForcedRedrawOnTimeoutState状态之后，接下来我们就可以分析调度器的实现了，也就是调度器的执行过程。

调度器通过Scheduler类实现，调度器的执行过程就表现为Scheduler类的成员函数ProcessScheduledActions不断地被调用，如下所示：

void Scheduler::ProcessScheduledActions() {
  ......

  SchedulerStateMachine::Action action;
  do {
    action = state_machine_.NextAction();
    ......
    state_machine_.UpdateState(action);
    base::AutoReset<SchedulerStateMachine::Action>
        mark_inside_action(&inside_action_, action);
    switch (action) {
      case SchedulerStateMachine::ACTION_NONE:
        break;
      case SchedulerStateMachine::ACTION_ANIMATE:
        client_->ScheduledActionAnimate();
        break;
      case SchedulerStateMachine::ACTION_SEND_BEGIN_MAIN_FRAME:
        client_->ScheduledActionSendBeginMainFrame();
        break;
      case SchedulerStateMachine::ACTION_COMMIT:
        client_->ScheduledActionCommit();
        break;
      case SchedulerStateMachine::ACTION_UPDATE_VISIBLE_TILES:
        client_->ScheduledActionUpdateVisibleTiles();
        break;
      case SchedulerStateMachine::ACTION_ACTIVATE_PENDING_TREE:
        client_->ScheduledActionActivatePendingTree();
        break;
      case SchedulerStateMachine::ACTION_DRAW_AND_SWAP_IF_POSSIBLE:
        DrawAndSwapIfPossible();
        break;
      case SchedulerStateMachine::ACTION_DRAW_AND_SWAP_FORCED:
        client_->ScheduledActionDrawAndSwapForced();
        break;
      case SchedulerStateMachine::ACTION_DRAW_AND_SWAP_ABORT:
        // No action is actually performed, but this allows the state machine to
        // advance out of its waiting to draw state without actually drawing.
        break;
      case SchedulerStateMachine::ACTION_BEGIN_OUTPUT_SURFACE_CREATION:
        client_->ScheduledActionBeginOutputSurfaceCreation();
        break;
      case SchedulerStateMachine::ACTION_MANAGE_TILES:
        client_->ScheduledActionManageTiles();
        break;
    }
  } while (action != SchedulerStateMachine::ACTION_NONE);

  SetupNextBeginFrameIfNeeded();
  ......

  if (state_machine_.ShouldTriggerBeginImplFrameDeadlineEarly()) {
    ......
    ScheduleBeginImplFrameDeadline(base::TimeTicks());
  }
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数ProcessScheduledActions在一个while循环中不断地调用成员变量state_machine_指向的SchedulerStateMachine对象的成员函数NextAction询问状态机下一个要执行的操作，直到状态机告知当前没有操作要执行为止。这些操作大概就对应于图2所示的操作。

每一个操作都是通过调用成员变量client_指向的ThreadProxy对象对应的成员函数执行的。例如，ACTION_SEND_BEGIN_MAIN_FRAME操作是通过调用成员变量client_指向的ThreadProxy对象的成员函数ScheduledActionSendBeginMainFrame执行的。ThreadProxy类的这些函数我们在后面的文章中再详细分析。每一个操作在执行之前，Scheduler类的成员函数ProcessScheduledActions会先调用state_machine_指向的SchedulerStateMachine对象的成员函数UpdateState更新状态机的状态。

跳出while循环之后，Scheduler类的成员函数ProcessScheduledActions调用另外一个成员函数SetupNextBeginFrameIfNeeded根据状态机的当前状态决定是否要发起下一个BEGIN_IMPL_FRAME操作。如果需要的话，就会在下一个VSync信号到来时，通过调用Scheduler类的成员函数ProcessScheduledActions渲染网页的下一帧。

Scheduler类的成员函数ProcessScheduledActions最后还会调用成员变量state_machine_指向的SchedulerStateMachine对象的成员函数ShouldTriggerBeginImplFrameDeadlineEarly检查是否提前执行渲染网页的操作。如果需要提前的话，那么就不会等待上一个VSync信号到来时设置的Deadline到期，而是马上调用成员函数ScheduleBeginImplFrameDeadline假设该Deadline已经到期，于是就可以马上渲染网页。

为了更好地理解调度器的执行过程，接下来我们继续前面提到的SchedulerStateMachine类的成员函数NextAction、UpdateState和ShouldTriggerBeginImplFrameDeadlineEarly以及Scheduler类的成员函数SetupNextBeginFrameIfNeeded和ScheduleBeginImplFrameDeadline的实现。

SchedulerStateMachine类的成员函数NextAction的实现如下所示：

SchedulerStateMachine::Action SchedulerStateMachine::NextAction() const {
  if (ShouldUpdateVisibleTiles())
    return ACTION_UPDATE_VISIBLE_TILES;
  if (ShouldActivatePendingTree())
    return ACTION_ACTIVATE_PENDING_TREE;
  if (ShouldCommit())
    return ACTION_COMMIT;
  if (ShouldAnimate())
    return ACTION_ANIMATE;
  if (ShouldDraw()) {
    if (PendingDrawsShouldBeAborted())
      return ACTION_DRAW_AND_SWAP_ABORT;
    else if (forced_redraw_state_ == FORCED_REDRAW_STATE_WAITING_FOR_DRAW)
      return ACTION_DRAW_AND_SWAP_FORCED;
    else
      return ACTION_DRAW_AND_SWAP_IF_POSSIBLE;
  }
  if (ShouldManageTiles())
    return ACTION_MANAGE_TILES;
  if (ShouldSendBeginMainFrame())
    return ACTION_SEND_BEGIN_MAIN_FRAME;
  if (ShouldBeginOutputSurfaceCreation())
    return ACTION_BEGIN_OUTPUT_SURFACE_CREATION;
  return ACTION_NONE;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数NextAction通过调用一系列的成员函数ShouldXXX决定当前需要执行的操作。例如，如果调用成员函数ShouldCommit得到的返回值为true，那么就SchedulerStateMachine类的成员函数NextAction就会返回一个ACTION_COMMIT值表示要执行一个ACTION_COMMIT操作。这些ShouldXXX成员函数我们在后面的文章中再详细分析。

SchedulerStateMachine类的成员函数UpdateState的实现如下所示：

void SchedulerStateMachine::UpdateState(Action action) {
  switch (action) {
    case ACTION_NONE:
      return;

    case ACTION_UPDATE_VISIBLE_TILES:
      last_frame_number_update_visible_tiles_was_called_ =
          current_frame_number_;
      return;

    case ACTION_ACTIVATE_PENDING_TREE:
      UpdateStateOnActivation();
      return;

    case ACTION_ANIMATE:
      last_frame_number_animate_performed_ = current_frame_number_;
      needs_animate_ = false;
      // TODO(skyostil): Instead of assuming this, require the client to tell
      // us.
      SetNeedsRedraw();
      return;

    case ACTION_SEND_BEGIN_MAIN_FRAME:
      DCHECK(!has_pending_tree_ ||
             settings_.main_frame_before_activation_enabled);
      DCHECK(!active_tree_needs_first_draw_ ||
             settings_.main_frame_before_draw_enabled);
      DCHECK(visible_);
      commit_state_ = COMMIT_STATE_BEGIN_MAIN_FRAME_SENT;
      needs_commit_ = false;
      last_frame_number_begin_main_frame_sent_ =
          current_frame_number_;
      return;

    case ACTION_COMMIT: {
      bool commit_was_aborted = false;
      UpdateStateOnCommit(commit_was_aborted);
      return;
    }

    case ACTION_DRAW_AND_SWAP_FORCED:
    case ACTION_DRAW_AND_SWAP_IF_POSSIBLE: {
      bool did_request_swap = true;
      UpdateStateOnDraw(did_request_swap);
      return;
    }

    case ACTION_DRAW_AND_SWAP_ABORT: {
      bool did_request_swap = false;
      UpdateStateOnDraw(did_request_swap);
      return;
    }

    case ACTION_BEGIN_OUTPUT_SURFACE_CREATION:
      DCHECK_EQ(output_surface_state_, OUTPUT_SURFACE_LOST);
      output_surface_state_ = OUTPUT_SURFACE_CREATING;

      // The following DCHECKs make sure we are in the proper quiescent state.
      // The pipeline should be flushed entirely before we start output
      // surface creation to avoid complicated corner cases.
      DCHECK_EQ(commit_state_, COMMIT_STATE_IDLE);
      DCHECK(!has_pending_tree_);
      DCHECK(!active_tree_needs_first_draw_);
      return;

    case ACTION_MANAGE_TILES:
      UpdateStateOnManageTiles();
      return;
  }
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

参数action表示调度器即将要调度执行的操作，SchedulerStateMachine类的成员函数UpdateState根据这个操作相应地更新状态机的状态。例如，如果调度器即将要调度执行的操作为ACTION_COMMIT，那么SchedulerStateMachine类的成员函数UpdateState就会调用另外一个成员函数UpdateStateOnCommit更新状态机的CommitState状态。这些状态的更新过程我们同样是在后面的文章再详细分析。

SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly的实现如下所示：

bool SchedulerStateMachine::ShouldTriggerBeginImplFrameDeadlineEarly() const {
  // TODO(brianderson): This should take into account multiple commit sources.

  if (begin_impl_frame_state_ != BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME)
    return false;

  // If we've lost the output surface, end the current BeginImplFrame ASAP
  // so we can start creating the next output surface.
  if (output_surface_state_ == OUTPUT_SURFACE_LOST)
    return true;

  // SwapAck throttle the deadline since we wont draw and swap anyway.
  if (pending_swaps_ >= max_pending_swaps_)
    return false;

  if (active_tree_needs_first_draw_)
    return true;

  if (!needs_redraw_)
    return false;

  // This is used to prioritize impl-thread draws when the main thread isn't
  // producing anything, e.g., after an aborted commit. We also check that we
  // don't have a pending tree -- otherwise we should give it a chance to
  // activate.
  // TODO(skyostil): Revisit this when we have more accurate deadline estimates.
  if (commit_state_ == COMMIT_STATE_IDLE && !has_pending_tree_)
    return true;

  // Prioritize impl-thread draws in smoothness mode.
  if (smoothness_takes_priority_)
    return true;

  return false;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

如前所述，当SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly返回true的时候，就表示要马上渲染网页的下一帧，而不要等待上一个VSync到来时所设置的Deadline。这隐含着SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly返回true的一个必要条件，那就是调度器当前必须是在等待Deadline的到来。

从前面的分析可以知道，当SchedulerStateMachine类的成员变量begin_impl_frame_state_的值等于BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME的时候，就表示调度器正在在等待Deadline的到来。因此，当SchedulerStateMachine类的成员变量begin_impl_frame_state_的值不等于BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME的时候，可以马上断定SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly返回true的必要条件不满足。

接下来有四种情况会导致SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly返回true。

第一种情况是网页的绘图表面表还没有创建，或者之前已经创建过，但是现在丢失了。在这种情况下，SchedulerStateMachine类的成员变量output_surface_state_的值等于OUTPUT_SURFACE_LOST。

第二种情况是上一个CC Pending Layer Tree刚刚激活为CC Active Layer Tree。在这种情况下，SchedulerStateMachine类的成员变量active_tree_needs_first_draw_的值等于true。CC Pending Layer Tree被激活为CC Active Layer Tree时，说明网页很可能发生了较大的变化，也就是它有可能需要花费更多的渲染时间，因此需要提前进行渲染，而不是等到Deadline到来时再渲染。不过，这种情况还需要满足另外一个条件，就是Render进程当前请求GPU进程执行的SwapBuffers操作未完成的次数pending_swaps_不能大于等于预先设置的阀值max_pending_swaps_。

第三种情况是虽然CC Layer Tree没有发生新的变化需要同步给CC Pending Layer Tree，但是网页当前被要求重新进行渲染，也就是对当前的CC Active Layer Tree进行渲染。这时候SchedulerStateMachine类的成员变量commit_state_的值等于COMMIT_STATE_IDLE，并且成员变量needs_redraw_的值等于true。这种情况出现在CC Layer Tree上一次将变化同步给CC Pending Layer Tree时还没有完成就被取消。不过，如果这时候存在一个CC Pending Layer Tree，那么SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly就不会返回true，目的是让已经存在的CC Pending Layer Tree优先渲染出来，而不是继续渲染当前的CC Active Layer Tree。

第四种情况是对第三种情况的补充，也就是网页当前的状态为：

1. 被要求重新渲染，也就是成员变量needs_redraw_的值等于true

2. CC Layer Tree有发生了新的变化，并且正在同步到CC Pending Layer Tree，或者上一次同步CC Layer Tree得到的CC Pending Layer Tree还未完成光栅化

这时候本应该让已经存在的CC Pending Layer Tree优先渲染，或者让CC Layer Tree同步后得到的新CC Pending Layer Tree优先渲染。但是如果SchedulerStateMachine类的成员变量smoothness_takes_priority_的值等于true，那么优先渲染的是当前的CC Active Layer Tree。也就是说，当网页被要求重新渲染时，不要等待新的内容准备就绪，要马上对现有的就绪内容进行渲染。因此，SchedulerStateMachine类的成员变量smoothness_takes_priority_的值等于true时，表示的意思是网页的现有内容显示优先于新内容显示，即使显现有内容是较旧的。这种体验带来的好处是让用户觉得网页显示很流畅，不是每次都一卡一顿地显示最新的内容。

接下来我们重点分析调度器准备下一个BEGIN_IMPL_FRAME操作的过程，也就是Scheduler类的成员函数SetupNextBeginFrameIfNeeded的实现，如下所示：

void Scheduler::SetupNextBeginFrameIfNeeded() {
  bool needs_begin_frame = state_machine_.BeginFrameNeeded();

  if (settings_.throttle_frame_production) {
    SetupNextBeginFrameWhenVSyncThrottlingEnabled(needs_begin_frame);
  } else {
    SetupNextBeginFrameWhenVSyncThrottlingDisabled(needs_begin_frame);
  }
  SetupPollingMechanisms(needs_begin_frame);
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数SetupNextBeginFrameIfNeeded首先调用成员变量state_machine_指向的SchedulerStateMachine对象的成员函数BeginFrameNeeded询问状态机是否需要重新绘制网页。在需要的情况下，才可能会请求在下一个VSync信号到来时对网页进行重绘。这一点容易理解，如果网页不需要重绘，那么下一帧就继续显示上一帧的内容即可。

并不是所有的平台都支持VSync信号。如果当前平台不支持VSync信号，那么Scheduler类的成员变量settings_描述的一个SchedulerSettings对象的成员变量throttle_frame_production的值会等于false，这时候Scheduler类的成员函数SetupNextBeginFrameIfNeeded调用另外一个成员函数SetupNextBeginFrameWhenVSyncThrottlingDisabled简单地根据帧率来决定下一个BEGIN_IMPL_FRAME操作的时间点。例如，假设屏幕的刷新频率为60fps，那么Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingDisabled就会在1000 / 60 = 16.67毫秒后发起下一个BEGIN_IMPL_FRAME操作。

这里我们只考虑平台支持VSync信号，这时候Scheduler类的成员函数SetupNextBeginFrameIfNeeded就会调用另外一个成员函数SetupNextBeginFrameWhenVSyncThrottlingEnabled设置在下一个VSync信号到来时执行一个BEGIN_IMPL_FRAME操作。

BEGIN_IMPL_FRAME操作是通过调用Scheduler类的成员函数ProcessScheduledActions执行的，它的职责对网页进行渲染，特指图2所示的ACTION_DRAW_AND_SWAP_FORCED操作。但是，Scheduler类的成员函数ProcessScheduledActions在执行的时候，根据当时状态机的状态，也可能会执行其它类型的操作。这样BEGIN_IMPL_FRAME操作就会起到向前推进网页的渲染管线的作用，也就是使得网页不会停留在一个中间状态的作用。例如，状态机的CommitState状态不等于COMMIT_STATE_IDLE的时候，就是一个中间状态。假如这时候Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnabled通过计算发现不需要在下一个VSync信号到来时发起一个BEGIN_IMPL_FRAME操作。这就会意味着Scheduler类的成员函数ProcessScheduledActions很可能在接下来一段时间里不会被调用。这将会造成状态机停留在CommitState中间状态。

为了避免状态机长时间停留在中间状态，调度器提供了一种Polling机制，它会定时地调用Scheduler类的成员函数ProcessScheduledActions，这样就可以不断地将网页的渲染管线向前推进，直到到达稳定状态。这是种Polling机制是通过调用Scheduler类的成员函数SetupPollingMechanisms运作的。Scheduler类的成员函数SetupPollingMechanisms的实现与前面提到的另外一个成员函数SetupNextBeginFrameWhenVSyncThrottlingDisabled类似，都是根据屏幕的刷新频率来定时调用Scheduler类的成员函数ProcessScheduledActions的。

接下来我们主要分析SchedulerStateMachine类的成员函数BeginFrameNeeded和Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnabled的实现，Scheduler类的另外两个成员函数SetupNextBeginFrameWhenVSyncThrottlingDisabled和SetupPollingMechanisms读者可以根据前面的解释进行自行分析。

SchedulerStateMachine类的成员函数BeginFrameNeeded的实现如下所示：

bool SchedulerStateMachine::BeginFrameNeeded() const {
  // Proactive BeginFrames are bad for the synchronous compositor because we
  // have to draw when we get the BeginFrame and could end up drawing many
  // duplicate frames if our new frame isn't ready in time.
  // To poll for state with the synchronous compositor without having to draw,
  // we rely on ShouldPollForAnticipatedDrawTriggers instead.
  if (!SupportsProactiveBeginFrame())
    return BeginFrameNeededToAnimateOrDraw();

  return BeginFrameNeededToAnimateOrDraw() || ProactiveBeginFrameWanted();
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数BeginFrameNeeded分两种情况决定当前是否是发起一个BEGIN_IMPL_FRAME操作。第一种情况是网页使用的合成器不支持主动发起BEGIN_IMPL_FRAME操作。第二种情况与第一种情况相反。

网页使用的合成器是否支持主动发起BEGIN_IMPL_FRAME操作，可以通过调用SchedulerStateMachine类的成员函数SupportsProactiveBeginFrame判断，它的实现如下所示：

// Note: If SupportsProactiveBeginFrame is false, the scheduler should poll
// for changes in it's draw state so it can request a BeginFrame when it's
// actually ready.
bool SchedulerStateMachine::SupportsProactiveBeginFrame() const {
  // It is undesirable to proactively request BeginFrames if we are
  // using a synchronous compositor because we *must* draw for every
  // BeginFrame, which could cause duplicate draws.
  return !settings_.using_synchronous_renderer_compositor;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

当SchedulerStateMachine类的成员变量settings_描述的SchedulerSettings对象的成员变量using_synchronous_renderer_compositor等于false的时候，SchedulerStateMachine类的成员函数SupportsProactiveBeginFrame的返回值就等于true，表示网页使用的合成器支持主动发起BEGIN_IMPL_FRAME操作。

当SchedulerStateMachine类的成员变量settings_描述的SchedulerSettings对象的成员变量using_synchronous_renderer_compositor等于true的时候，表示网页使用的合成器是同步合成器（Synchronous Renderer Compositor）。同步合成器适用在WebView的情景。WebView是嵌入在应用程序窗口中显示网页的，它渲染网页的方式与独立的浏览器应用有所不同。简单来说，就是每当WebView需要重绘网页，它需要向应用程序窗口发送一个Invalidate消息。应用程序窗口接下来就会调用WebView的onDraw函数。一旦WebView的onDraw函数被调用，它就必须准备好要合成的内容。也就是它不能设置一个Deadline，等到Deadline到期时再去合成的内容。这就是所谓的“同步”，而设置Deadline的方式是“异步”的。

回到SchedulerStateMachine类的成员函数BeginFrameNeeded中，如果网页使用的是同步合成器，那么就只有在调用另外一个成员函数BeginFrameNeededToAnimateOrDraw得到的返回值等于true的时候，SchedulerStateMachine类的成员函数BeginFrameNeeded的返回才会等于true。

SchedulerStateMachine类的成员函数BeginFrameNeededToAnimateOrDraw的实现如下所示：

// These are the cases where we definitely (or almost definitely) have a
// new frame to animate and/or draw and can draw.
bool SchedulerStateMachine::BeginFrameNeededToAnimateOrDraw() const {
  // The output surface is the provider of BeginImplFrames, so we are not going
  // to get them even if we ask for them.
  if (!HasInitializedOutputSurface())
    return false;

  // If we can't draw, don't tick until we are notified that we can draw again.
  if (!can_draw_)
    return false;

  // The forced draw respects our normal draw scheduling, so we need to
  // request a BeginImplFrame for it.
  if (forced_redraw_state_ == FORCED_REDRAW_STATE_WAITING_FOR_DRAW)
    return true;

  // There's no need to produce frames if we are not visible.
  if (!visible_)
    return false;

  // We need to draw a more complete frame than we did the last BeginImplFrame,
  // so request another BeginImplFrame in anticipation that we will have
  // additional visible tiles.
  if (swap_used_incomplete_tile_)
    return true;

  if (needs_animate_)
    return true;

  return needs_redraw_;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数BeginFrameNeededToAnimateOrDraw返回true需要满足两个必要条件：

1. 网页当前的绘图表面可用，也就是网页的绘图表面已经创建，并且没有失效。这可以通过调用SchedulerStateMachine类的成员函数HasInitializedOutputSurface判断。

2. 网页的上一个CC Pending Layer Tree已经被激活为CC Active Layer Tree。这时候SchedulerStateMachine类的成员变量can_draw_的值会等于true。

满足了以上两个必要条件后，有四种情况会使得SchedulerStateMachine类的成员函数BeginFrameNeededToAnimateOrDraw返回true。

第一种情况是状态机的ForcedRedrawOnTimeoutState状态等于FORCED_REDRAW_STATE_WAITING_FOR_DRAW。从图6可以知道，这时候网页正在等待CC Pending Layer Tree激活为CC Active Layer Tree，以便对得到的CC Active Layer Tree。现在既然CC Pending Layer Tree已经激活，因此就需要对网页执行一个渲染操作。

后面三种情况需要满足第三个必要条件，就是网页当前是可见的。这时候SchedulerStateMachine类的成员变量visible_会等于true。

第二种情况是网页上次渲染时，有些分块（Tile）还没有准备就绪，也就是还没有光栅化完成。这时候SchedulerStateMachine类的成员变量swap_used_incomplete_tile_会等于true。这种情况也要求执行一个渲染操作。在执行这个渲染操作的时候，调度器会检查之前未准备就绪的分块是否已经就准备就绪。如果已经准备就绪，那么就可以对它们进行渲染。

第三种情况是网页现在正处于动画显示过程中。这时候SchedulerStateMachine类的成员变量needs_animate_的值会等于true。这时候要求执行一个渲染操作，就可以使得动画持续执行下去。

第四种情况是网页被要求进行重新绘制，或者是因为CC Pending Layer Tree刚刚激活为CC Active Layer Tree，或者网页的CC Layer Tree上一次同步到CC Pending Layer Tree的过程中还没有完成就被取消了。这时候要求执行一个渲染操作，就可以使得刚刚激活得到的CC Active Layer Tree可以马上进行渲染，或者恢复CC Layer Tree同步到CC Pending Layer Tree的操作。

回到SchedulerStateMachine类的成员函数BeginFrameNeeded中，如果网页使用的不是同步合成器，那么除了调用成员函数BeginFrameNeededToAnimateOrDraw得到的返回值等于true的情况，还有另外一种情况也会使得SchedulerStateMachine类的成员函数BeginFrameNeeded的返回值等于true，就是调用另外一个成员函数ProactiveBeginFrameWanted得到的返回值也等于true。

SchedulerStateMachine类的成员函数ProactiveBeginFrameWanted的实现如下所示：

// Proactively requesting the BeginImplFrame helps hide the round trip latency
// of the SetNeedsBeginFrame request that has to go to the Browser.
bool SchedulerStateMachine::ProactiveBeginFrameWanted() const {
  // The output surface is the provider of BeginImplFrames,
  // so we are not going to get them even if we ask for them.
  if (!HasInitializedOutputSurface())
    return false;

  // Do not be proactive when invisible.
  if (!visible_)
    return false;

  // We should proactively request a BeginImplFrame if a commit is pending
  // because we will want to draw if the commit completes quickly.
  if (needs_commit_ || commit_state_ != COMMIT_STATE_IDLE)
    return true;

  // If the pending tree activates quickly, we'll want a BeginImplFrame soon
  // to draw the new active tree.
  if (has_pending_tree_)
    return true;

  // Changing priorities may allow us to activate (given the new priorities),
  // which may result in a new frame.
  if (needs_manage_tiles_)
    return true;

  // If we just sent a swap request, it's likely that we are going to produce
  // another frame soon. This helps avoid negative glitches in our
  // SetNeedsBeginFrame requests, which may propagate to the BeginImplFrame
  // provider and get sampled at an inopportune time, delaying the next
  // BeginImplFrame.
  if (HasRequestedSwapThisFrame())
    return true;

  return false;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数ProactiveBeginFrameWanted返回true需要满足两个必要条件：

1. 网页的绘图表面已经创建好，并且没有失效。

2. 网页当前是可见的。

满足了以上两个必要条件后，有五种情况会使得SchedulerStateMachine类的成员函数ProactiveBeginFrameWanted返回true。

第一种情况是Main线程通知调度器网页的CC Layer Tree有新的变化，需要同步到CC Pending Layer Tree去。这时候SchedulerStateMachine类的成员变量needs_commit_会等于true。

第二种情况是状态机的CommitState状态不等于COMMIT_STATE_IDLE。这意味着Compositor线程正在执行同步CC Layer Tree和CC Pending Layer Tree的操作。为了正常推进这个操作，需要一个BEGIN_IMPL_FRAME操作，以便触发Scheduler类的成员函数ProcessScheduledActions的调用。这样就可以保证正常推进CC Layer Tree和CC Pending Layer Tree的同步操作。

第三种情况是网页存在一个CC Pending Layer Tree。这时候SchedulerStateMachine类的成员变量has_pending_tree_会等于true。这时候同样需要通过一个BEGIN_IMPL_FRAME操作推进这个CC Pending Layer Tree激活为CC Active Layer Tree。

第四种情况是Compositor线程需要对网页的分块进行光栅化操作。这时候SchedulerStateMachine类的成员变量needs_manage_tiles_会等于true。

这时候同样需要通过一个BEGIN_IMPL_FRAME操作推进光栅化操作的执行。

第五种情况是网页的当前帧已经渲染好，并且Render进程也已经向GPU发起了一个SwapBuffers操作，也就是请求Browser进程将网页的UI显示出来。这时候调用SchedulerStateMachine类的成员函数HasRequestedSwapThisFrame得到的返回值为true。这时候请求执行下一个BEGIN_IMPL_FRAME操作，可以尽快地检查网页是否需要绘制下一帧，也就是让Main线程或者Compositor线程尽快准备好下一个帧。

对比SchedulerStateMachine类的成员函数ProactiveBeginFrameWanted和BeginFrameNeededToAnimateOrDraw的实现可以发现，前者比后者更激进地请求执行下一个BEGIN_IMPL_FRAME操作。后者在被动要求重绘网页下一帧的时候才会返回true，而前者会主动准备去网页的下一帧的绘制操作。

回到Scheduler类的成员函数SetupNextBeginFrameIfNeeded中，它通过调用SchedulerStateMachine类的成员函数SupportsProactiveBeginFrame获知是否要发起下一个BEGIN_IMPL_FRAME操作的信息后，如果平台支持VSync信号，那么接下来它会调用另外一个成员函数SetupNextBeginFrameWhenVSyncThrottlingEnable根据VSync信号来准备下一个BEGIN_IMPL_FRAME操作。

Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnable的实现如下所示：

// When we are throttling frame production, we request BeginFrames
// from the OutputSurface.
void Scheduler::SetupNextBeginFrameWhenVSyncThrottlingEnabled(
    bool needs_begin_frame) {
  bool at_end_of_deadline =
      state_machine_.begin_impl_frame_state() ==
          SchedulerStateMachine::BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE;

  bool should_call_set_needs_begin_frame =
      // Always request the BeginFrame immediately if it wasn't needed before.
      (needs_begin_frame && !last_set_needs_begin_frame_) ||
      // Only stop requesting BeginFrames after a deadline.
      (!needs_begin_frame && last_set_needs_begin_frame_ && at_end_of_deadline);

  if (should_call_set_needs_begin_frame) {
    if (settings_.begin_frame_scheduling_enabled) {
      client_->SetNeedsBeginFrame(needs_begin_frame);
    } else {
      synthetic_begin_frame_source_->SetNeedsBeginFrame(
          needs_begin_frame, &begin_retro_frame_args_);
    }
    last_set_needs_begin_frame_ = needs_begin_frame;
  }

  PostBeginRetroFrameIfNeeded();
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

在两种情况下，Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnable会请求执行下一个BEGIN_IMPLP_FRAME操作。

第一种情况是调度器之前没有请求过调度执行下一个BEGIN_IMPLP_FRAME操作，这时候cheduler类的成员变量last_set_needs_begin_frame_等于false。此时参数needs_begin_frame的值又等于true，也就是状态机要求执行一个BEGIN_IMPLP_FRAME操作。这时候调度器就必须要调度执行一个BEGIN_IMPLP_FRAME操作。否则的话，就永远不会执行下一个BEGIN_IMPLP_FRAME操作。

第二种情况是调度器之前请求过调度执行下一个BEGIN_IMPLP_FRAME操作，并且这个BEGIN_IMPLP_FRAME操作的Deadline已经到来，以及参数needs_begin_frame的值等于false。试想这种情况，如果调度器不继续请求调度执行下一个BEGIN_IMPLP_FRAME操作的话，网页的渲染管线在上一次请求的BEGIN_IMPLP_FRAME操作执行完成后，就断开了。因此在这种情况下，也需要请求请示调度执行下一个BEGIN_IMPLP_FRAME操作。

如果对上述两种情况做一个总结，就是只有在前两个连续的BEGIN_IMPLP_FRAME操作期间，状态机都表示不需要绘制网页的下一帧的情况下，调度器才会停止请求调度执行下一个BEGIN_IMPLP_FRAME操作。通过这种方式保证网页的渲染管线可以持续地推进到稳定状态，而不会停留在上面提到的中间状态。

一旦决定需要请求调度执行下一个BEGIN_IMPLP_FRAME操作，本地变量should_call_set_needs_begin_frame的值就会被设置为true，这时候如果Scheduler类的成员变量settings_描述的SchedulerSettings对象的成员变量begin_frame_scheduling_enabled的值等于true，那么Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnabled就会调用成员变量client_指向的一个ThreadProxy对象的成员函数SetNeedsBeginFrame请求调度执行下一个BEGIN_IMPLP_FRAME操作，否则的话，调用另外一个成员变量synthetic_begin_frame_source_指向的一个SyntheticBeginFrameSource对象的成员函数SetNeedsBeginFrame请求调度执行下一个BEGIN_IMPLP_FRAME操作。

SyntheticBeginFrameSource类是通过软件方式调度执行BEGIN_IMPLP_FRAME操作的，实际上就是通过定时器，根据屏幕的刷新频率模拟生成VSync信号。这种方式产生的VSync信号会受到定时器精度的影响。例如，假设屏幕刷新频率为60fps，那么就应该每16.67ms生成一个VSync信号。如果定时器只能精确到整数毫秒，那么就意味着定时器只能在16ms或者17ms后触发定时器。如果一直都是使用16ms，那么就会导致VSync信号的产生频率大于 60fps。如果一直都使用17ms，那么就会导致VSync信号的产生频率小于 60fps。为了弥补定时精度带来的缺陷，SyntheticBeginFrameSource类会自动调整定时器的Timeout时间，使得VSync信号的平均周期等于16.67ms，也就是第一个VSync信号16ms后产生，第二个VSync信号17ms后产生，第三个VSync信号17ms后产生，第四VSync信号16ms后产生......，依次类推。这一点是SyntheticBeginFrameSource类通过使用另外一个类DelayBasedTimeSource实现的。有兴趣的读者可以自行分析DelayBasedTimeSource类的实现。

我们假设Scheduler类的成员变量settings_描述的SchedulerSettings对象的成员变量begin_frame_scheduling_enabled的值等于true，这表示屏幕支持以硬件方式产生VSync信号。在这种情况下，就直接利用屏幕产生的VSync信号调度BEGIN_IMPLP_FRAME操作即可。如前所述，这是通过调用ThreadProxy类的成员函数SetNeedsBeginFrame实现的。

请求了调度下一个BEGIN_IMPLP_FRAME操作之后，Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnabled还会调用另外一个成员函数PostBeginRetroFrameIfNeeded检查之前调度的BEGIN_IMPLP_FRAME操作是否都已经得到执行。有时候之前请求调度的BEGIN_IMPLP_FRAME操作在下一个VSync信号到来时，会被延时执行。这些被延时的BEGIN_IMPLP_FRAME操作会被保存在一个队列中，等待Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnabled执行。注意，这个延时与BEGIN_IMPLP_FRAME操作设置的Deadline是无关的。一个BEGIN_IMPLP_FRAME操作只有被执行时，才可以设置Deadline。这一点我们后面再进行分析。

接下来我们继续分析ThreadProxy类的成员函数SetNeedsBeginFrame的实现，以便了解调度器通过VSync信号调度执行BEGIN_IMPLP_FRAME操作的过程。

ThreadProxy类的成员函数SetNeedsBeginFrame的实现如下所示：

void ThreadProxy::SetNeedsBeginFrame(bool enable) {
  ......
  impl().layer_tree_host_impl->SetNeedsBeginFrame(enable);
  ......
}

这个函数定义在文件external/chromium_org/cc/trees/thread_proxy.cc中。

ThreadProxy类的成员函数SetNeedsBeginFrame实现是调用负责管理网页的CC Pending Layer Tree和CC Active Layer Tree的LayerTreeHostImpl对象的成员函数SetNeedsBeginFrame请求在下一个VSync信号到来时获得通知。

参数enable表示是否需要持续地请求VSync信号通知。从前面的调用过程可以知道，当网页需要渲染下一帧时，参数enable的值就会等于true。当参数enable的值等于false的时候，实际上是表示调度器要停止接收VSync信号。

LayerTreeHostImpl类的成员函数SetNeedsBeginFrame的实现如下所示：

void LayerTreeHostImpl::SetNeedsBeginFrame(bool enable) {
  if (output_surface_)
    output_surface_->SetNeedsBeginFrame(enable);
  else
    DCHECK(!enable);
}

这个函数定义在文件external/chromium_org/cc/trees/layer_tree_host_impl.cc中。

LayerTreeHostImpl类的成员变量output_surface_描述的就是网页的绘图表面。在接下来一篇文章中，我们会分析这个绘图表面的创建过程。这个绘图表面是通过一个CompositorOutputSurface对象描述的，因此LayerTreeHostImpl类的成员函数SetNeedsBeginFrame接下来会调用CompositorOutputSurface类的成员函数SetNeedsBeginFrame请求接收下一个VSync信号通知。

CompositorOutputSurface类的成员函数SetNeedsBeginFrame的实现如下所示：

void CompositorOutputSurface::SetNeedsBeginFrame(bool enable) {
  DCHECK(CalledOnValidThread());
  Send(new ViewHostMsg_SetNeedsBeginFrame(routing_id_, enable));
}

这个函数定义在文件external/chromium_org/content/renderer/gpu/compositor_output_surface.cc中。

CompositorOutputSurface类的成员函数SetNeedsBeginFrame向Browser进程发送一个类型为ViewHostMsg_SetNeedsBeginFrame的IPC消息。在Android平台上，这个IPC消息由RenderWidgetHostViewAndroid类的成员函数OnMessageReceived接收，如下所示：

bool RenderWidgetHostViewAndroid::OnMessageReceived(
    const IPC::Message& message) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(RenderWidgetHostViewAndroid, message)
    ......
    IPC_MESSAGE_HANDLER(ViewHostMsg_SetNeedsBeginFrame,
                        OnSetNeedsBeginFrame)
    ......
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_widget_host_view_android.cc中。

负责接收消息的RenderWidgetHostViewAndroid对象描述的是Browser进程为在Render进程中加载的网页创建一个RenderWidgetHostView控件。这个RenderWidgetHostView控件的创建过程，可以参考前面Chromium硬件加速渲染的OpenGL上下文绘图表面创建过程分析一文。

RenderWidgetHostViewAndroid类的成员函数OnMessageReceived将类型为ViewHostMsg_SetNeedsBeginFrame的IPC消息分发给成员函数OnSetNeedsBeginFrame处理，如下所示：

void RenderWidgetHostViewAndroid::OnSetNeedsBeginFrame(bool enabled) {
  if (enabled == needs_begin_frame_)
    return;

  TRACE_EVENT1("cc", "RenderWidgetHostViewAndroid::OnSetNeedsBeginFrame",
               "enabled", enabled);
  if (content_view_core_ && enabled)
    content_view_core_->GetWindowAndroid()->RequestVSyncUpdate();

  needs_begin_frame_ = enabled;
}

这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_widget_host_view_android.cc中。

RenderWidgetHostViewAndroid类的成员变量content_view_core_指向一个ContentViewCoreImpl对象。调用这个ContentViewCoreImpl对象的成员函数GetWindowAndroid可以获得一个WindowAndroid对象。有了这个WindowAndroid对象之后，就可以调用它的成员函数RequestVSyncUpdate请求获得下一个VSync信号通知。不过，在参数enabled等于true的情况下，才会执行这个操作。

WindowAndroid类的成员函数RequestVSyncUpdate通过Java层的Choreographer接口请求系统在下一个VSync信号到来时，给当前进程发送一个通知。当前进程获得这个通知后，会调用RenderWidgetHostViewAndroid类的成员函数OnVSync，这样RenderWidgetHostViewAndroid类就获得了VSync信号通知。

RenderWidgetHostViewAndroid类的成员函数OnVSync的实现如下所示：

void RenderWidgetHostViewAndroid::OnVSync(base::TimeTicks frame_time,
                                          base::TimeDelta vsync_period) {
  ......

  base::TimeTicks display_time = frame_time + vsync_period;

  // TODO(brianderson): Use adaptive draw-time estimation.
  base::TimeDelta estimated_browser_composite_time =
      base::TimeDelta::FromMicroseconds(
          (1.0f * base::Time::kMicrosecondsPerSecond) / (3.0f * 60));

  base::TimeTicks deadline = display_time - estimated_browser_composite_time;

  host_->Send(new ViewMsg_BeginFrame(
      host_->GetRoutingID(),
      cc::BeginFrameArgs::Create(frame_time, deadline, vsync_period)));

  if (needs_begin_frame_)
    content_view_core_->GetWindowAndroid()->RequestVSyncUpdate();
}

这个函数定义在文件external/chromium_org/content/browser/renderer_host/render_widget_host_view_android.cc中。

参数frame_time表示当前帧的时间，另外一个参数vsync_period表示屏幕的刷新周期。这两个参数相加，就得到下一帧的显示时间，记录在本地变量display_time中。

RenderWidgetHostViewAndroid类的成员函数OnVSync接下来计算Browser进程合成网页所需要的时间，记录在本地变量estimated_browser_composite_time中。这个时间等于1/3屏幕刷新周期，并且假设屏幕刷新频率为60fps。

用下一帧的显示时间display_time减去Browser进程合成网页所需要的时间estimated_browser_composite_time，就可以得到Render进程将UI提交给Browser进程合成的最迟时间，这个时间记录在本地变量deadline中。

再接下来，RenderWidgetHostViewAndroid类的成员函数OnVSync根据时间frame_time、deadline和vsync_period创建了一个BeginFrameArgs对象中，并且将该BeginFrameArgs对象封装成一个类型为ViewMsg_BeginFrame的IPC消息，发送给Render进程。Render进程接收到该消息后，就会根据上面计算出来的deadline时间调度执行一个BEGIN_IMPL_FRAME操作。

同时，我们还会看到，当RenderWidgetHostViewAndroid类的成员变量needs_begin_frame_等于true的时候，RenderWidgetHostViewAndroid类的成员函数OnVSync会继续请求获得下一个VSync信号通知，这样就能持续地通知Render进程执行BEGIN_IMPL_FRAME操作。

Render进程是通过CompositorOutputSurface类的成员函数OnMessageReceived接收类型为ViewMsg_BeginFrame的IPC消息的，如下所示：

void CompositorOutputSurface::OnMessageReceived(const IPC::Message& message) {
  ......
  IPC_BEGIN_MESSAGE_MAP(CompositorOutputSurface, message)
    ......
#if defined(OS_ANDROID)
    IPC_MESSAGE_HANDLER(ViewMsg_BeginFrame, OnBeginFrame);
#endif
  IPC_END_MESSAGE_MAP()
}

这个函数定义在文件external/chromium_org/content/renderer/gpu/compositor_output_surface.cc中。

从这里可以看到，CompositorOutputSurface类的成员函数OnMessageReceived将类型为ViewMsg_BeginFrame的IPC消息分发给成员函数OnBeginFrame处理，如下所示：

void CompositorOutputSurface::OnBeginFrame(const cc::BeginFrameArgs& args) {
  DCHECK(CalledOnValidThread());
  client_->BeginFrame(args);
}

这个函数定义在文件external/chromium_org/content/renderer/gpu/compositor_output_surface.cc中。

CompositorOutputSurface类的成员变量client_指向的是一个LayerTreeHostImpl对象，CompositorOutputSurface类的成员函数OnBeginFrame调用它的成员函数BeginFrame通知它现在可以执行一个BEGIN_IMPL_FRAME操作了。

LayerTreeHostImpl类的成员函数BeginFrame的实现如下所示：

void LayerTreeHostImpl::BeginFrame(const BeginFrameArgs& args) {
  client_->BeginFrame(args);
}

这个函数定义在文件external/chromium_org/cc/trees/layer_tree_host_impl.cc中。

LayerTreeHostImpl类的成员变量client_指向的是一个ThreadProxy对象，LayerTreeHostImpl类的成员函数BeginFrame调用它的成员函数BeginFrame通知执行一个BEGIN_IMPL_FRAME操作。

ThreadProxy类的成员函数BeginFrame的实现如下所示：

void ThreadProxy::BeginFrame(const BeginFrameArgs& args) {
  impl().scheduler->BeginFrame(args);
}

这个函数定义在文件external/chromium_org/cc/trees/thread_proxy.cc中。

ThreadProxy类的成员函数BeginFrame又通知调度器执行一个BEGIN_IMPL_FRAME操作，也就是调用Scheduler类的成员函数BeginFrame。

Scheduler类的成员函数BeginFrame的实现如下所示：

// BeginFrame is the mechanism that tells us that now is a good time to start
// making a frame. Usually this means that user input for the frame is complete.
// If the scheduler is busy, we queue the BeginFrame to be handled later as
// a BeginRetroFrame.
void Scheduler::BeginFrame(const BeginFrameArgs& args) {
  ......

  BeginFrameArgs adjusted_args(args);
  adjusted_args.deadline -= EstimatedParentDrawTime();

  bool should_defer_begin_frame;
  if (settings_.using_synchronous_renderer_compositor) {
    should_defer_begin_frame = false;
  } else {
    should_defer_begin_frame =
        !begin_retro_frame_args_.empty() || begin_retro_frame_posted_ ||
        !last_set_needs_begin_frame_ ||
        (state_machine_.begin_impl_frame_state() !=
         SchedulerStateMachine::BEGIN_IMPL_FRAME_STATE_IDLE);
  }

  if (should_defer_begin_frame) {
    begin_retro_frame_args_.push_back(adjusted_args);
    ......
    return;
  }

  BeginImplFrame(adjusted_args);
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数BeginFrame首先调用另外一个成员函数EstimatedParentDrawTime得到浏览器合成网页UI所需要的时间，并且从参数args传递进来的Deadline减去这个时间，从而得到新的Deadline。

Scheduler类的成员函数EstimatedParentDrawTime的实现如下所示：

class CC_EXPORT Scheduler {
 public:
  ......

  base::TimeDelta EstimatedParentDrawTime() {
    return estimated_parent_draw_time_;
  }

  ......

 private:
  ......

  base::TimeDelta estimated_parent_draw_time_;

  ......
};

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.h中。

从这里看到，Scheduler类的成员函数EstimatedParentDrawTime返回的是成员变量estimated_parent_draw_time_的值。这个成员变量的值是通过调用Scheduler类的成员函数SetEstimatedParentDrawTime设置的，如下所示：

void Scheduler::SetEstimatedParentDrawTime(base::TimeDelta draw_time) {
  DCHECK_GE(draw_time.ToInternalValue(), 0);
  estimated_parent_draw_time_ = draw_time;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数SetEstimatedParentDrawTime是被ThreadProxy类的成员函数SetEstimatedParentDrawTime调用的，如下所示：

void ThreadProxy::SetEstimatedParentDrawTime(base::TimeDelta draw_time) {
  impl().scheduler->SetEstimatedParentDrawTime(draw_time);
}

这个函数定义在文件external/chromium_org/cc/trees/thread_proxy.cc中。

ThreadProxy类的成员函数SetEstimatedParentDrawTime又是被LayerTreeHostImpl类的成员函数InitializeRenderer调用的，如下所示：

bool LayerTreeHostImpl::InitializeRenderer(
    scoped_ptr<OutputSurface> output_surface) {
  ......

  // TODO(brianderson): Don't use a hard-coded parent draw time.
  base::TimeDelta parent_draw_time =
      (!settings_.begin_frame_scheduling_enabled &&
       output_surface_->capabilities().adjust_deadline_for_parent)
          ? BeginFrameArgs::DefaultEstimatedParentDrawTime()
          : base::TimeDelta();
  client_->SetEstimatedParentDrawTime(parent_draw_time);

  ......
}

这个函数定义在文件external/chromium_org/cc/trees/layer_tree_host_impl.cc中。

LayerTreeHostImpl类的成员变量settings_指向的是一个LayerTreeSettings对象。当这个LayerTreeSettings对象的成员变量begin_frame_scheduling_enabled等于false的时候，表示调度器是利用前面提到的软件方式产生的VSync信号来调度执行BEGIN_IMPL_FRAME操作的。在这种情况下，前面分析的Scheduler类的成员函数BeginFrame通过参数args获得的Deadline还没有减去Browser进程合成网页UI所需要的时间。

LayerTreeHostImpl类的另外一人成员变量output_surface_描述的是网页的绘图表面。当网页的绘图表面有调整Browser进程合成网页UI所需要的时间的能力，并且调度器是利用前面提到的软件方式产生的VSync信号来调度执行BEGIN_IMPL_FRAME操作时，LayerTreeHostImpl类的成员函数InitializeRenderer就会将Browser进程合成网页UI所需要的时间设置为调用BeginFrameArgs类的静态成员函数DefaultEstimatedParentDrawTime获得的值。否则的话，就会将Browser进程合成网页UI所需要的时间为0。不过，从前面的分析可以知道，当调度器是利用前面提到的硬件方式产生的VSync信号来调度执行BEGIN_IMPL_FRAME操作时，在计算下一个BEGIN_IMPL_FRAME操作的Deadline时，已经将Browser进程合成网页UI所需要的时间考虑进去了，如前面分析的RenderWidgetHostViewAndroid类的成员函数OnVSync所示。

BeginFrameArgs类的静态成员函数DefaultEstimatedParentDrawTime的实现如下所示：

base::TimeDelta BeginFrameArgs::DefaultEstimatedParentDrawTime() {
  return base::TimeDelta::FromMicroseconds(16666 / 3);
}

这个函数定在文件external/chromium_org/cc/output/begin_frame_args.cc中。

BeginFrameArgs类的静态成员函数DefaultEstimatedParentDrawTime也是按照屏幕刷新频率为60fps计算Browser进程合成网页UI所需要的时间的，计算出来的时间等于1/3刷新周期，也就是（16.666 / 3）毫秒。

这意味着无论是利用硬件方式还是软件方式产生的VSync信号来调度BEGIN_IMPL_FRAME操作，Browser进程合成网页UI所需要的时间都是设置为1/3屏幕刷新周期，并且假定屏幕的刷新频率为60fps。

回到Scheduler类的成员函数BeginFrame中，它计算好下一个BEGIN_IMPL_FRAME操作的Deadline之后，接下来再看看是否要延迟执行下一个BEGIN_IMPL_FRAME操作。如果网页使用的是非同步合成器，那么有四种情况下需要延迟执行下一个BEGIN_IMPL_FRAME操作。

第一种情况是之前请求执行的BEGIN_IMPL_FRAME操作还没有全部被调度执行，这时候Scheduler类的成员变量begin_retro_frame_args_描述的一个std::deque不等于空。

第二种情况是在下一个VSync信号到来之前，已经有一个BEGIN_IMPL_FRAME操作在调度执行，这时候Scheduler类的成员变量begin_retro_frame_posted_的值等于true。

第三种情况是网页的下一帧实际上是不需要重新绘制的，这时候Scheduler类的成员变量last_set_needs_begin_frame_的值等于false。

第四种情况是状态机的BeginImplFrameState状态不等于BEGIN_IMPL_FRAME_STATE_IDLE，这意味有一个BEGIN_IMPL_FRAME操作正在执行。

此外，如果网页使用的是同步合成器，那么是不允许延迟执行BEGIN_IMPL_FRAME操作的。

对于需要延迟执行的BEGIN_IMPL_FRAME操作，与之对应的一个BeginFrameArgs对象都被保存在Scheduler类的成员变量begin_retro_frame_args_描述的一个std::deque中，而对于不需要延迟执行的BEGIN_IMPL_FRAME操作，Scheduler类的成员函数BeginFrame会马上调用另外一个成员函数BeginImplFrame执行它。

前面在分析Scheduler类的成员函数SetupNextBeginFrameWhenVSyncThrottlingEnable时提到，它在请求调度执行下一个BEGIN_IMPL_FRAME操作后，会马上调用另外一个成员函数PostBeginRetroFrameIfNeeded检查之前请求的BEGIN_IMPL_FRAME操作是否都已经得到执行，如下所示：

void Scheduler::PostBeginRetroFrameIfNeeded() {
  if (!last_set_needs_begin_frame_)
    return;

  if (begin_retro_frame_args_.empty() || begin_retro_frame_posted_)
    return;

  // begin_retro_frame_args_ should always be empty for the
  // synchronous compositor.
  DCHECK(!settings_.using_synchronous_renderer_compositor);

  if (state_machine_.begin_impl_frame_state() !=
      SchedulerStateMachine::BEGIN_IMPL_FRAME_STATE_IDLE)
    return;

  begin_retro_frame_posted_ = true;
  impl_task_runner_->PostTask(FROM_HERE, begin_retro_frame_closure_);
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

从前面的分析可以知道，当Scheduler类的成员变量begin_retro_frame_args_描述的一个std::deque不等于空的时候，意味着有BEGIN_IMPL_FRAME操作被延迟执行，而现在就是时候去执行它们了，不过要满足另外三个条件：

1. 网页的下一帧是需要重新绘制的，也就是Scheduler类的成员变量last_set_needs_begin_frame_的值等于true。

2. 当前没有延迟的BEGIN_IMPL_FRAME操作加入到Compositor线程的消息队列中等待执行，也就是Scheduler类的成员变量begin_retro_frame_posted_的值等于false。

3. 状态机的BeginImplFrameState状态不等于BEGIN_IMPL_FRAME_STATE_IDLE，这也意味着有目前有一个BEGIN_IMPL_FRAME正在执行过程中。

一旦Scheduler类的成员函数PostBeginRetroFrameIfNeeded决定要执行一个之前被延迟执行的BEGIN_IMPL_FRAME操作，它就会向Compositor线程的消息队列发送一个Task，这个Task通过Scheduler类的成员变量begin_retro_frame_closure_绑定了Scheduler类的成员函数BeginRetroFrame，并且会将Scheduler类的成员变量begin_retro_frame_posted_的值设置为true。

在上述情况下，Scheduler类的成员函数BeginRetroFrame很快就会在Compositor线程中执行，执行过程如下所示：

void Scheduler::BeginRetroFrame() {
  ......
  begin_retro_frame_posted_ = false;

  // If there aren't any retroactive BeginFrames, then we've lost the
  // OutputSurface and should abort.
  if (begin_retro_frame_args_.empty())
    return;

  // Discard expired BeginRetroFrames
  // Today, we should always end up with at most one un-expired BeginRetroFrame
  // because deadlines will not be greater than the next frame time. We don't
  // DCHECK though because some systems don't always have monotonic timestamps.
  // TODO(brianderson): In the future, long deadlines could result in us not
  // draining the queue if we don't catch up. If we consistently can't catch
  // up, our fallback should be to lower our frame rate.
  base::TimeTicks now = gfx::FrameTime::Now();
  base::TimeDelta draw_duration_estimate = client_->DrawDurationEstimate();
  while (!begin_retro_frame_args_.empty() &&
         now > AdjustedBeginImplFrameDeadline(begin_retro_frame_args_.front(),
                                              draw_duration_estimate)) {
    .....
    begin_retro_frame_args_.pop_front();
  }

  if (begin_retro_frame_args_.empty()) {
    DCHECK(settings_.throttle_frame_production);
    ......
  } else {
    BeginImplFrame(begin_retro_frame_args_.front());
    begin_retro_frame_args_.pop_front();
  }
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数BeginRetroFrame首先将成员变量begin_retro_frame_posted_的值设置为false，表示之前发送Compositor线程的消息队列中的执行延迟BEGIN_IMPL_FRAME操作的Task已经得到执行，这样调度器后面就可以继续执行下一个被延迟的BEGIN_IMPL_FRAME操作了。

接下来Scheduler类的成员函数BeginRetroFrame通过一个while循环将那些Deadline小于等于当前时间的BEGIN_IMPL_FRAME操作丢弃。这也就是说，那些被延迟的BEGIN_IMPL_FRAME操作，只有在它们的Deadline到来之前，才会被继续执行。一旦存在这样的BEGIN_IMPL_FRAME操作，它就会从Scheduler类的成员变量begin_retro_frame_args_描述的std::queue中移除，并且通过调用Scheduler类的成员函数BeginImplFrame执行。

Scheduler类的成员函数BeginImplFrame的实现如下所示：

void Scheduler::BeginImplFrame(const BeginFrameArgs& args) {
  ......
  DCHECK(state_machine_.begin_impl_frame_state() ==
         SchedulerStateMachine::BEGIN_IMPL_FRAME_STATE_IDLE);
  DCHECK(state_machine_.HasInitializedOutputSurface());
  ......

  base::TimeDelta draw_duration_estimate = client_->DrawDurationEstimate();
  begin_impl_frame_args_ = args;
  begin_impl_frame_args_.deadline -= draw_duration_estimate;

  if (!state_machine_.smoothness_takes_priority() &&
      state_machine_.MainThreadIsInHighLatencyMode() &&
      CanCommitAndActivateBeforeDeadline()) {
    state_machine_.SetSkipNextBeginMainFrameToReduceLatency();
  }

  ......
  state_machine_.OnBeginImplFrame(begin_impl_frame_args_);
  ......

  ProcessScheduledActions();

  state_machine_.OnBeginImplFrameDeadlinePending();
  ScheduleBeginImplFrameDeadline(
      AdjustedBeginImplFrameDeadline(args, draw_duration_estimate));
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数BeginImplFrame首先是调用成员变量client_指向的一个ThreadProxy对象的成员函数DrawDurationEstimate根据以往网页每一帧的绘制时间评估出下一帧的绘制时间，并且会从参数args描述的Deadline中减去该时间，从而得到新的Deadline。新的Deadline记录在Scheduler类的成员变量begin_impl_frame_args_中。

Scheduler类的成员函数BeginImplFrame接下来检查是否要在即将要执行的BEGIN_IMPL_FRAME操作期间，跳过执行BEGIN_MAIN_FRAME操作。BEGIN_MAIN_FRAME操作指的就是图2所示的第2个操作ACTION_SEND_BEGIN_MAIN_FRAME，也就是Main线程绘制CC Layer Tree的操作。

在满足以下三个条件的情况下，在即将要执行的BEGIN_IMPL_FRAME操作期间，BEGIN_MAIN_FRAME操作会被禁止执行：

1. 网页新内容优化于现有内容渲染，也就是如果CC Layer Tree的内容发生了变化，那么就需要尽快渲染。这时候调用Scheduler类的成员变量state_machine_指向的一个SchedulerStateMachine对象的成员函数smoothness_takes_priority得到的返回值等于false。

2. Main线程当前处于高延时模式。这时候调用Scheduler类的成员变量state_machine_指向的一个SchedulerStateMachine对象的成员函数MainThreadIsInHighLatencyMode得到的返回值等于true。

3. Main线程绘制CC Layer Tree的所需要的时间，加上将CC Layer Tree同步到CC Pending Layer Tree所需要的时间，小于即将要执行的BEGIN_IMPL_FRAME操作设置的Deadline。这时候调用Scheduler类的成员函数CanCommitAndActivateBeforeDeadline得到的返回值等于true。

对于上述3个条件，简单一点理解就是：如果Main线程当前处于高延时模式，那么就是在即将要执行的BEGIN_IMPL_FRAME操作期间，禁止执行BEGIN_MAIN_FRAME操作。

接下来我们先分析SchedulerStateMachine类的成员函数MainThreadIsInHighLatencyMode的实现，以便了解什么情况下Main线程会被认为处于高延时模式，它的实现如下所示：

bool SchedulerStateMachine::MainThreadIsInHighLatencyMode() const {
  // If a commit is pending before the previous commit has been drawn, we
  // are definitely in a high latency mode.
  if (CommitPending() && (active_tree_needs_first_draw_ || has_pending_tree_))
    return true;

  // If we just sent a BeginMainFrame and haven't hit the deadline yet, the main
  // thread is in a low latency mode.
  if (HasSentBeginMainFrameThisFrame() &&
      (begin_impl_frame_state_ == BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING ||
       begin_impl_frame_state_ == BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME))
    return false;

  // If there's a commit in progress it must either be from the previous frame
  // or it started after the impl thread's deadline. In either case the main
  // thread is in high latency mode.
  if (CommitPending())
    return true;

  // Similarly, if there's a pending tree the main thread is in high latency
  // mode, because either
  //   it's from the previous frame
  // or
  //   we're currently drawing the active tree and the pending tree will thus
  //   only be drawn in the next frame.
  if (has_pending_tree_)
    return true;

  if (begin_impl_frame_state_ == BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE) {
    // Even if there's a new active tree to draw at the deadline or we've just
    // swapped it, it may have been triggered by a previous BeginImplFrame, in
    // which case the main thread is in a high latency mode.
    return (active_tree_needs_first_draw_ || HasSwappedThisFrame()) &&
           !HasSentBeginMainFrameThisFrame();
  }

  // If the active tree needs its first draw in any other state, we know the
  // main thread is in a high latency mode.
  return active_tree_needs_first_draw_;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数MainThreadIsInHighLatencyMode是在即将要执行下一个BEGIN_IMPL_FRAME操作时调用的，也就是在即将要渲染网页的下一帧时调用的，这时候状态机的BeginImplFrameState状态等于BEGIN_IMPL_FRAME_STATE_IDLE，它判断Main线程是否处理高延时模式是通过观察网页前两两个帧的渲染情况进行的。在这种情况下，如果在网页之前两帧或者之前一帧的渲染过程中Main线程都有参与，并且到目前为止，渲染工作还没有完成，那么就认为Main线程耗费的时间太多了。从这个判断逻辑可以看出，渲染网页一帧所需要的时间，主要取决于Main线程所做的工作。如果Main线程所做的工作不多，那么Compositor线程做的工作也不多，这是一个正相关的关系。

当SchedulerStateMachine类的成员变量has_pending_tree_等于true的时候，表示前一帧的CC Pending Layer Tree还没有完成光栅化操作。这种情况就认为是前一帧的渲染还没有完成。因此，这时候Main线程处于高延时模式。

当SchedulerStateMachine类的成员变量active_tree_needs_first_draw_等于true的时候，表示前一帧的CC Pending Layer Tree刚刚被激活为CC Active Layer Tree，并且正在等待第一次渲染。这种情况也认为是前一帧的渲染还没有完成。因此，这时候Main线程处于高延时模式。

当调用SchedulerStateMachine类的成员函数CommitPending得到的返回值等于true的时候，表示状态机的CommitState状态等COMMIT_STATE_BEGIN_MAIN_FRAME_SENT、COMMIT_STATE_BEGIN_MAIN_FRAME_STARTED或者COMMIT_STATE_READY_TO_COMMIT，这时候表示Main线程正在将CC Layer Tree同步到CC Pending Layer Tree去。这种情况也认为是前一帧的渲染还没有完成。因此，这时候Main线程处于高延时模式。

由于只有在Main线程将CC Layer Tree同步到CC Pending Layer Tree去之后，才会得到一个新的CC Pending Layer Tree。因此，当调用SchedulerStateMachine类的成员函数CommitPending得到的返回值等于true的时候，如果SchedulerStateMachine类的成员变量has_pending_tree_active_tree_needs_first_draw_也等于true，那么就会认为网页之前的两帧都还没有完成渲染工作。换句话就说，第三帧马上要渲染的时候，第一帧还没有光栅化操作或者刚刚完成光栅化操作但是还未来得及第一次渲染，第二帧正在将CC Layer Tree同步到新的CC Pending Layer Tree去。这时候就很明确地确定Main线程处于高延时模式。

如果SchedulerStateMachine类的成员函数MainThreadIsInHighLatencyMode不是在即将要执行下一个BEGIN_IMPL_FRAME操作时调用的，也就是状态机的BeginImplFrameState状态不等于BEGIN_IMPL_FRAME_STATE_IDLE。我们分两种情况讨论。

第一种情况是状态机的BeginImplFrameState状态等于BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING或者BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME。这时候是允许Main线程对CC Layer Tree进行重绘的，也就是这时候允许调度器调度执行一个ACTION_SEND_MAIN_BEGIN_FRAME操作。在这种情况下，如果调度器确实也调度执行了一个ACTION_SEND_MAIN_BEGIN_FRAME操作，也就是调用SchedulerStateMachine类的成员函数HasSentBeginMainFrameThisFrame得到的返回值等于true，那么可以确定Main线程不是处于高延时模式。这是因为调度器在前一帧的渲染工作完成之后才会调度执行一个ACTION_SEND_MAIN_BEGIN_FRAME操作。

第二种情况是状态机的BeginImplFrameState状态等于BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE。这时候如果有一个刚刚激活的CC Active Layer Tree，并且它还没有被渲染，也就是SchedulerStateMachine类的成员变量active_tree_needs_first_draw_的值等于true，这也是说明前一帧还没有渲染完成。因此，这时候会认为Main线程处于高延时模式。另一方面，这时候如果调用SchedulerStateMachine类的成员函数HasSwappedThisFrame得到的返回值等于true，那么就说明有一帧刚刚被渲染。但是这一帧有可能不是当前帧，而是前一帧。这一点可以通过调用SchedulerStateMachine类的成员函数HasSentBeginMainFrameThisFrame判断。如果得到的返回值等于false，那么就说明在当前的BEGIN_IMPL_FRAME操作期间，没有执行过ACTION_SEND_MAIN_BEGIN_FRAME操作。这意味着刚刚被渲染的是上一帧的内容。由于上一帧的内容是在当前的BEGIN_IMPL_FRAME操作的Deadline到来时才渲染完成，Main线程就会认为处于高延时模式。理想的情况是，上一帧在下一帧的Deadline到来之前就渲染完成。

回到Scheduler类的成员函数BeginImplFrame中，如果这时候Main线程被认为处于高延时模式，那么调度器就会给状态机就会设置一个标记，禁止它在接下来的BEGIN_IMPL_FRAME操作中，执行ACTION_SEND_MAIN_BEGIN_FRAME操作，也就是禁止Main线程提交新的内容给Compositor线程渲染。这是通过调用SchedulerStateMachine类的成员函数etSkipNextBeginMainFrameToReduceLatency实现的，如下所示：

void SchedulerStateMachine::SetSkipNextBeginMainFrameToReduceLatency() {
  skip_next_begin_main_frame_to_reduce_latency_ = true;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数etSkipNextBeginMainFrameToReduceLatency将成员变量skip_next_begin_main_frame_to_reduce_latency_的值设置为true，这样在接下来的BEGIN_IMPL_FRAME操作期间，状态机就不会通知调度器执行ACTION_SEND_MAIN_BEGIN_FRAME操作。

继续回到Scheduler类的成员函数BeginImplFrame中，它接下来就分四个阶段执行一个BEGIN_IMPL_FRAME操作。

第一阶段是将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING，然后调用Scheduler类的成员函数ProcessScheduledActions允许调度器调度执行其它操作。我们结合图1看，这实际上就是允许在当前的BEGIN_IMPL_FRAME操作的Deadline到来前，执行其它操作。如果这些操作能在当前的BEGIN_IMPL_FRAME操作的Deadline到来前完成，那么就不但不会影响当前帧的渲染，还可以让调度器提前去做下一帧的工作。例如，这时候调度器可以通知Main线程去绘制下一帧的内容，也就是执行一个ACTION_SEND_MAIN_BEGIN_FRAME操作。

将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING是通过调用SchedulerStateMachine类的成员函数OnBeginImplFrame实现的，如下所示：

void SchedulerStateMachine::OnBeginImplFrame(const BeginFrameArgs& args) {
  AdvanceCurrentFrameNumber();
  begin_impl_frame_args_ = args;
  DCHECK_EQ(begin_impl_frame_state_, BEGIN_IMPL_FRAME_STATE_IDLE) << *AsValue();
  begin_impl_frame_state_ = BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数OnBeginImplFrame除了将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING，还会增加状态机内部维护的一个帧号，这是通过调用另外一个成员函数AdvanceCurrentFrameNumber实现的，如下所示：

void SchedulerStateMachine::AdvanceCurrentFrameNumber() {
  current_frame_number_++;

  // "Drain" the ManageTiles funnel.
  if (manage_tiles_funnel_ > 0)
    manage_tiles_funnel_--;

  skip_begin_main_frame_to_reduce_latency_ =
      skip_next_begin_main_frame_to_reduce_latency_;
  skip_next_begin_main_frame_to_reduce_latency_ = false;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

SchedulerStateMachine类的成员函数AdvanceCurrentFrameNumber将成员变量current_frame_number_的值增加1，表示调度器要执行一个新的BEGIN_IMPL_FRAME操作。这个成员变量描述的是当前执行的BEGIN_IMPL_FRAME操作的顺序号。通过这个顺序号可以判断状态机的某些状态是与上一帧相关的，还是与当前帧相关的。

除了设置当前执行的BEGIN_IMPL_FRAME操作的顺序号，SchedulerStateMachine类的成员函数AdvanceCurrentFrameNumber还会判断另外一个成员变量manage_tiles_funnel_的值是否大于0。如果大于0，那么就将它的值减少1。这个成员变量用来控制每一个BEGIN_IMPL_FRAME操作只执行一次分块光栅化操作。

SchedulerStateMachine类的成员函数AdvanceCurrentFrameNumber最后将成员变量skip_next_begin_main_frame_to_reduce_latency_的值设置到另外一个成员变量skip_next_begin_main_frame_to_reduce_latency_中去，使得前者的值只在当前帧中生效。

回到Scheduler类的成员函数BeginImplFrame中，从另外一个成员函数ProcessScheduledActions返回来后，第一阶段工作就执行完成。接着开始执行第二阶段工作，也就是等待当前BEGIN_IMPL_FRAME操作的Deadline的到来。

第二阶段工作由三部分组成。第一部分是调用SchedulerStateMachine类的成员函数OnBeginImplFrameDeadlinePending将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME。第二部分是调用Scheduler类的成员函数AdjustedBeginImplFrameDeadline检查是否需要调整Deadline。第三部分是调用Scheduler类的成员函数ScheduleBeginImplFrameDeadline等待Deadline的到来。

SchedulerStateMachine类的成员函数OnBeginImplFrameDeadlinePending的实现如下所示：

void SchedulerStateMachine::OnBeginImplFrameDeadlinePending() {
  DCHECK_EQ(begin_impl_frame_state_,
            BEGIN_IMPL_FRAME_STATE_BEGIN_FRAME_STARTING)
      << *AsValue();
  begin_impl_frame_state_ = BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

Scheduler类的成员函数AdjustedBeginImplFrameDeadline的实现如下所示：

base::TimeTicks Scheduler::AdjustedBeginImplFrameDeadline(
    const BeginFrameArgs& args,
    base::TimeDelta draw_duration_estimate) const {
  if (settings_.using_synchronous_renderer_compositor) {
    // The synchronous compositor needs to draw right away.
    return base::TimeTicks();
  } else if (state_machine_.ShouldTriggerBeginImplFrameDeadlineEarly()) {
    // We are ready to draw a new active tree immediately.
    return base::TimeTicks();
  } else if (state_machine_.needs_redraw()) {
    // We have an animation or fast input path on the impl thread that wants
    // to draw, so don't wait too long for a new active tree.
    return args.deadline - draw_duration_estimate;
  } else {
    // The impl thread doesn't have anything it wants to draw and we are just
    // waiting for a new active tree, so post the deadline for the next
    // expected BeginImplFrame start. This allows us to draw immediately when
    // there is a new active tree, instead of waiting for the next
    // BeginImplFrame.
    // TODO(brianderson): Handle long deadlines (that are past the next frame's
    // frame time) properly instead of using this hack.
    return args.frame_time + args.interval;
  }
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

如前所述，如果网页使用的是同步合成器，也就是Scheduler类的成员变量settings_指向的SchedulerSettings对象的成员变量using_synchronous_renderer_compositor的值等于true，那么是不允许当前BEGIN_IMPL_FRAME操作设置Deadline的，因此这里将Deadline调整为0。

如果状态机表示现在马上渲染网页，也就是调用SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly得到的返回值等于true，也需要将Deadline调整为0，以便可以马上执行渲染网页的操作。前面我们已经分析过SchedulerStateMachine类的成员函数ShouldTriggerBeginImplFrameDeadlineEarly的实现。

如果状态机表示网页现在需要马上进行渲染，也就是调用SchedulerStateMachine类的成员函数needs_redraw得到的返回值为true，那么需要减小Deadline的值。减小的值刚好就等于一次渲染所需要的时间。这个时间由参数draw_duration_estimate指定。这种情况一般是由动画或者用户输入触发的。

最后，如果没有特殊情况，那么当前BEGIN_IMPL_FRAME操作就是按照前面计算好的Deadline执行。

Scheduler类的成员函数ScheduleBeginImplFrameDeadline的实现如下所示：

void Scheduler::ScheduleBeginImplFrameDeadline(base::TimeTicks deadline) {
  if (settings_.using_synchronous_renderer_compositor) {
    // The synchronous renderer compositor has to make its GL calls
    // within this call.
    // TODO(brianderson): Have the OutputSurface initiate the deadline tasks
    // so the sychronous renderer compositor can take advantage of splitting
    // up the BeginImplFrame and deadline as well.
    OnBeginImplFrameDeadline();
    return;
  }
  begin_impl_frame_deadline_task_.Cancel();
  begin_impl_frame_deadline_task_.Reset(begin_impl_frame_deadline_closure_);

  base::TimeDelta delta = deadline - gfx::FrameTime::Now();
  if (delta <= base::TimeDelta())
    delta = base::TimeDelta();
  impl_task_runner_->PostDelayedTask(
      FROM_HERE, begin_impl_frame_deadline_task_.callback(), delta);
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

Scheduler类的成员函数ScheduleBeginImplFrameDeadline首先检查网页使用的是否是同步合成器。如果是的话，它就会忽略掉正在执行的BEGIN_IMPL_FRAME操作的Deadline，也就是马上调用Scheduler类的成员函数OnBeginImplFrameDeadline执行一个BEGIN_IMPL_FRAME操作。

如果网页使用的不是同步合成器，那么Scheduler类的成员函数ScheduleBeginImplFrameDeadline就会计算当前时间与参数deadline指定的时间的差值delta，并且向Compositor线程的消息队列发送一个Task，指定该Task在delta时间后执行。向Compositor线程的消息队列发送的Task通过Scheduler类的成员变量begin_impl_frame_deadline_closure_绑定绑定了Scheduler类的成员函数OnBeginImplFrameDeadline。因此，在delta时间后，Scheduler类的成员函数OnBeginImplFrameDeadline就会在Compositor线程中执行。

Scheduler类的成员函数OnBeginImplFrameDeadline执行的BEGIN_IMPL_FRAME操作的第三阶段和第四阶段的工作，如下所示：

void Scheduler::OnBeginImplFrameDeadline() {
  ......

  // We split the deadline actions up into two phases so the state machine
  // has a chance to trigger actions that should occur durring and after
  // the deadline separately. For example:
  // * Sending the BeginMainFrame will not occur after the deadline in
  //     order to wait for more user-input before starting the next commit.
  // * Creating a new OuputSurface will not occur during the deadline in
  //     order to allow the state machine to "settle" first.
  state_machine_.OnBeginImplFrameDeadline();
  ProcessScheduledActions();
  state_machine_.OnBeginImplFrameIdle();
  ProcessScheduledActions();

  ......
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler.cc中。

第三阶段和第四阶段的工作都是通过调用Scheduler类的成员函数ProcessScheduledActions完成的。不过，第三阶段的工作是在将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE的情况下执行的，而第四阶段的工作是在将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_IDLE的情况下执行的。

通过调用SchedulerStateMachine类的成员函数OnBeginImplFrameDeadline可以将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME，如下所示：

void SchedulerStateMachine::OnBeginImplFrameDeadline() {
  DCHECK_EQ(begin_impl_frame_state_, BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME)
      << *AsValue();
  begin_impl_frame_state_ = BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

通过调用SchedulerStateMachine类的成员函数OnBeginImplFrameIdle可以将状态机的BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_IDLE，如下所示：

void SchedulerStateMachine::OnBeginImplFrameIdle() {
  DCHECK_EQ(begin_impl_frame_state_, BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE)
      << *AsValue();
  begin_impl_frame_state_ = BEGIN_IMPL_FRAME_STATE_IDLE;
}

这个函数定义在文件external/chromium_org/cc/scheduler/scheduler_state_machine.cc中。

状态机的BeginImplFrameState状态等于BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE的时候，调度器主要是调度Compositor线程执行图2所示的第6个操作ACTION_DRAW_AND_SWAP_FORCED。但是它也允许执行另外的一些操作，例如BEGIN_MAIN_FRAME操作，即图2所示的第2个操作ACTION_SEND_MAIN_FRAME。我们知道，状态机的BeginImplFrameState状态在等于BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE之前，等于BEGIN_IMPL_FRAME_STATE_INSIDE_BEGIN_FRAME，并且这两个状态之间是存在一个时间差的。如果在这个时间差内，用户产生了一个输入事件，改变了CC Layer Tree的内容。等到状态机的BeginImplFrameState状态等于BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE的时候，如果允许执行一个BEGIN_MAIN_FRAME操作，那么就能够重新绘制CC Layer Tree的内容，并且提交给Compositor线程渲染，那么就会让用户觉得网页的响应是很快。否则的话，用户的这个输入，至少要等到下一帧才得到响应。

同时，状态机在BEGIN_IMPL_FRAME操作执行完成后，会禁止执行BEGIN_MAIN_FRAME操作。也就是说，在同一帧内，BEGIN_MAIN_FRAME操作只可以在BEGIN_IMPL_FRAME操作之前执行。这样做是出于这样的一个考虑。如果在同一帧内，BEGIN_MAIN_FRAME操作在BEGIN_IMPL_FRAME操作后执行，那么执行的结果要等到接下来的第2个VSync信号到来时才能表现出来。可是，从现在起到接下来的第1个VSync信号到来期间，用户可能会产生输入事件。由于前面已经执行了一个BEGIN_MAIN_FRAME操作，那么上述用户产生的输入事件需要通过另外一个BEGIN_MAIN_FRAME操作才能反映出来。但是，另外这个BEGIN_MAIN_FRAME操作要等到接下来的第3个VSync信号到来时才能表现出来。这样的结果就会让用户觉得网页的响应不够快。如果禁止在同一帧内，BEGIN_MAIN_FRAME操作不能在BEGIN_IMPL_FRAME操作之前执行，那么上述用户产生的输入事件就可以纳入下一个BEGIN_MAIN_FRAME操作中。注意，这个BEGIN_MAIN_FRAME是在接下来的第1个VSync信号到来时执行的，因此它绘制出来的内容在接下来的第2个VSync信号到来时就会得到显示。这种方式就比前面一种方式提前了一个VSync信号，因此能让用户觉得网页的响应很快。

BEGIN_IMPL_FRAME操作执行完成之后，需要将状态机的BeginImplFrameState状态从BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE修改为BEGIN_IMPL_FRAME_STATE_IDLE。这是因为当状态机的BeginImplFrameState状态等于BEGIN_IMPL_FRAME_STATE_INSIDE_DEADLINE的时候，有些操作是不允许执行的，例如为网页创建绘图表面的操作，即图2所示的第1个操作ACTION_BEGIN_OUTPUT_SURFACE_CREATION。但是这时候实际上是可以执行这个操作的，主要将BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_IDLE即可。

将BeginImplFrameState状态设置为BEGIN_IMPL_FRAME_STATE_IDLE之后，之所以又要再次调用Scheduler类的成员函数ProcessScheduledActions，就是为了检查是否有诸如ACTION_BEGIN_OUTPUT_SURFACE_CREATION之类的操作需要执行。如果有的话，就可以马上执行它们。

至此，我们就分析完成调度器的实现了。虽然与调度器相关的类只有Scheduler和SchedulerStateMachine两个，并且它们的代码加起来也只有2000行左右，不过它们的实现逻辑还是挺复杂的，理解起来会有一点的困难。这需要我们反复地阅读和消化。另外，这篇文章分析的也仅仅是调度器的实现框架，它内部还会涉及到图2所示的每一个操作都是如何调度执行的。在接下来的一系列文章中，我们就会具体地分析它们。等到全部分析完成后，我们再回过头来看这篇文章，就会容易理解很多。在接下来的一篇文章中，我们就先分析图2所示的第1个操作ACTION_BEGIN_OUTPUT_SURFACE_CREATION的执行过程，即网页绘图表面的创建过程，敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

你可能感兴趣的:(android,scheduler,chromium)

android系统selinux中添加新属性property 辉色投像
1.定位/android/system/sepolicy/private/property_contexts声明属性开头：persist.charge声明属性类型：u:object_r:system_prop:s0图12.定位到android/system/sepolicy/public/domain.te删除neverallow{domain-init}default_prop:property
2.2.6 通知类控件 Toast、Menu 常思行
本文例程下载：WillFlow_Toast、WillFlowMenu一、什么是Toast？Toast也被叫做吐司，是Android系统提供的一种非常好的提醒方式，在程序中可以使用它将一些短小的信息通知给用户，它有如下两个特点：Toast是没有焦点的Toast显示的时间有限过一定的时间就会自动消失所以一般来讲Toast的使用并不会影响我们的正常操作，并且它通常不会占用太大的屏幕空间，有着良好的用户体
Java爬虫框架（一）--架构设计狼图腾-狼之传说 java 框架 java 任务 html解析器存储电子商务
一、架构图那里搜网络爬虫框架主要针对电子商务网站进行数据爬取，分析，存储，索引。爬虫：爬虫负责爬取，解析，处理电子商务网站的网页的内容数据库：存储商品信息索引：商品的全文搜索索引Task队列：需要爬取的网页列表Visited表：已经爬取过的网页列表爬虫监控平台：web平台可以启动，停止爬虫，管理爬虫，task队列，visited表。二、爬虫1.流程1)Scheduler启动爬虫器，TaskMast
mac 备份android 手机通讯录导入iphone,iphone如何导出通讯录（轻松教你iPhone备份通讯录的方法）... weixin_39762838 mac 备份android 手机通讯录导入iphone
在日新月异的手机更替中，换手机已经成为一个非常稀松平常的事情，但将旧手机上面的通讯录导入到新手机还是让不少小伙伴为难，本篇将给大家详细讲解这方面的知识：“苹果手机通讯录怎么导入到新手机”及“安卓手机通讯录导入到新手机”的方法。一、苹果手机通讯录导入到新手机常用方法(SIM卡导入)在苹果手机主频幕上找到“设置”，单击进入设置菜单，下拉菜单列表，点击“邮件、通讯录、日历”，然后找到“导入SIM卡通讯录
android 更改窗口的层次,浮窗开发之窗口层级 Ms.Bu android 更改窗口的层次
最近在项目中遇到了这样的需求：需要在特定的其他应用之上悬浮自己的UI交互(拖动、输入等复杂的UI交互)，和九游的浮窗类似，不过我们的比九游的体验更好，我们越过了很多授权的限制。浮窗效果很多人都知道如何去实现一个简单的浮窗，但是却很少有人去深入的研究背后的流程机制，由于项目中浮窗交互比较复杂，遇到了些坑查看了很多资料，故总结浮窗涉及到的知识点：窗口层级关系(浮窗是如何“浮”的)？浮窗有哪些限制，如何
Android应用性能优化轻口味 Android
Android手机由于其本身的后台机制和硬件特点，性能上一直被诟病，所以软件开发者对软件本身的性能优化就显得尤为重要；本文将对Android开发过程中性能优化的各个方面做一个回顾与总结。Cache优化ListView缓存：ListView中有一个回收器，Item滑出界面的时候View会回收到这里，需要显示新的Item的时候，就尽量重用回收器里面的View；每次在getView函数中inflate新
Android实现监听事件的方法 Amy木婉清
1.通过内部类实现2.通过匿名内部类实现3.通过事件源所在类实现4.通过外部类实现5.布局文件中onclick属性(针对点击事件)1.通过内部类实现代码:privateButtonmBtnEvent;//oncreate中mBtnEvent.setOnClickListener(newOnClick());//内部类实现监听classOnClickimplementsView.OnClickLis
高级UI<第二十四篇>：Android中用到的矩阵常识 NoBugException
（1）定义在数学中，矩阵（Matrix）是一个按照长方阵列排列的复数或实数集合。由m×n个数aij排成的m行n列的数表称为m行n列的矩阵，简称m×n矩阵。记作：图片.png这m×n个数称为矩阵A的元素，简称为元，数aij位于矩阵A的第i行第j列，称为矩阵A的(i,j)元，以数aij为(i,j)元的矩阵可记为(aij)或(aij)m×n，m×n矩阵A也记作Amn。元素是实数的矩阵称为实矩阵，元素是复
RK3229_Android9.0_Box 4G模块EC200A调试 suifen_ 网络
0、kernel修改这部分完全可以参考Linux的移植：RK3588EC200A-CN【4G模块】调试_rkec200a-cn-CSDN博客1、修改device/rockchip/rk322xdiff--gita/device.mkb/device.mkindexec6bfaa..e7c32d1100755---a/device.mk+++b/device.mk@@-105,6+105,8@@en
kt文件和java文件_Java与Kotlin之间怎样进行互操作铭空间 kt文件和java文件
Java与Kotlin之间怎样进行互操作发布时间：2021-02-0210:50:43来源：亿速云阅读：98作者：小新这篇文章主要介绍了Java与Kotlin之间怎样进行互操作，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。前言目前kotlin是谷歌首推的开发Android的语言，但由于历史原因，我们绝大部分项目依旧还是以Java为主
Android shell 常用 debug 命令晨春计 Audio debug android linux
目录1、查看版本2、am命令3、pm命令4、dumpsys命令5、sed命令6、log定位查看APK进程号7、log定位使用场景1、查看版本1.1、Android串口终端执行getpropro.build.version.release#获取Android版本uname-a#查看linux内核版本信息uname-r#单独查看内核版本1.2、linux服务器执行lsb_release-a#查看Lin
2024年最全Flutter如何和Native通信-Android视角，Electron开发Android界面 2401_84544531 程序员 android 面试学习
总结【Android详细知识点思维脑图（技能树）】其实Android开发的知识点就那么多，面试问来问去还是那么点东西。所以面试没有其他的诀窍，只看你对这些知识点准备的充分程度。so，出去面试时先看看自己复习到了哪个阶段就好。虽然Android没有前几年火热了，已经过去了会四大组件就能找到高薪职位的时代了。这只能说明Android中级以下的岗位饱和了，现在高级工程师还是比较缺少的，很多高级职位给的薪
分享一个基于python的电子书数据采集与可视化分析 hadoop电子书数据分析与推荐系统 spark大数据毕设项目（源码、调试、LW、开题、PPT) 计算机源码社 Python项目大数据大数据 python hadoop 计算机毕业设计选题计算机毕业设计源码数据分析 spark毕设
作者：计算机源码社个人简介：本人八年开发经验，擅长Java、Python、PHP、.NET、Node.js、Android、微信小程序、爬虫、大数据、机器学习等，大家有这一块的问题可以一起交流！学习资料、程序开发、技术解答、文档报告如需要源码，可以扫取文章下方二维码联系咨询Java项目微信小程序项目Android项目Python项目PHP项目ASP.NET项目Node.js项目选题推荐项目实战|p
android ndk 开发jni调用对象方法，数组参数 wulongkou 开发问题安卓的事 ndk android studio jni
一、JNI和NDK关系JNI是Java语言提供的Java和C/C++相互沟通的机制，Java可以通过JNI调用本地的C/C++代码，本地的C/C++的代码也可以调用java代码。JNI是本地编程接口，Java和C/C++互相通过的接口。Java通过C/C++使用本地的代码的一个关键性原因在于C/C++代码的高效性。NDK是一系列工具的集合。它提供了一系列的工具，帮助开发者快速开发C（或C++）的动
Android jni中数组参数的传递方式 lokeyme Andriod android开发 JNI NDK java c语言
1、背景今天调试了一下Androidjni关于Java中调用C代码的程序，发现我的数组参数传递方式不对，导致值传递不正确，我的方法是：C代码，入口函数#include#includejintJava_sony_MedicalRecordDemo_MainActivity_decryptionSuccess(JNIEnv*env,jobjectthiz,jintAttr[]){returnAttr[
1-1.Jetpack 之 Navigation 简单编码模板我命由我12345 Android -Jetpack 简化编程 java java-ee android-studio android studio 安卓 android jetpack
一、Navigation1、Navigation概述Navigation是Jetpack中的一个重要成员，它主要是结合导航图（NavigationGraph）来控制和简化Fragment之间的导航，即往哪里走，该怎么走2、Navigate引入在模块级build.gradle中引入相关依赖implementation'androidx.navigation:navigation-fragment:2
python logging模块默认日志级别_一看就懂，Python 日志 logging 模块详解及应用路易·罗莎 python logging模块默认日志级别
日志概述百度百科的日志概述：Windows网络操作系统都设计有各种各样的日志文件，如应用程序日志，安全日志、系统日志、Scheduler服务日志、FTP日志、WWW日志、DNS服务器日志等等，这些根据你的系统开启的服务的不同而有所不同。我们在系统上进行一些操作时，这些日志文件通常会记录下我们操作的一些相关内容，这些内容对系统安全工作人员相当有用。比如说有人对系统进行了IPC探测，系统就会在安全日志
Android JetPack架构——结合记事本Demo一篇打通对Sqlite的增删改查结合常用jetpack架构应用 erhtre 程序员 android jetpack 架构 sqlite
为什么要用Jetpack?========================================================================关于为什么要用Jetpack，我参考了许多的博客和官方文档，开阔了我对Android生态圈的理解和认识，在Jetpack推出前出现的许许多多强大的第三方框架与语言，典型代表无疑是强大的RxJava在Jetpack仍然有许多粉丝在一
Android干净架构MVI模板使用指南井美婵Toby
Android干净架构MVI模板使用指南android-clean-architecture-mvi-boilerplateAforkofourcleanarchitectureboilerplateusingtheModel-View-Intentpattern项目地址:https://gitcode.com/gh_mirrors/an/android-clean-architecture-mv
⭐Unity 安卓环境中正确地读取和处理 XML 文件惊鸿醉 Unity unity android xml
写了一个选择题Demo，电脑包和编辑器内无问题，但是打包安卓手机之后题目无法正常使用，想到的是安卓环境中正确地读取文件的问题改进方案：1.由于XmlDocument.Load方法在Android上的路径问题（由于文件位于APK内部，无法像在文件系统中那样直接访问），需要先使用UnityWebRequest来异步加载文件内容，然后再解析XML。2.异步处理：修改你的代码，以支持异步文件加载和处理，这
《Android进阶之光》读书笔记 soleil雪寂读书笔记 #Android进阶之光
文章目录第1章Android新特性1.1.Android5.0新特性1.2.RecyclerView1.1.4.3种Notification1.1.5.Toolbar与Palette1.1.6.Palette1.2.Android6.0新特性1.2.2.运行时权限机制1.3.Android7.0新特性第2章MaterialDesign2.2.DesignSupportLibrary常用控件详解第3
《Android进阶之光》— Android 书籍王睿丶 Android 永无止境《Android进阶之光》Android书籍 Android phoenix 移动开发
文章目录第1章Android新特性1第2章MaterialDesign48第3章View体系与自定义View87第4章多线程编程165第5章网络编程与网络框架204第6章设计模式271第7章事件总线308第8章函数响应式编程333第9章注解与依赖注入框架382第10章应用架构设计422第11章系统架构与MediaPlayer框架460出版年:2017-7简介：《Android进阶之光》是一本And
《android进阶之光》——多线程编程（上） TAING要一直努力读书笔记
今天了解了下多线程编程，知识点如下：进程与线程：进程是什么？线程是什么？进程可以看作是程序的实体，是线程的容器，是受操作系统管理的基本运行单元，例如exe文件就是一个进程。线程是进程运行的一些子任务，是操作系统调度的最小单元，各线程拥有自己的计数器，堆栈，局部变量等，也可以访问线程间共享的内存。线程的状态有哪些？新创建，可运行，等待，超时等待，阻塞，终止怎么创建一个线程？-三种方法第一种，MyTr
android进阶之光！Android面试必备的集合源码详解，系列篇程序员Sunbu 程序员 Android
前言面试：如果不准备充分的面试，完全是浪费时间，更是对自己的不负责。文末会给大家分享下我整理的Android面试专题及答案其中大部分都是大企业面试常问的面试题，可以对照这查漏补缺，当然了，这里所列的肯定不可能覆盖全部方式，不过对大家找工作肯定是有帮助！本月飞机到达上海，到今天第6天了，四家大公司华为，小米，映客，抖音，还有二家中小型公司。有几家已经面了几轮，下周还要面，挂了几家，不过目前已经选择了
Android-悬浮窗功能的实现（附Java、KT实现源码）(1) egrhef 程序员 android java 开发语言
//获取服务的操作对象valbinder=serviceasFloatWinfowServices.MyBinderbinder.service}overridefunonServiceDisconnected(name:ComponentName){}}overridefunonActivityResult(requestCode:Int,resultCode:Int,data:Intent){
Visual Studio中的Android模拟器使用详解 wurui8 android android studio android android应用
关注微信号：javalearns随时随地学Java或扫一扫随时随地学JavaMicrosoft本周发布了VisualStudio2015预览版,里面包含Android开发工具.安装的时候,如果选Android开发,VisualStudio会把调试Android应用程序用的VisualStudio模拟器也装上.在介绍这个新模拟器之前,我们先来聊一聊,为什么需要一个新的Android模拟器–当然,你也
K8S学习笔记02——K8S组件沉淅尘 #Docker #K8S kubernetes
Kubernetes组件一、控制平面组件（ControlPlaneComponents）(1)kube-apiserver(2)etcd(3)kube-scheduler(4)kube-controller-manager(5)cloud-controller-manager二、Node组件1.kubelet2.kube-proxy3.容器运行时（ContainerRuntime）三、插件（Add
Unity 热更之【HybirdCLR】+【YooAsset】 [安卓 Android端] [代码 + 资源热更] 功能的简单实现演示仙魁XAN Unity 进阶 unity HybirdCLR YooAsset HotUpdate 热更新
Unity热更之【HybirdCLR】+【YooAsset】[安卓Android端][代码+资源热更]功能的简单实现演示目录Unity热更之【HybirdCLR】+【YooAsset】[安卓Android端][代码+资源热更]功能的简单实现演示一、简单介绍二、HybridCLR三、YooAsset四、HybirdCLR引入工程五、YooAsset引入工程六、Python服务器简单构建七、Hybir
Android 用线程池实现一个简单的任务队列(Kotlin) 深海呐 Android #Android进阶 #Kotlin android kotlin 线程池延时任务队列线程池延时任务
关于线程池,Kotlin和java的使用方式一样在Android中,很多人喜欢用Handler的postDelayed()去实现延时任务.要使用postDelayed(),去实现延时任务队列,就不可避免要使用递归.但是这样做,代码的简洁性,和书写的简易,就远不如使用线程池.使用线程池的简单程度:privatevalmThreadPool=Executors.newSingleThreadSched
（小白入门）Windows环境下搭建React Native Android开发环境码农老黑前端 React Native 移动开发 Android studio
ReactNative(简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的UI框架React在原生移动应用平台的衍生产物，目前支持iOS和Android两大平台。RN的环境搭建在RN的中文社区有所介绍，但是对于小白来说还是有些太过简略了。RN中文社区详见参考，本文不涉及的问题也许在其中能够有所解答。ReactNative思想底层引擎是JavaSc
html 周华华 html
js 1，数组的排列 var arr=[1,4,234,43,52,]; for(var x=0;x<arr.length;x++){ for(var y=x-1;y<arr.length;y++){ if(arr[x]<arr[y]){ &
【Struts2 四】Struts2拦截器 bit1129 struts2拦截器
Struts2框架是基于拦截器实现的，可以对某个Action进行拦截，然后某些逻辑处理，拦截器相当于AOP里面的环绕通知，即在Action方法的执行之前和之后根据需要添加相应的逻辑。事实上，即使struts.xml没有任何关于拦截器的配置，Struts2也会为我们添加一组默认的拦截器，最常见的是，请求参数自动绑定到Action对应的字段上。 Struts2中自定义拦截器的步骤是：
make:cc 命令未找到解决方法 daizj linux 命令未知 make cc
安装rz sz程序时，报下面错误： [root@slave2 src]# make posix cc -O -DPOSIX -DMD=2 rz.c -o rz make: cc：命令未找到 make: *** [posix] 错误 127 系统：centos 6.6 环境：虚拟机错误原因：系统未安装gcc，这个是由于在安
Oracle之Job应用周凡杨 oracle job
最近写服务，服务上线后，需要写一个定时执行的SQL脚本，清理并更新数据库表里的数据，应用到了Oracle 的 Job的相关知识。在此总结一下。一：查看相关job信息 1、相关视图 dba_jobs all_jobs user_jobs dba_jobs_running 包含正在运行
多线程机制朱辉辉33 多线程
转至http://blog.csdn.net/lj70024/archive/2010/04/06/5455790.aspx 程序、进程和线程：程序是一段静态的代码，它是应用程序执行的蓝本。进程是程序的一次动态执行过程，它对应了从代码加载、执行至执行完毕的一个完整过程，这个过程也是进程本身从产生、发展至消亡的过程。线程是比进程更小的单位，一个进程执行过程中可以产生多个线程，每个线程有自身的
web报表工具FineReport使用中遇到的常见报错及解决办法（一）老A不折腾 web报表 finereport java报表报表工具
FineReport使用中遇到的常见报错及解决办法（一）这里写点抛砖引玉，希望大家能把自己整理的问题及解决方法晾出来，Mark一下，利人利己。出现问题先搜一下文档上有没有，再看看度娘有没有，再看看论坛有没有。有报错要看日志。下面简单罗列下常见的问题，大多文档上都有提到的。 1、address pool is full：含义：地址池满，连接数超过并发数上
mysql rpm安装后没有my.cnf 林鹤霄没有my.cnf
Linux下用rpm包安装的MySQL是不会安装/etc/my.cnf文件的，至于为什么没有这个文件而MySQL却也能正常启动和作用，在这儿有两个说法，第一种说法，my.cnf只是MySQL启动时的一个参数文件，可以没有它，这时MySQL会用内置的默认参数启动，第二种说法，MySQL在启动时自动使用/usr/share/mysql目录下的my-medium.cnf文件，这种说法仅限于r
Kindle Fire HDX root并安装谷歌服务框架之后仍无法登陆谷歌账号的问题 aigo root
原文：http://kindlefireforkid.com/how-to-setup-a-google-account-on-amazon-fire-tablet/ Step 4: Run ADB command from your PC On the PC, you need install Amazon Fire ADB driver and instal
javascript 中var提升的典型实例 alxw4616 JavaScript
// 刚刚在书上看到的一个小问题,很有意思.大家一起思考下吧 myname = 'global'; var fn = function () { console.log(myname); // undefined var myname = 'local'; console.log(myname); // local }; fn() // 上述代码实际上等同于以下代码 m
定时器和获取时间的使用百合不是茶时间的转换定时器
定时器:定时创建任务在游戏设计的时候用的比较多 Timer();定时器 TImerTask();Timer的子类由 Timer 安排为一次执行或重复执行的任务。定时器类Timer在java.util包中。使用时，先实例化，然后使用实例的schedule(TimerTask task, long delay)方法，设定
JDK1.5 Queue bijian1013 java thread java多线程 Queue
JDK1.5 Queue LinkedList： LinkedList不是同步的。如果多个线程同时访问列表，而其中至少一个线程从结构上修改了该列表，则它必须保持外部同步。（结构修改指添加或删除一个或多个元素的任何操作；仅设置元素的值不是结构修改。）这一般通过对自然封装该列表的对象进行同步操作来完成。如果不存在这样的对象，则应该使用 Collections.synchronizedList 方
http认证原理和https bijian1013 http https
一.基础介绍在URL前加https://前缀表明是用SSL加密的。你的电脑与服务器之间收发的信息传输将更加安全。 Web服务器启用SSL需要获得一个服务器证书并将该证书与要使用SSL的服务器绑定。 http和https使用的是完全不同的连接方式，用的端口也不一样,前者是80，后
【Java范型五】范型继承 bit1129 java
定义如下一个抽象的范型类，其中定义了两个范型参数，T1，T2 package com.tom.lang.generics; public abstract class SuperGenerics<T1, T2> { private T1 t1; private T2 t2; public abstract void doIt(T
【Nginx六】nginx.conf常用指令(Directive) bit1129 Directive
1. worker_processes 8; 表示Nginx将启动8个工作者进程，通过ps -ef|grep nginx,会发现有8个Nginx Worker Process在运行 nobody 53879 118449 0 Apr22 ? 00:26:15 nginx: worker process
lua 遍历Header头部 ronin47 lua header 遍历　
local headers = ngx.req.get_headers() ngx.say("headers begin", "<br/>") ngx.say("Host : ", he
java-32.通过交换a,b中的元素，使[序列a元素的和]与[序列b元素的和]之间的差最小(两数组的差最小)。 bylijinnan java
import java.util.Arrays; public class MinSumASumB { /** * Q32.有两个序列a,b，大小都为n,序列元素的值任意整数，无序. * * 要求：通过交换a,b中的元素，使[序列a元素的和]与[序列b元素的和]之间的差最小。 * 例如: * int[] a = {100,99,98,1,2,3
redis 开窍的石头 redis
在redis的redis.conf配置文件中找到# requirepass foobared 把它替换成requirepass 12356789 后边的12356789就是你的密码打开redis客户端输入config get requirepass 返回 redis 127.0.0.1:6379> config get requirepass 1) "require
[JAVA图像与图形]现有的GPU架构支持JAVA语言吗？ comsci java语言
无论是opengl还是cuda，都是建立在C语言体系架构基础上的，在未来，图像图形处理业务快速发展，相关领域市场不断扩大的情况下，我们JAVA语言系统怎么从这么庞大，且还在不断扩大的市场上分到一块蛋糕，是值得每个JAVAER认真思考和行动的事情
安装ubuntu14.04登录后花屏了怎么办 cuiyadll ubuntu
这个情况，一般属于显卡驱动问题。可以先尝试安装显卡的官方闭源驱动。按键盘三个键：CTRL + ALT + F1 进入终端，输入用户名和密码登录终端：安装amd的显卡驱动 sudo apt-get install fglrx 安装nvidia显卡驱动 sudo ap
SSL 与数字证书的基本概念和工作原理 darrenzhu 加密 ssl 证书密钥签名
SSL 与数字证书的基本概念和工作原理 http://www.linuxde.net/2012/03/8301.html SSL握手协议的目的是或最终结果是让客户端和服务器拥有一个共同的密钥，握手协议本身是基于非对称加密机制的，之后就使用共同的密钥基于对称加密机制进行信息交换。 http://www.ibm.com/developerworks/cn/webspher
Ubuntu设置ip的步骤 dcj3sjt126com ubuntu
在单位的一台机器完全装了Ubuntu Server，但回家只能在XP上VM一个，装的时候网卡是DHCP的，用ifconfig查了一下ip是192.168.92.128,可以ping通。转载不是错： Ubuntu命令行修改网络配置方法 /etc/network/interfaces打开后里面可设置DHCP或手动设置静态ip。前面auto eth0，让网卡开机自动挂载. 1. 以D
php包管理工具推荐 dcj3sjt126com PHP Composer
http://www.phpcomposer.com/ Composer是 PHP 用来管理依赖（dependency）关系的工具。你可以在自己的项目中声明所依赖的外部工具库（libraries），Composer 会帮你安装这些依赖的库文件。中文文档入门指南下载安装包列表 Composer 中国镜像
Gson使用四（TypeAdapter） eksliang json gson Gson自定义转换器 gsonTypeAdapter
转载请出自出处：http://eksliang.iteye.com/blog/2175595 一.概述 Gson的TypeAapter可以理解成自定义序列化和返序列化二、应用场景举例例如我们通常去注册时（那些外国网站），会让我们输入firstName，lastName,但是转到我们都
JQM控件之Navbar和Tabs gundumw100 html xml css
在JQM中使用导航栏Navbar是简单的。只需要将data-role="navbar"赋给div即可： <div data-role="navbar"> <ul> <li><a href="#" class="ui-btn-active&qu
利用归并排序算法对大文件进行排序 iwindyforest java 归并排序大文件分治法 Merge sort
归并排序算法介绍，请参照Wikipeida zh.wikipedia.org/wiki/%E5%BD%92%E5%B9%B6%E6%8E%92%E5%BA%8F 基本思想：大文件分割成行数相等的两个子文件，递归（归并排序）两个子文件，直到递归到分割成的子文件低于限制行数低于限制行数的子文件直接排序两个排序好的子文件归并到父文件直到最后所有排序好的父文件归并到输入
iOS UIWebView URL拦截啸笑天 UIWebView
本文译者：candeladiao，原文：URL filtering for UIWebView on the iPhone说明：译者在做app开发时，因为页面的javascript文件比较大导致加载速度很慢，所以想把javascript文件打包在app里，当UIWebView需要加载该脚本时就从app本地读取，但UIWebView并不支持加载本地资源。最后从下文中找到了解决方法，第一次翻译，难免有
索引的碎片整理SQL语句 macroli sql
SET NOCOUNT ON DECLARE @tablename VARCHAR (128) DECLARE @execstr VARCHAR (255) DECLARE @objectid INT DECLARE @indexid INT DECLARE @frag DECIMAL DECLARE @maxfrag DECIMAL --设置最大允许的碎片数量,超过则对索引进行碎片
Angularjs同步操作http请求with $promise qiaolevip 每天进步一点点学习永无止境 AngularJS 纵观千象
// Define a factory app.factory('profilePromise', ['$q', 'AccountService', function($q, AccountService) { var deferred = $q.defer(); AccountService.getProfile().then(function(res) {
hibernate联合查询问题 sxj19881213 sql Hibernate HQL 联合查询
最近在用hibernate做项目，遇到了联合查询的问题，以及联合查询中的N+1问题。针对无外键关联的联合查询，我做了HQL和SQL的实验，希望能帮助到大家。（我使用的版本是hibernate3.3.2） 1 几个常识：（1）hql中的几种join查询，只有在外键关联、并且作了相应配置时才能使用。（2）hql的默认查询策略，在进行联合查询时，会产
struts2.xml wuai struts
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.3//EN" "http://struts.apache