Chromium on Android: 分析Chromium WebView的软件渲染方式

摘要

渲染过程可以形象地理解为用一支笔将特定的内容在一张纸上画出来，然后呈现在屏幕上，而对笔和纸张的选择决定了渲染的方式。在Chromium on Android: 认识Chromium WebView一文中我们提到，新版的WebView同时支持两种渲染模式，即软件渲染和硬件渲染。简单的说，软件渲染方式就是用“CPU”这支“笔”将页面内容绘制到以位图Bitmap为材质的“纸张”上，而硬件渲染方式则是用GPU这支笔（当然也需要借助CPU）将页面内容绘制到以Texture为材质的“纸张”上。本文将深入分析新版WebView的软件渲染过程，后续将对硬件渲染做进一步讨论。

为什么支持软件渲染

从Android 3.0（API Level 11）开始, 2D渲染过程就全面支持硬件加速了，也就是说所有在View的Canvas上执行的绘制操作都是使用GPU了。同时，Android平台为在不同的层次为应用程序提供了配置接口或API接口，用来指定程序是否启用硬件加速。比如，你可以在manifest文件中显式设置android:hardwareAccelerated值

<applicationandroid:hardwareAccelerated="true" ...>

表示整个应用程序都将启用硬件加速，也可以为某个Activity或者View设置hardwareAccelerated属性。关于设定硬件加速的方式，详细信息请参考[1]。

那么，既然有了系统级别的硬件加速支持，新版WebView为什么还要支持软件渲染方式呢？原因有二：

WebView是Android系统的内置组件，对组件的升级必须保证对应用程序的兼容性。换句话说，那些使用了WebView但没有启用硬件加速的应用程序也能够在Android 4.4上正常工作。这是最主要的原因。
硬件加速方式虽然看上去“高端大气上档次“，但相应地应用程序会耗费更多的系统内存，例如需要加载OpenGL的动态库，会占用一定的内容空间（~8M？）。因此，软件渲染方式提供了另一种备选方案，应用程序可以根据Android设备配置选择是否启用硬件加速，确保正常的运行。

WebView的软件渲染过程

WebView的渲染是个较为复杂的过程，但只要将其中的关键步骤抽取出来，提纲挈领，再复杂的过程也可以一目了然，跃然纸上。如下这幅框架图尝试简化WebView渲染过程，只描述关键模块和步骤，接下来会逐一解读。

关键的6大步骤

页面内容的更新导致包含WebViewChromium的ViewGroup失效,也就是WebView失效。触发HTML页面更新原因很多，比如DOM树变化，CSS动画以及相应快速滚动或缩放手势等等；
View系统收到失效消息后，要求WebView部件重新绘制。如上所述，调用WebView.onDraw方法，继而触发AwContents.onDraw方法；
AwContents请求native端对象InProcessViewRenderer调用OnDraw方法
InProcessViewRenderer对象请求同步合成器（SynchronousCompositor）以软件模式合成页面内容；
页面中的内容层首先会被绘制一个SkPicture中，这个绘制操作只是记录绘制的命令
同步合成器的软件渲染子会re-play记录在SkPicture中的命令，将内容真正地绘制在WebView对应的Canvas上。这个过程被称为“光栅化”。

参考资源：

[1] 应用程序如何开启硬件加速，http://developer.android.com/guide/topics/graphics/hardware-accel.html#controlling

[2] Android视图系统的绘制模型，http://developer.android.com/guide/topics/graphics/hardware-accel.html#model