手机QQ浏览器4.0渲染架构分析

简单分析了一下手机QQ浏览器4.0的渲染架构,主要通过反编译代码,DDMS Method Profiling,Hierachy Viewer,dumpsys等工具,在Galaxy Note(4.1 ROM),开了GPU强制加速进行验证:

1,QQ目前还没有真正支持硬件加速,代码里面的Compositor(负责合成)的子类有两个CompositorSW和CompositorHwAccel,CompositorHwAccel仍然是空的,实际使用的是CompositorSW;

public CompositorHwAccel(WebView paramWebView)
{
super(paramWebView);
throw new RuntimeException(“Hardware accel is not implemented yet”);
}

2,QQ目前的渲染架构应该是从系统浏览器2.x版本改过来的,改动比较大,从系统浏览器移植的WebView并不负责实际上的渲染,而是交由自己的Compositor负责(WebView实际并不真正当作一个正常的View来使用,也没有嵌入当前的View Hierachy);

3,在网页显示的区域,QQ会创建一个SurfaceView叠加在上面,Compositor在WebCore线程获得这个SurfaceView的Surface(实际上是获得Surface的Graphics Buffer),网页预先渲染到一块内部的位图缓存,然后把这块位图缓存拷贝到Surface上面(drawBitmap),因为SurfaceView和Activity Window的混合是由系统的Window Compositor完成,所以不受Activity Window是否开启硬件加速影响;

4,外壳使用标准的Android View,绘制到Activity Window上,Activity Window是否开启硬件加速对外壳影响不大;

5,所以QQ所有的网页渲染都是发生在WebCore线程,绘制到一个独立的SurfaceView上,最终显示到屏幕是交由系统的Window Compositor负责,Activity Window是否开启硬件加速对网页渲染不起任何作用,网页渲染始终都是使用CPU完成,总的来说这种方式比较好的解决了用户开启强制GPU加速的情况,但是后续要实现真正的硬件加速相对比较麻烦;

6,QQ渲染架构后续的发展有两种可能,一是迁移到4.x系统浏览器的渲染架构,但是这个跟QQ目前的渲染架构差别比较大,除非自己搞的这套机制完全废弃掉;二是把SurfaceView改成GLSurfaceView,使用GPU来进行贴图,不过目前QQ貌似还不支持分块渲染,估计要自己先实现一套分块渲染的架构;

Advertisements