我的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

2013,我的年终总结

12-14

这里直接是拷贝过来的文字,有些链接没加上比如《深圳——经历磨练》,《2011总结》等等。各位小伙伴也来分享下你的2013吧。rn原文可以看这里:[url=http://blog.csdn.net/withiter/article/details/17320083][/url]rnrn想想已经12月中旬了,早点把2013年的年终总结写了也好。写总结的好处就是你可以通过总结看出你的成长或者退步。rn先稍微总结下毕业后这几年的变化。希望对刚毕业以及处于迷茫期的童鞋们有点帮助。rnrn2010年:rn其实在毕业之前到刚正式上班这段时间,我是很迷茫的。我在论坛里也经常看到这样的帖子,我会安慰他们说每个人基本上都会有这么一个阶段,所以不用太担心。从实习到转正之后,由于TL对我很信任,让我带了6-7个实习生做公司内部项目,导致我对未来很有信心,所以就有了这篇文章:《深圳——经历磨练》。现在回头看看这篇文章,还是被自己感动到了。那时候还是吃了不少苦,拿着2500块的薪水还很happy的为公司做这做那,真的是当公司就是自己的未来,把能奉献的都奉献给了公司。当然换回来的是技术的快速提升。那时候都不知道和公司提要求,类似涨薪水之类的,后来估计是老大看不下去了,主动给我涨了1000块薪水。rnrn2011年:rn这年是比较纠结的一年,各种诱惑。也经历了人生的第一次跳槽,而且很惊心动魄,有兴趣的去看看《2011总结》。也欢迎各位点评下当时的选择。。。rnrn2012年:rn这一年也算是我比较幸运的一年,不仅做了一些私活,而且也得到了一个比较好的工作机会。所以今年又跳了一次。。这。。我不知道说好还是坏,频繁的跳槽其实是不好的,但是人往高处走,水往低处流,我也没办法啊。为什么说比较幸运呢?因为这一年遇到了现在的女朋友。来看看《2012年终总结》。rnrn2013年:rn前面说了那么多废话,终于到今年了!还是和以前一样不分技术,生活,情感了。揉一起说到哪就哪吧~rn今年在工作上的角色有些变化。从之前的Develper慢慢做了一些Test/PL/PM的事情。我也对自身的定位重新思考了一下,我慢慢对产品经理的角色产生了兴趣,我觉得产品经理才是我近几年的目标。以前一直都是我被面试,今年也帮Team面了一些人。这里我个人比较反对那种面死对方的面试官。我对被面试的人的态度就是掌握的技术能参与工作,如果脑子灵活思路清晰点的那就更好!不需要一问一答,可以让面试者自由发挥,围绕一个项目或者一个模块从架构到技术细节进行阐述。我觉得这样的氛围才能让面试者正常的表现出自己的能力!rn再说说兼职这事,坛子里的好多同学比较有兴趣,我也来说说这事。今年年初的时候,我接了一个私活,100RMB/小时。这个私活不是整个项目,而是参与一个项目的开发。每天下班回家周末抽点时间做做,大概做了2,3个月左右,赚了几万块。这是别人找到我的。我自己也尝试过在国外的一些网站接一些活做做,赚点外快什么的。发现比较困难。也由于一些流程比较麻烦,我就也很少去这些网站看了。如果有兴趣的同学可以看看,国内的威客网站我就不说了,那啥,坑爹,白菜价的项目,算了,别接。这里我列几个国外的网站:rnElance:https://www.elance.com/rnFreelancer:http://www.freelancer.com/rn一般做前端的比较好接一些!rnrn再扯扯CSDN这边的事,很荣幸的成为了CSDN博客专家,到目前为止也写了3个专栏,有兴趣的可以去看看:http://blog.csdn.net/column/mycolumn.html。就在前2个月我也当了Java Web版的小版主。一是为了提升自己的能力,二是提升的自己的同时也能帮助到别人,最后就是想为CSDN做点事。这段过程让我受益颇多!感谢CSDN这个平台!最近有个CSDN博客之星的评选活动,我也很荣幸的被列入参选人选,这里也再帮自己拉个票吧,觉得博文写得还不错的就帮忙投我一票吧,感谢,投票地址:http://vote.blog.csdn.net/blogstaritem/blogstar2013/huxiwengrnrn上班之余,我还有一个4个人的私人小团队。组建也有2年左右了,之前做了一些小的项目没什么“钱景”,就直接放弃了那些项目,不去推广了。现在已经转战移动互联网,我们觉得现在的项目有一点的前景,大家都在用平时空余时间满怀激情的开发着。这个项目直接让我跟公司提出了离职申请,是的,我准备创业!不管成功与否我都不会为此次创业后悔。不过由于公司现在项目组的特殊原因,我还不能立即离职,在过完春节之后就可以全身心投入到自己的产品当中了!这也是我为什么会把角色转移到产品经理的原因。rnrn最后一个重量级的事情就是去见了女朋友家长!第一次见家长,我的小心脏紧张的都快蹦出来了。不过还好,一切顺利,叔叔阿姨都挺喜欢我的,最让我惊喜的是第一次见面就让我直接叫爸妈了!rn女朋友明年研究生毕业,前段日子在找工作,也挺辛苦的,功夫不负有心人,拿了一些offer,最终决定去高德,10k/月。是俺刚毕业时候的4倍啊!真是让人羡慕。rnrn再用几句话总结下今年的一切,事业稳步提升,但这不是我想要的,要搞就搞大的!见了女朋友家长,老婆应该算是到手了吧,哈哈。最后祝各位学习事业步步高升,加薪升职,家庭幸福美满!

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试

关闭