我的2013 - 年终总结 + 浏览器渲染发展的一些思考

又到一年的年末，秉承传统，继续为这一年写一篇总结的文章。今年依旧延续了进入公司后每年都更换不同小组的传统，下半年调到了内核渲染组，不过之前在技术研究组的工作也一直是专注于浏览器渲染相关的技术研究，所以这次调动也算是顺理成章了，工作内容基本上没有任何变化。

今年一年以来的工作都跟硬件加速渲染有关，除了在不断完善和优化原有的硬件加速/图层混合加速的渲染架构，保证UC加速版的顺利发布外，另外最主要的工作就是设计和实现2D Canvas的加速渲染架构，从年初的初始实现版本到UC9.4加速版的版本，其间一共更替了三套不同的架构，而且每一次基本上都是完全推倒重来，但也解决了前一版本无法克服的一些内在缺陷，当前最新的架构基本上已经没有什么性能上明显的瓶颈，也足够灵活地根据不同的设备动态调整自己的行为，在兼容性，资源占用，性能这三者之间取得一个较好的平衡。

回顾自己这一年的收获，通过研究Android图形子系统的底层实现，研究GPU和其它各种硬件的工作原理，自己对渲染架构和性能的理解也越来越深刻。“物尽其用，要事优先”是自己对高性能渲染架构的总结，一个高性能的渲染架构，设计者需要对硬件有相当的认识，知道如何将一个完整的渲染任务合理地进行分解，然后调度不同的硬件尽可能并发地完成它；要了解哪里是性能的瓶颈，哪部分是关键的任务，要保证关键任务优先获得资源的分配，尽可能降低瓶颈的影响。

下半年开始，在和主管的工作总结中，还有职业等级评定的答辩会议上，都不断地被问到下面这两个问题，同时自己也在不断地进行思考。

• 浏览器的渲染架构还有没有可能有更大的性能突破？
• 浏览器能不能够成为一个承载游戏运行的良好平台，使得H5游戏能够跟原生游戏在同一层面竞争？

浏览器的渲染架构还有没有可能有更大的性能突破？

目前基于WebKit或者Blink内核浏览器的渲染架构，虽然各自的实现不太一样，但是整体架构设计都是由Apple奠定的，Apple当时把自己在MacOS上的那套Layer Rendering的渲染架构引入WebKit，率先在Safari上实现了Accelerated Compositing（图层混合加速），Chrome接着完成了自己的图层混合加速实现，而Android直到3.x的系统浏览器才开始支持，到了4.1才算是比较完善。虽然我不太了解Firefox的渲染架构实现，不过之前看过的一些文章介绍，思路总体上应该跟WebKit差不多。

图层混合加速将渲染任务分解为Paint（绘制）和Composite（混合），绘制由WebKit内核自身使用CPU在一个独立的线程完成，绘制或者光栅化后的结果Layer Buffer（图层缓存）被发送到混合线程，由GPU来进行混合，而Blit（缓存的混合）则是GPU最擅长的工作，甚至可能不需要动用GPU的3D加速单元，使用2D Blitter就够了。

这种架构主要的缺陷在于：

1. 为了保证渲染性能和效果，浏览器需要大量的图层缓存，尤其对于是一些图层非常复杂，数量非常多的网页，这个问题在移动设备上更加明显；
2. 由于绘制仍然使用CPU，对于普通的网页，绘制任务主要由图片，文本，各种不同图形的填充（使用纯色，渐变或者纹理）组成，CPU在大部份情况下的确做的比GPU更好，而且资源消耗更少，另外也有助于让GPU更专注于混合任务；但是对一些复杂的动态特效，像是CSS Filter的使用，单纯靠CPU会很困难，并且这种先绘制再混合的方式对于这些动态特效来说反而会造成性能上的损失，并且需要更多缓存；

第一个问题，如果GPU能够支持一种无损压缩的纹理作为图层缓存，并且压缩可以高效实时的完成（甚至可以使用GPU，在纹理上传的同时完成压缩），就能够得到极大的缓解（对于网页这种大部份以文本和图形为主的位图，压缩率应该非常高，使用ZIP压缩1/10都是很正常的），不过在了解了一些纹理压缩相关的知识后，发现这一点的确不太可能，GPU主要还是为了游戏设计的，而游戏使用的都是事先生成的压缩纹理，并且GPU为了读取压缩纹理时的速度考虑，不可能支持可变压缩率，所以也无法支持无损压缩。

