Chromium网页Layer Tree创建过程分析

Posted 2020-06-30 罗升阳

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Chromium网页Layer Tree创建过程分析相关的知识，希望对你有一定的参考价值。

在Chromium中，WebKit会创建一个Graphics Layer Tree描述网页。Graphics Layer Tree是和网页渲染相关的一个Tree。网页渲染最终由Chromium的CC模块完成，因此CC模块又会根据Graphics Layer Tree创建一个Layer Tree，以后就会根据这个Layer Tree对网页进行渲染。本文接下来就分析网页Layer Tree的创建过程。

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

《android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

从前面Chromium网页Graphics Layer Tree创建过程分析一文可以知道，网页的Graphics Layer Tree是根据Render Layer Tree创建的，Render Layer Tree又是根据Render Object Tree创建的。Graphics Layer Tree与Render Layer Tree、Render Layer Tree与Render Object Tree的节点是均是一对多的关系，然而Graphics Layer Tree与CC模块创建的Layer Tree的节点是一一对应的关系，如图1所示：

图1 Graphics Layer Tree与CC Layer Tree的关系

也就是说，每一个Graphics Layer都对应有一个CC Layer。不过，Graphics Layer与CC Layer不是直接的一一对应的，它们是透过另外两个Layer才对应起来的，如图2所示：

图2 Graphics Layer与CC Layer的对应关系

中间的两个Layer分别是WebContentLayerImpl和WebLayerImpl，它们是属于Content层的对象。关于Chromium的层次划分，可以参考前面Chromium网页加载过程简要介绍和学习计划一文的介绍。Graphics Layer与CC Layer的对应关系，是在Graphics Layer的创建过程中建立起来的，接下来我们就通过源码分析这种对应关系的建立过程。

从前面Chromium网页Graphics Layer Tree创建过程分析一文可以知道，Graphics Layer是通过调用GraphicsLayerFactoryChromium类的成员函数createGraphicsLayer创建的，如下所示：

