Chromimum Android渲染介绍

从概念上一个使用硬件加速(AC)时，页面显示的结构是Viewport -> Layer(s) -> Tile(s)，所谓的纹理就是Tile上显示的内容。分块最大的好处就是重绘的单元变小，更利于降低系统开销。

(Tile翻成瓦片，还不如瓷砖呢 ^_^!)

从WebKit内核到Chromium的cc模块，其对应关系如下:

Chormium通过impl-side painting实现了多线程的渲染(Design Document)。其目的是将WebKit内核的页面内容绘制与实际显示隔离开来，再将painting操作分为recording和rasterization。

其中一个重要的概念是Main Thread(side)和Impl Thread(side)。

Main Thread运行于Render线程，包括RenderWidget，LayerTreeHost等。Impl Thread运行于Compositor线程，包括LayerTreeHostImpl等。两者通过一个Proxy进行线程的通讯。基本的渲染路径就像是dot绘图一样，先录制脚本，再生成图像。它使用的对象是SkPicture, 它能做到类似Display List的功能，能够记录，再播放。这也是跨进程渲染的基础（必然需要一个编码及解码的过程。）。

步骤如下:

* 在Main Thread里，Chromium/WebKit的渲染到一个图形后端(SkPicture)存储起来, 由LayerTreeHost管理整个Layer Tree。这个过程叫Record，并没有真正绘制。

* 将这些数据提交到Impl Thread里的LayerTreeHostImpl进行给制，这个过程是Upload,还有一个Commit。

* LayerTreeHostImpl再通过AwContents，使用Android的GL功能进行合成绘制，这个过程叫Rastering (光栅化，其实就是用位图显示的概念,对应于矢量方式绘图.)。

结构上，LayerTreeHost与LayerTreeHostImpl构成了Main Thread和Impl Thread的交互界面。

初始化时，流程从RenderViewImpl的创建开始，如下图所示(ThreadProxy是Proxy的实现):

为了更好地安排Main Thread与Impl Thread的任务队列，还会有一个Scheduler负责任务安排。以下是类的关系，可以看到它们的生命周期管理:

Main Thread(Side)

LayerTreeHost/LayerTreeHostImpl只是组织和事务处理的类，实际绘制时是以OutputSurface为基础的，可以理解为图形后端。Android WebView和CC都是基于对OutputSurface的操作来完成后面的合成的。Chromium WebView使用同步合成器，即SynchronousCompositor，在UI线程上使用系统的GL能力绘制。后面有一串以SynchronousCompositor命名的类。

首先当LayerTreeHostImpl准备好后，会向LayerTreeHost请求OutputSurface, 最终由RenderWidget通过SynchronousCompositorFactory创建出一个OutputSurface,并交给LayerTreeHostImpl管理(scoped_ptr)。