第二个问题，可能的答案是将一部分绘制任务丢到混合线程直接由GPU来完成。不过困难在于两个方面：首先是否能够对绘制任务进行合理的分解，将其中一部分适合GPU完成的任务由GPU在混合线程直接进行绘制，而剩下的仍然保持原有的方式，简单说就是实现一种Hybrid Rendering架构；另一方面是使用GPU做缓存的混合是比较简单的，但是要直接完成复杂的绘制则比较困难，如果使用OpenGL，意味着要实现各种不同绘制的Shader，如果使用OpenVG这样的矢量图绘制API，貌似硬件兼容性和系统支持程度又有很多问题（Android系统本身是不支持OpenVG的，即使大部份GPU硬件上都支持）。除此之外使用RenderScript或者OpenCL这样的异构计算API来进行GPU加速绘制也是一种可能的方式。

浏览器能不能够成为一个承载游戏运行的良好平台，使得H5游戏能够跟原生游戏在同一层面竞争？

回答这个问题之前，先看一下现状，浏览器目前是通过2D Canvas和3D Canvas（WebGL）来支持2D/3D的即时绘图，这也是目前H5游戏的基础。在Android平台上，Chrome和UC都比较完整实现了2D Canvas的GPU加速，并且Chrome已经支持WebGL，UC接下来也会提供WebGL的支持，而WebGL本来就是对应到GLES。使用2D/3D Canvas开发H5游戏，存在的一些性能问题是：

1. Canvas元素只是网页中所有元素的其中一个，所以它的绘制必须先绘制到一个单独的缓存中，仍然再跟其它元素的图层缓存进行混合输出，这个会带来一些额外的开销，导致性能损耗。不过这个问题还好，对PC来说这个额外开销不算高，而移动设备GPU的性能也越来越好（不过分辨率飙升过快也是一个问题...）
2. 2D Canvas只提供了最基础的绘图API，难以通过这些API高效实现各种复杂的特效，比如说要实现一个粒子效果，不得不调用几十次甚至上百次drawRect或者drawBitmap，这样的效率非常低。而WebGL还好，可以允许游戏自己直接控制Buffer，自己编写Shader实现各种特效，直接交由GPU运行，从这点看，长远来说WebGL对游戏还是更有前途一些，不过相对来说，它的开发难度就要高不少（即使是使用2D Canvas开发的游戏，很多游戏也会在一些静态不需要太高性能的场景改成使用CSS+DIV来降低开发难度）；
3. 无论是2D Canvas也好，WebGL也好，它们都只提供了绘图API，离一个完整的游戏引擎相去甚远，而要依靠JS实现一个高性能的大型游戏引擎（包括物理运动引擎等）用来支撑一个大型游戏，受限于JS本身的性能，并且缺少底层硬件的直接控制能力，这点不得不说是最大的困难；

对于第三点，Firefox和Chrome的解决思路完全不同：

• Chrome通过Native Client允许原生代码直接在浏览器提供的一个受限环境里面运行；
• Firefox通过ASM.js + WebGL的方式，遵循ASM.js语法的代码仍然是标准的JS代码，但是特殊的语法使得JS虚拟机可以直接将它们翻译成机器码，高效地运行；

这两种方式先不谈技术本身的成熟度，共同存在的问题就是它们都太过复杂，游戏开发者不直接使用Cocos2D或者Unity3D这样成熟的游戏引擎开发原生游戏而使用Native Client或者ASM.js +WebGL，那简直就是脱裤子放屁，多此一举。

有没有第三种解决问题的思路，我个人认为，浏览器自带游戏引擎（自行开发或者整合第三方的游戏引擎），然后通过一套标准的游戏引擎API供JS调用是一种可行的方式，这样JS就基本上变成像Lua这样的场景控制脚本，这种方式能够同时解决性能的问题和游戏开发难度的问题，当然它的问题是这样的游戏引擎标准API的制定和浏览器的实现还是相当虚无缥缈的事情......

除了性能问题，H5游戏还有打包，发行等问题，不过这些可以通过打包应用（Packaged App）和Web App Store来解决。

最后是我这一年写的比较满意的一些文章：

1. Why Your Android Apps Suck https://plus.google.com/104793567654398886385/posts/TEr9MYV7tVy
2. Android GraphicBuffer Introduction and Its Usage in Rendering https://plus.google.com/104793567654398886385/posts/j1LcfHAr5BS
3. High Performance Canvas Game for Android（高性能Android Canvas游戏开发） http://tech.uc.cn/?p=2414