PassOwnPtr<GraphicsLayer> GraphicsLayerFactoryChromium::createGraphicsLayer(GraphicsLayerClient* client)  
{  
    OwnPtr<GraphicsLayer> layer = adoptPtr(new GraphicsLayer(client));  
    ......  
    return layer.release();  
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/GraphicsLayerFactoryChromium.cpp中。

参数client指向的实际上是一个CompositedLayerMapping对象，这个CompositedLayerMapping对象会用来构造一个Graphics Layer。Graphics Layer的构造过程，也就是GraphicsLayer类的构造函数的实现，如下所示：

GraphicsLayer::GraphicsLayer(GraphicsLayerClient* client)
    : m_client(client)
    , ...... 
{
    ......

    m_opaqueRectTrackingContentLayerDelegate = adoptPtr(new OpaqueRectTrackingContentLayerDelegate(this));
    m_layer = adoptPtr(Platform::current()->compositorSupport()->createContentLayer(m_opaqueRectTrackingContentLayerDelegate.get()));
    
    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp中。

GraphicsLayer类的构造函数首先是将参数client指向的CompositedLayerMapping对象保存在成员变量m_client中，接着又创建了一个OpaqueRectTrackingContentLayerDelegate对象保存在成员变量opaqueRectTrackingContentLayerDelegate中。

再接下来GraphicsLayer类的构造函数通过Platform类的静态成员函数current获得一个RendererWebKitPlatformSupportImpl对象。这个RendererWebKitPlatformSupportImpl对象定义在Content模块中，它实现了由WebKit定义的Platform接口，用来向WebKit层提供平台相关的实现。

通过调用RendererWebKitPlatformSupportImpl类的成员函数compositorSupport可以获得一个WebCompositorSupportImpl对象。有了这个WebCompositorSupportImpl对象之后，就可以调用它的成员函数createContentLayer创建一个WebContentLayerImpl对象，并且保存在GraphicsLayer类的成员变量m_layer中。

WebCompositorSupportImpl类的成员函数createContentLayer的实现如下所示：

WebContentLayer* WebCompositorSupportImpl::createContentLayer(
    WebContentLayerClient* client) {
  return new WebContentLayerImpl(client);
}

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

从这里可以看到，WebCompositorSupportImpl类的成员函数createContentLayer创建了一个WebContentLayerImpl对象返回给调用者。

WebContentLayerImpl对象的创建过程，即WebContentLayerImpl类的构造函数的实现，如下所示：

WebContentLayerImpl::WebContentLayerImpl(blink::WebContentLayerClient* client)
    : client_(client), ...... {
  if (WebLayerImpl::UsingPictureLayer())
    layer_ = make_scoped_ptr(new WebLayerImpl(PictureLayer::Create(this)));
  else
    layer_ = make_scoped_ptr(new WebLayerImpl(ContentLayer::Create(this)));
  ......
}

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

从前面的调用过程可以知道，参数client指向的实际上是一个OpaqueRectTrackingContentLayerDelegate对象，WebContentLayerImpl类的构造函数首先将它保存在成员变量client_中。

WebContentLayerImpl类的构造函数接下来调用WebLayerImpl类的静态成员函数UsingPictureLayer判断Render进程是否启用Impl Side Painting特性。如果启用的话，就会调用PictureLayer类的静态成员函数Create创建一个Picture Layer；否则的话，就会调用ContentLayer类的静态成员函数Create创建一个Content Layer。有了Picture Layer或者Content Layer之后，再创建一个WebLayerImpl对象，保存在WebContentLayerImpl类的成员变量layer_中。

当Render进程设置了enable-impl-side-painting启动选项时，就会启用Impl Side Painting特性，也就是会在Render进程中创建一个Compositor线程，与Render进程中的Main线程一起协作完成网页的渲染。在这种情况下，Graphics Layer在绘制网页内容的时候，实际上只是记录了绘制命令。这些绘制命令就记录在对应的Picture Layer中。

另一方面，如果Render进程没有设置enable-impl-side-painting启动选项，那么Graphics Layer在绘制网页内容的时候，就会通过Content Layer提供的一个Canvas真正地把网页内容对应的UI绘制在一个内存缓冲区中。

无论是Picture Layer还是Content Layer，它们都是在cc::Layer类继承下来的，也就是说，它们对应于图2所示的CC Layer。不过，我们只考虑Picture Layer的情况，因此接下来我们继续分析Picture Layer的创建过程，也就是PictureLayer类的静态成员函数Create的实现，如下所示：

scoped_refptr<PictureLayer> PictureLayer::Create(ContentLayerClient* client) {
  return make_scoped_refptr(new PictureLayer(client));
}

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

从这里可以看到，PictureLayer类的静态成员函数Create创建了一个PictureLayer对象返回给调用者。

PictureLayer对象的创建过程，也就是PictureLayer类的构造函数的实现，如下所示：

PictureLayer::PictureLayer(ContentLayerClient* client)
    : client_(client),
      pile_(make_scoped_refptr(new PicturePile())),
      ...... {
}

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

从前面的调用过程可以知道，参数client指向的实际上是一个WebContentLayerImpl对象，PictureLayer类的构造函数将它保存在成员变量client_中。

PictureLayer类的构造函数还做了另外一件重要的事情，就是创建了一个PicturePile对象，并且保存在成员变量pile_中。这个PicturePile对象是用来将Graphics Layer的绘制命令记录在Pictrue Layer中的，后面我们分析网页内容的绘制过程时就会看到这一点。

回到WebContentLayerImpl类的构造函数中，它创建了一个Pictrue Layer之后，接下来就会以这个Pictrue Layer为参数，创建一个WebLayerImpl对象，如下所示：

WebLayerImpl::WebLayerImpl(scoped_refptr<Layer> layer) : layer_(layer) {
  ......
}

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

WebLayerImpl类的构造函数主要就是将参数layer描述的一个PictrueLayer对象保存在成员变量layer_中。

从前面Chromium网页Graphics Layer Tree创建过程分析一文还可以知道，Graphics Layer与Graphics Layer是通过GraphicsLayer类的成员函数addChild形成父子关系的（从而形成Graphics Layer Tree），如下所示：

void GraphicsLayer::addChild(GraphicsLayer* childLayer)
{
    addChildInternal(childLayer);
    updateChildList();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp中。

GraphicsLayer类的成员函数addChild首先调用成员函数addChildInternal将参数childLayer描述的一个Graphics Layer作为当前正在处理的Graphics Layer的子Graphics Layer，如下所示：

void GraphicsLayer::addChildInternal(GraphicsLayer* childLayer)
{
    ......

    childLayer->setParent(this);
    m_children.append(childLayer);

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp中。

这一步执行完成后，Graphics Layer之间就建立了父子关系。回到GraphicsLayer类的成员函数addChild中，它接下来还会调用另外一个成员函数updateChildList，用来在CC Layer之间建立父子关系，从而形CC Layer Tree。

GraphicsLayer类的成员函数updateChildList的实现如下所示：

void GraphicsLayer::updateChildList()
{
    WebLayer* childHost = m_layer->layer();
    ......

    for (size_t i = 0; i < m_children.size(); ++i)
        childHost->addChild(m_children[i]->platformLayer());

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp中。

从前面的分析可以知道，GraphicsLayer类的成员变量m_layer指向的是一个WebContentLayerImpl对象，调用这个WebContentLayerImpl对象的成员函数layer获得的是一个WebLayerImpl对象，如下所示：

blink::WebLayer* WebContentLayerImpl::layer() {
  return layer_.get();
}

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

从前面的分析可以知道，WebContentLayerImpl类的成员变量layer_指向的是一个WebLayerImpl对象，因此WebContentLayerImpl类的成员函数layer返回的是一个WebLayerImpl对象。

回到GraphicsLayer类的成员函数updateChildList中，它接下来调用GraphicsLayer类的成员函数platformLayer获得当前正在处理的Graphics Layer的所有子Graphics Layer对应的WebLayerImpl对象，如下所示：

WebLayer* GraphicsLayer::platformLayer() const
{
    return m_layer->layer();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp中。

这些子Graphics Layer对应的WebLayerImpl对象也就是通过调用它们的成员变量m_layer指向的WebContentLayerImpl对象的成员函数layer获得的。

再回到GraphicsLayer类的成员函数updateChildList中，获得当前正在处理的Graphics Layer对应的WebLayerImpl对象，以及其所有的子Graphics Layer对应的WebLayerImpl对象之后，就可以通过调用WebLayerImpl类的成员函数addChild在它们之间也建立父子关系，如下所示：

void WebLayerImpl::addChild(WebLayer* child) {
  layer_->AddChild(static_cast<WebLayerImpl*>(child)->layer());
}

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

从前面的分析可以知道，WebLayerImpl类的成员变量layer_指向的是一个PictrueLayer对象，因此WebLayerImpl类的成员函数addChild所做的事情就是在两个PictrueLayer对象之间建立父子关系，这是通过调用PictrueLayer类的成员函数AddChild实现的。

PictrueLayer类的成员函数AddChild是父类Layer继承下来的，它的实现如下所示：

void Layer::AddChild(scoped_refptr<Layer> child) {
  InsertChild(child, children_.size());
}

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

Layer类的成员函数AddChild将参数child描述的Pictrue Layer设置为当前正在处理的Picture Layer的子Picture Layer，这是通过调用Layer类的成员函数InsertChild实现的，如下所示：

void Layer::InsertChild(scoped_refptr<Layer> child, size_t index) {
  DCHECK(IsPropertyChangeAllowed());
  child->RemoveFromParent();
  child->SetParent(this);
  child->stacking_order_changed_ = true;

  index = std::min(index, children_.size());
  children_.insert(children_.begin() + index, child);
  SetNeedsFullTreeSync();
}

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

Layer类的成员函数InsertChild所做的第一件事情是将当前正在处理的Picture Layer设置为参数child描述的Pictrue Layer的父Picture Layer，并且将参数child描述的Pictrue Layer保存在当前正在处理的Picture Layer的子Picture Layer列表中。

Layer类的成员函数InsertChild所做的第二件事情是调用另外一个成员函数SetNeedsFullTreeSync发出一个通知，要在CC Layer Tree与CC Pending Layer Tree之间做一个Tree结构同步。

Layer类的成员函数SetNeedsFullTreeSync的实现如下所示：

void Layer::SetNeedsFullTreeSync() {
  if (!layer_tree_host_)
    return;

  layer_tree_host_->SetNeedsFullTreeSync();
}

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

Layer类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象，这个LayerTreeHost是用来管理CC Layer Tree的，后面我们再分析它的创建过程。Layer类的成员函数SetNeedsFullTreeSync所做的事情就是调用这个LayerTreeHost对象的成员函数SetNeedsFullTreeSync通知它CC Layer Tree结构发生了变化，需要将这个变化同步到CC Pending Layer Tree中去。

LayerTreeHost类的成员函数SetNeedsFullTreeSync的实现如下所示：

void LayerTreeHost::SetNeedsFullTreeSync() {
  needs_full_tree_sync_ = true;
  SetNeedsCommit();
}

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

LayerTreeHost类的成员函数SetNeedsFullTreeSync将成员变量needs_full_tree_sync_设置为true，以标记要在CC Layer Tree和CC Pending Layer Tree之间做一次结构同步，然后再调用另外一个成员函数SetNeedsCommit请求在前面Chromium网页渲染机制简要介绍和学习计划一文中提到的调度器将CC Layer Tree同步到CC Pending Tree去。至于这个同步操作什么时候会执行，就是由调度器根据其内部的状态机决定了。这一点我们在后面的文章再分析。

这一步执行完成之后，就可以在CC模块中得到一个Layer Tree，这个Layer Tree与WebKit中的Graphics Layer Tree在结构上是完全同步的，并且这个同步过程是由WebKit控制的。这个同步过程之所以要由WebKit控制，是因为CC Layer Tree是根据Graphics Layer Tree创建的，而Graphics Layer Tree又是由WebKit管理的。

WebKit现在还需要做的另外一件重要的事情是告诉CC模块，哪一个Picture Layer是CC Layer Tree的根节点，这样CC模块才可以对整个CC Layer Tree进行管理。很显然，Graphics Layer Tree的根节点对应的Picture Layer，就是CC Layer Tree的根节点。因此，WebKit会在创建Graphics Layer Tree的根节点的时候，将该根节点对应的Picture Layer设置到CC模块中去，以便后者将其作为CC Layer Tree的根节点。

Graphics Layer Tree的根节点是什么时候创建的呢？从前面Chromium网页加载过程简要介绍和学习计划这个系列的文章可以知道，Graphics Layer Tree的根节点对应于Render Layer Tree的根节点，Render Layer Tree的根节点又对应于Render Object Tree的根节点，因此我们就从Render Object Tree的根节点的创建过程开始，分析Graphics Layer Tree的根节点的创建过程。

从前面Chromium网页DOM Tree创建过程分析一文可以知道，Render Object Tree的根节点是在Document类的成员函数attach中创建的，如下所示：

void Document::attach(const AttachContext& context)
{
    ......

    m_renderView = new RenderView(this);
    ......

    m_renderView->setStyle(StyleResolver::styleForDocument(*this));

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/dom/Document.cpp中。

Document类的成员函数attach首先创建了一个RenderView对象，保存在成员变量m_renderView中。这个RenderView对象就是Render Object Tree的根节点。Document类的成员函数attach接下来还会调用RenderView类的成员函数setStyle给前面创建的RenderView对象设置CSS属性。

从前面Chromium网页Render Layer Tree创建过程分析一文可以知道，在给Render Object Tree的节点设置CSS属性的过程中，会创建相应的Render Layer。这一步发生在RenderLayerModelObject类的成员函数styleDidChange中，如下所示：

void RenderLayerModelObject::styleDidChange(StyleDifference diff, const RenderStyle* oldStyle)  
{  
    ......  
  
    LayerType type = layerTypeRequired();  
    if (type != NoLayer) {  
        if (!layer() && layerCreationAllowedForSubtree()) {  
            ......  
  
            createLayer(type);  
            
            ......  
        }  
    } else if (layer() && layer()->parent()) {  
        ......  
  
        layer()->removeOnlyThisLayer(); // calls destroyLayer() which clears m_layer  
  
        ......  
    }  
  
    if (layer()) {  
        ......  
  
        layer()->styleChanged(diff, oldStyle);  
    }  
  
    ......  
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/RenderLayerModelObject.cpp中。

RenderLayerModelObject类的成员函数styleDidChange的详细分析可以参考Chromium网页Render Layer Tree创建过程分析一文。其中，Render Layer的创建是通过调用RenderLayerModelObject类的成员函数createLayer实现的，并且创建出来的Render Layer的成员函数styleChanged会被调用，用来设置它的CSS属性。

在设置Render Layer Tree的根节点的CSS属性的过程中，会触发Graphics Layer Tree的根节点的创建，因此接下来我们继续分析RenderLayer类的成员函数styleChanged的实现，如下所示：

void RenderLayer::styleChanged(StyleDifference diff, const RenderStyle* oldStyle)
{
    ......

    m_stackingNode->updateStackingNodesAfterStyleChange(oldStyle);

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/RenderLayer.cpp中。

RenderLayer类的成员变量m_stackingNode指向的是一个RenderLayerStackingNode对象。这个RenderLayerStackingNode对象描述的是一个Stacking Context。关于Stacking Context，可以参考前面Chromium网页Graphics Layer Tree创建过程分析一文。RenderLayer类的成员函数styleChanged调用上述RenderLayerStackingNode对象的成员函数updateStackingNodesAfterStyleChange通知它所关联的Render Layer的CSS属性发生了变化，这样它可能就需要更新自己的子元素。

RenderLayerStackingNode类的成员函数updateStackingNodesAfterStyleChange的实现如下所示：

void RenderLayerStackingNode::updateStackingNodesAfterStyleChange(const RenderStyle* oldStyle)
{
    bool wasStackingContext = oldStyle ? !oldStyle->hasAutoZIndex() : false;
    int oldZIndex = oldStyle ? oldStyle->zIndex() : 0;

    bool isStackingContext = this->isStackingContext();
    if (isStackingContext == wasStackingContext && oldZIndex == zIndex())
        return;

    dirtyStackingContextZOrderLists();

    if (isStackingContext)
        dirtyZOrderLists();
    else
        clearZOrderLists();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/RenderLayerStackingNode.cpp中。

RenderLayerStackingNode类的成员函数updateStackingNodesAfterStyleChange判断当前正在处理的RenderLayerStackingNode对象关联的Render Layer的CSS属性变化，是否导致它从一个Stacking Context变为一个非Stacking Context，或者从一个非Stacking Context变为一个Stacking Context。

在从非Stacking Context变为Stacking Context的情况下，RenderLayerStackingNode类的成员函数updateStackingNodesAfterStyleChange就会调用另外一个成员函数dirtyZOrderLists将Stacking Context标记为Dirty状态，这样以后在需要的时候就会根据该Stacking Context的子元素的z-index重新构建Graphics Layer Tree。

RenderLayerStackingNode类的成员函数dirtyZOrderLists的实现如下所示：

void RenderLayerStackingNode::dirtyZOrderLists()
{
    ......

    if (m_posZOrderList)
        m_posZOrderList->clear();
    if (m_negZOrderList)
        m_negZOrderList->clear();
    m_zOrderListsDirty = true;

    if (!renderer()->documentBeingDestroyed())
        compositor()->setNeedsCompositingUpdate(CompositingUpdateRebuildTree);
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/RenderLayerStackingNode.cpp中。

RenderLayerStackingNode类的成员函数dirtyZOrderLists首先是将用来保存子元素的两个列表清空。其中一个列表用来保存z-index为正数的子元素，另一个列表用来保存z-index为负数的子元素。这些子元素在各自的列表中均是按照从小到大的顺序排列的。有了这个顺序之后，Graphics Layer Tree就可以方便地按照z-index顺序创建出来。

RenderLayerStackingNode类的成员函数dirtyZOrderLists接下来将成员变量m_zOrderListsDirty的值设置为true，就将自己的状态标记为Dirty，以后就会重新根据子元素的z-index值，将它们分别保存在对应的列表中。

RenderLayerStackingNode类的成员函数dirtyZOrderLists最后判断当前加载的网页有没有被销毁。如果没有被销毁，就会调用另外一个成员函数compositor，获得一个RenderLayerCompositor对象。这个RenderLayerCompositor对象是用来管理当前加载的网页的Graphics Layer Tree的。有了这个RenderLayerCompositor对象之后，就可以调用它的成员函数setNeedsCompositingUpdate，用来通知它需要重建Graphics Layer Tree。

RenderLayerCompositor类的成员函数setNeedsCompositingUpdate的实现如下所示：

void RenderLayerCompositor::setNeedsCompositingUpdate(CompositingUpdateType updateType)
{
    ......
    if (!m_renderView.needsLayout())
        enableCompositingModeIfNeeded();

    m_pendingUpdateType = std::max(m_pendingUpdateType, updateType);
    ......
}