How Rendering Work (in WebKit and Blink)

Posted by Roger on 2014 年 4 月 16 日

自从开始从事浏览器内核开发工作以来，已经写过不少跟渲染相关的文章。但是一直想写一篇像 How Browsers Work 类似，能够系统，完整地阐述浏览器的渲染引擎是如何工作的，它是如何对网页渲染性能进行优化的文章，却一直因为畏惧所需要花费的时间和精力，迟迟无法动笔。不管如何，现在终于鼓起勇气来写了，希望自己能够完成吧…

文章包括的主要内容如下 —

首先明确文中关于渲染的定义，浏览器内核引擎通常又被称为网页渲染引擎，但是这里的渲染实际上是一个泛指，广义的渲染，它包括了浏览器内核所有的主要工作 － 加载，解析，排版，绘制等等。而在本文里面的渲染，指的是跟绘制相关的部分，也就是浏览器是如何将排版后的结果最终显示在屏幕上的这一过程。如果读者希望先对浏览器内核引擎，特别是 WebKit 有一个大概的了解，How Browsers Work，，WebKit for Developers 可以提供不错的入门指引。

其次，本文主要描述 WebKit 引擎的实现，不过因为 Blink 实际上从 WebKit 分支出来的时间并不长，两者在渲染整体架构上还是基本一致的，所以文中不会明确区分这两者。

最后，希望这篇文章能够给从事浏览器内核开发，特别是渲染引擎开发的开发者一个能够快速入门的指引，并给前端开发者优化网页渲染性能提供足够的知识和帮助。

因为文章后续还有可能会持续修订和补充，如果要查看最新的内容，请访问个人博客的原文：，如果有什么疏漏和错误，也欢迎读者来信指正（roger2yi@gmail.com）。

渲染基础 － DOM ＆ RenderObject & RenderLayer

图片来自 GPU Accelerated Compositing in Chrome

Tags:

高性能Android Canvas游戏开发

Posted by Roger on 2013 年 11 月 6 日

UC在今年年初发布了支持硬件加速的实验室版，开始实验性地支持对2D Canvas进行硬件加速。在之前发布的9.3版本中开始分开两个版本 – 普通版和加速版，针对中高端手机的加速版开始正式支持硬件加速2D Canvas渲染。并且在即将发布的9.4加速版还会带来全新的Canvas渲染架构，进一步提升性能和减少对系统资源的占用。

这篇文章的主要目的是为移动Canvas游戏的开发者如何针对Android UC浏览器加速版进行渲染性能优化提供指导，不过文中的大部分内容也适用于Android平台其它支持硬件加速2D Canvas的浏览器，比如Chrome for Android（Chrome也已经正式成为Android 4.4的系统内置浏览器）。另外，这篇文章的内容主要是针对渲染性能优化，而不是JavaScript性能优化，不过因为Android UC浏览器使用的是V8引擎，所以您应该很容易找到很多如何针对V8优化JavaScript性能的文章。

Rule #0 为移动平台进行优化

为移动平台进行优化是十分重要的，因为移动平台的性能大概只有桌面平台的1/10左右（注1），它通常意味着：

注释：

如果您需要对移动平台浏览器的性能有一个全面的了解，建议阅读文章“Why mobile web apps are slow”（原文，译文）和”5 Myths About Mobile Web Performance“（原文，译文）。

Rule #1 为Android而不是iOS而优化

牢记这一点非常重要，Mobile Safari的Canvas渲染机制跟Android平台有很大的不同，特别地针对Mobile Safari进行优化的Canvas游戏在Android平台的渲染性能会十分的糟糕。

Mobile Safari使用了iOS/MacOS平台特有的IOSurface作为Canvas的Buffer，当通过Canvas API往IOSurface绘制内容的时候是没有GPU加速的，iOS仍然使用CPU进行绘制，但是将一个IOSurface绘制到另外一个IOSurface上的时候，iOS会使用GPU的2D位拷贝加速单元进行加速（注1）。这种机制其实也是iOS UI界面Layer Rendering渲染架构的基础。所以为iOS优化的Canvas游戏会倾向于使用大量的Off-Screen Canvas（注2），不管是静态的图片也好，还是需要动态产生的内容也好，统统都缓存到一个Off-Screen Canvas上，最终游戏场景的绘制就是一个把一堆Off-Screen Canvas绘制到一个On-Screen Canvas的过程，这样就可以充分利用iOS绘制IOSurface到IOSurface使用了GPU加速的特性来提升渲染性能。

但是这种大量使用Off-Screen Canvas的做法在Android平台的浏览器上会非常糟糕。Android平台并没有IOSurface的同等物（一块同时支持CPU读写和GPU读写的缓冲区），所以它只能使用GL API对Canvas进行加速，一个加速的Canvas，它的Buffer是一个GL Texture（被attach到一个FBO上），这意味着：

后续的内容会进一步说明如何针对使用GL加速的Canvas渲染架构进行优化。

注释：

一般GPU都会带有多个独立的加速单元，包括3D加速单元，支持GL和D3D这样的3D API；2D位拷贝加速单元，对将一块缓冲区绘制到另外一块缓冲区进行加速；2D矢量绘制加速单元，支持像OpenVG这样的2D API，但是Android平台只支持通过GL API使用GPU加速，并没有公开的2D位拷贝加速API，虽然2.x的时候厂商可以提供一个copybit模块对位拷贝进行加速，供SurfaceFlinger使用，但这个模块不是通用的，并且不对外公开，另外在4.x的时候也已经移除了。

Off-Screen Canvas在文中是指display:none，没有attach到DOM树上的Canvas，相对于On-Screen Canvas而言。

Tags: android canvas