uniapp重新渲染页面_高性能Web动画和渲染原理系列（2）——渲染管线和CPU渲染...

【小宅按】 介绍浏览器渲染原理及CPU渲染流程

示例代码托管在：http://www.github.com/dashnowords/blogs
博客园地址：《大史住在大前端》原创博文目录

一. 高性能动画

动画的流畅程度通常是以FPS(Frame Per Second，每秒帧率)作为衡量的。在摄像机录制视频时每一帧实际上包含了一段时间内的画面记录（长曝光摄影的道理相同的），如果画面里的事物在运动，那么暂停播放时看到的画面通常都是模糊的，这样的画面也被称为“模糊帧”，加上双眼“视觉暂留”效果的影响，影视作品一般只要达到24FPS就可以展示出看起来连续运动的画面；而在页面的渲染中，每一帧都是由计算机计算渲染出来的精确画面，帧和帧之间并不存在模糊过渡，所以通常认为需要达到50FPS~60FPS的帧率，才能够得到较好的观看体验。

为了达到尽可能接近60FPS以上的帧率，浏览器每一帧的计算和绘制所花费的时间就需要控制在1000/60≈16.6ms以内，根据Google开发者社区提供的资料，开发者最好能够将所有的工作控制在10ms左右，以便给浏览器一些处理内部工作的时间，否则就无法在限定的时间内完成画面更新，动态的内容就会表现出卡顿，对用户体验造成负面影响。下一节就来看一下，在这16ms的时间里，浏览器都需要完成哪些任务。

二. 像素渲染管线

基本渲染流程

谈起浏览器的工作流程，你可能会在大多数文章中见过下面这张图：

它直观地描述了浏览器如何将HTML文件和CSS样式文件通过逐步处理最终合成渲染树并展示在页面上的过程，当然其中每一步都是非常复杂的，如果你对此还不熟悉，可以通过【浏览器的工作原理：新式网络浏览器幕后揭秘】这篇文章进行了解（极力推荐这篇文章！）。但实际上上面的流程里并没有覆盖网站的整个生命周期，它只是描述了从用户获取到网站首页和资源文件后到完成首屏渲染这段时间内所做的工作，尽管工作流程几乎是一致的，但诸如响应用户的交互动作，在页面上实现动画等等内容，只通过上面的宏观原理图理解起来还是很困难的。当开发者谈及浏览器渲染性能的话题时，我们通常会听到“重排”、“重绘”等术语，实际上它们就是对这后半部分工作的描述，它被称为“浏览器像素渲染管线”，此时就需要祭出Google开发者社区提供的基本原理图：

编写在JavaScript代码中的那些事件监听器、定时任务等等异步触发的代码就会在橙色的部分执行，这部分代码运行在主线程中，如果有问题的代码或是执行时间较长的代码在其中造成了阻塞，后续的几个步骤就只能等着，这会直接延缓页面的渲染甚至导致页面直接崩溃，当JavaScript执行完一个宏任务并清空了当前的微任务队列后，就会开始UI渲染流程，进入下一个环节。

在Style阶段需要找出发生变更的样式并重新计算相关的尺寸，当然在首屏渲染之前第一次处理CSS