HTML5页面渲染性能的”程序转换“思路

做浏览器内核引擎的,一般都会考虑怎么做性能优化,这个优化实际上包括下面的内容:

(1)内存占用的优化,特别是对于嵌入式设备尤其重要,chromium有个blimp thin client的模块,不知道有没有用处;

(2)渲染性能的提高,注意核心就是尽量利用硬件GPU来做渲染,避免CPU计算和内存Copy的开销

(3)网络IO性能的提高,改善页面加载、响应数据,乃至云加速压缩流量、广告过滤屏蔽无用流量,等等

好吧,性能优化也就是这么多内容。但我要讲的”程序转换“思路不是这么回事,这个想法是:

在保证页面最终渲染结构及用户UX可用性差别不大的情况下,做极端的处理在parser阶段转换HTML代码(包含CSS、JS)。

也就是说,这个思路的核心在于一个能够理解W3C规范的高级的类似于编译器前端转换引擎。

这个领域,目前似乎还没有进一步深入的工作。

对前端开发,Babel.js以其其他的一些JS工具能够将ES6语法的JS代码转换为老的JavaScript。不过,纯JS做这个源代码转换问题倒不是很大,可以在AST上面进行模板转换。

问题是对于一个包含了HTML+CSS+JS的复杂页面,做”程序转换“就不是那么简单了。

不过,假如Web的未来就是用JS实现一切(JS DOM、CSS Houdini用JS来定制Layout、Service Worker控制loader过程),那么也许这个问题最终还是可以转换为JS源代码转换。

假设现阶段只对HTML+CSS这么做的话(不考虑前端JS框架生成html代码的情况,因为这可以移到后端来完成),可以考虑的优化情形:

(1)针对设备的viewport进行layout相关的重新改写,比如,将某些auto width/height转换为固定的宽高,这可以大大提高浏览器内核进一步layout的速度;

(2)针对某些无用的嵌套很深的div、viewport外的或者隐藏不可见的div(可能需要JS来触发显示),可以在初始阶段直接忽略掉(但是需要实现一个按需的重新parser/load进DOM树的过程)

这只是设想的比较简单的情形。这个地方最关键的就是需要一个高性能的解释器引擎。


Asm.js创建了一套基于Type Hints的JS子集,此子集可供JavaScript引擎直接优化为类型特定的机器代码(而不是动态的对象访问)。

HTML5似乎也可以采用这种思路:定义一个HTML5的渲染性能优化子集。此子集可被layout引擎高效处理。甚至不需要创建复杂的render树(采用JS DOM描述)。但这个优化子集究竟应该是什么样子的,目前还没法给一个具体的描述。



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