要提升网页滑屏的性能，一个简单的做法就是让 WebView 本身持有一块独立的缓存，而 WebView 的绘制就分成了两步 1) 根据需要更新内部缓存，将网页内容绘制到内部缓存里面 2) 将内部缓存拷贝到窗口缓存上。第一步我们通常称为绘制（Paint）或者光栅化（Rasterization），它将一些绘图指令转换成真正的像素颜色值，而第二步我们一般称为混合（Composite），它负责缓存的拷贝，同时还可能包括位移（Translation），缩放（Scale），旋转（Rotation），Alpha 混合等操作。咋一看，渲染变得比原来更复杂，还多了一步操作，但实际上，混合的耗时通常远远小于网页内容绘制的耗时，后者即使在移动设备上一般也就在几个毫秒以内，而大部分时候，在第一步里面，我们只需要绘制一块很小的区域而不需要绘制一个完整 WebView 大小的区域，这样就有效地减少了绘制这一步的开销。以网页滚动为例子，每次滚动实际上只需要绘制新进入 WebView 可见区域的部分，如果向上滚动了10个像素，我们需要绘制的区域大小就是10 x Width of WebView，比起原来需要绘制整个 WebView 大小区域的网页内容当然要快的多了。

进一步来说，浏览器还可以使用多线程的渲染架构，将网页内容绘制到缓存的操作放到另外一个独立的线程（绘制线程），而原来线程对 WebView 的绘制就只剩下缓存的拷贝（混合线程），绘制线程跟混合线程之间可以使用同步，部分同步，完全异步等作业模式，让浏览器可以在性能与效果之间根据需要进行选择，比如说异步模式下，当浏览器需要将 WebView 缓存拷贝到窗口缓存，但是需要更新的部分还没有来得及绘制时，浏览器可以在还未及时更新的部分绘制一个背景色或者空白，这样虽然渲染效果有所下降，但是保证了每一帧窗口更新的间隔都在理想的范围内。并且浏览器还可以为 WebView 创建一个更大的缓存，超过 WebView本身的大小，让我们可以缓存更多的网页内容，可以预先绘制不可见的区域，这样就可以有效减少异步模式下出现空白的状况，在性能和效果之间取得更好的平衡。

上述的渲染模式，无论是绘制还是混合，都是由 CPU 完成的，而没有使用到 GPU。绘制任务比较复杂，较难使用 GPU 来完成，并且对于各种复杂的图形/文本的绘制来说，使用 GPU 效率有时反而更低（并且系统资源的开销也较大），但是混合就不一样了，GPU 最擅长的就是并行处理多个像素的计算，所以 GPU 相对于 CPU，执行混合的速度要快的多，特别是存在缩放，旋转，Alpha 混合的时候，而且混合相对来说也比较简单，改成使用 GPU 来完成并不困难。

并且在多线程渲染模式下，因为绘制和混合分别处于不同的线程，绘制使用 CPU，混合使用 GPU，这样可以通过 CPU/GPU 之间的并发运行有效地提升浏览器整体的渲染性能。更何况，窗口的更新是由混合线程来负责的，混合的效率越高，窗口更新的间隔就越短，用户感受到 UI 界面变化的流畅度就越高，只要窗口更新的间隔能够始终保持在16.7毫秒以内，UI 界面就能够一直保持60帧/每秒的极致流畅度（因为一般来说，显示屏幕的刷新频率是60hz，所以60帧/秒已经是极限帧率，超过这个数值意义不大，而且 OS 的图形子系统本身就会强制限制 UI 界面的更新跟屏幕的刷新保持同步）。

所以对于现代浏览器来说，所谓硬件加速，就是使用 GPU 来进行混合，绘制仍然使用 CPU 来完成。

图片来自 [UC 浏览器 9.7 Android版]，使用256×256大小的分块

网页的缓存通常都不是一大块，而是划分成一格一格的小块，通常为256×256或者512×512大小，这种渲染方式称为分块渲染（Tile Rendering）。使用分块渲染的主要原因是因为 –

总之固定大小的小块缓存，通过一个统一缓存池来管理的方式，比起每个 WebView 自己持有一大块缓存有很多优势。特别是更适合多线程 CPU/GPU 并发的渲染模型，所以基本上支持硬件加速的浏览器都会使用分块渲染的方式。

图片来自 [UC 浏览器 9.7 Android版]，可见区域内有4个 Layer 有自己的缓存 – 最底层的 Base Layer，上方的 Fixed 标题栏，中间的热点新闻栏，右下方的 Fixed 跳转按钮

图层混合加速（Accelerated Compositing）的渲染架构是 Apple 引入 WebKit 的，并在 Safari 上率先实现，而 Chrome/Android/Qt/GTK+ 等都陆续完成了自己的实现。如果熟悉 iOS 或者 Mac OS GUI 编程的读者对其应该不会感到陌生，它跟 iOS CoreAnimation 的 Layer Rendering 渲染架构基本类似，主要都是为了解决当 Layer 的内容频繁发生变化，或者当 Layer 触发一个2D/3D变换（2D/3D Transform ）或者渐隐渐入动画，它的位移，缩放，旋转，透明度等属性不断发生变化时，在原有的渲染架构下，渲染性能低下的问题。

非混合加速的渲染架构，所有的 RenderLayer 都没有自己独立的缓存，它们都被绘制到同一个缓存里面（按照它们的先后顺序），所以只要这个 Layer 的内容发生变化，或者它的一些 CSS 样式属性比如 Transform/Opacity 发生变化，变化区域的缓存就需要重新生成，此时不但需要绘制变化的 Layer，跟变化区域（Damage Region）相交的其它 Layer 都需要被绘制，而前面已经说过，网页的绘制是十分耗时的。如果 Layer 偶尔发生变化，那还不要紧，但如果是一个 JavaScript 或者 CSS 动画在不断地驱使 Layer 发生变化，这个动画要达到60帧/每秒的流畅效果就基本不可能了。