browser-rendering-optimization, 60fps 平滑度的浏览器渲染优化 !

分享于 

8分钟阅读

GitHub

  繁體 雙語
Notes on browser rendering optimization and hitting 60fps smoothness!
  • 源代码名称:browser-rendering-optimization
  • 源代码网址:http://www.github.com/vasanthk/browser-rendering-optimization
  • browser-rendering-optimization源代码文档
  • browser-rendering-optimization源代码下载
  • Git URL:
    git://www.github.com/vasanthk/browser-rendering-optimization.git
    Git Clone代码到本地:
    git clone http://www.github.com/vasanthk/browser-rendering-optimization
    Subversion代码到本地:
    $ svn co --depth empty http://www.github.com/vasanthk/browser-rendering-optimization
    Checked out revision 1.
    $ cd repo
    $ svn up trunk
    
    浏览器渲染优化

    浏览器渲染优化和点击 60fps 平滑度的说明 !

    理解如何优化web站点和应用程序之前,要了解在编写的代码和绘制的像素之间实际上是什么。

    浏览器执行以下六个不同的任务来完成所有这些任务:

    • 下载和解析 HTML,CSS和 JavaScript
    • 评估 JavaScript
    • 计算元素的样式
    • 在页面上布局元素
    • 绘制元素的实际像素

    将用户置于性能中心

    • 100毫秒
      • 在这个时间窗口中响应用户操作,他们会觉得结果是即时的。 行动与React之间的联系。
    • 1 秒
      • 在这个窗口中,事物感觉自然和连续的任务的一部分。 此外,用户将失去对他们正在执行的任务的关注。 对于网络上的大多数用户来说,加载页面或者更改视图都是一个任务。
    • 16毫秒
      • 给出一个每秒更新1 次的屏幕,该窗口表示将单个帧设置为屏幕的时间( 教授数学表示 ÷ 60 = ~16).。 人们在跟踪运动时非常好,不喜欢在不满足运动的期望或者周期性停止时不喜欢。

    Browser rendering pipeline - 60fps

    60fps = 16 ms/frame,但实际上只有 10 -12ms才能完成所有工作,因为浏览器开销。

    应用生命周期( 轨道)

    • 响应
    • 动画
    • 空闲
    • 加载( XHR,web sockets,HTML导入 等等 )

    RAIL

    实际时间顺序
    • 加载( ~1秒) 初始页加载。 在这里下载并渲染关键资源。
    • 空闲( ~ 50ms 块) 执行所有非必需的工作以确保稍后发生的交互。 如 延迟加载 项目,做前动画calcs等。
    • 响应( ~100ms ),在 100毫秒内响应。
    • 实际上我们从( ~16ms ) 获得了 ~12ms,因为浏览器有一些开销。

    RAIL Time Table

    样式更改时发生的情况?

    例如在不透明度变化或者变换动画中,只触发合成。
    • 页面没有收到任何新的HTML,所以DOM不需要构建。
    • 页面没有接收任何新的CSS,因此CSSOM不需要构建。
    • 页面没有收到任何新的HTML或者 CSS,所以呈现树不需要被触摸。
    • 如果不透明度或者转换更改影响它的自身层上的元素,则不需要运行布局。
    • 如果不透明度或者变换改变影响它的自身层上的元素,则不需要运行油漆。

    用于运行更快的JavaScript代码

    • 不要把注意力集中在微优化上。 由于不同的JS引擎( V8 等等 ) 以不同的方式处理它,所以循环 vs。
    • JS可以触发渲染管道( 样式。布局。绘制和合成更改)的每个部分,因此在每个帧中尽早运行它。

    动画

    • 'requestAnimationFrame是创建动画的goto工具。
      • 安排在每个帧的最早可能时刻运行的JavaScript。
      • 浏览器可以将并发动画优化成单一的重排和重绘循环,从而实现更高的。 例如基于js的动画与CSS过渡或者 SVG SMIL同步。
      • 另外,如果在不可见的选项卡中运行动画循环,浏览器将不会保持运行,这意味着 LESS CPU,GPU和内存使用率会更高,导致电池寿命更长。
    • 浏览器必须在 60fps IE 处渲染帧。 16 ms/帧。
      • 由于浏览器开销,我们绕过 10毫秒,所以JS大约有 3ms 个时间。
    • JavaScript -> 样式-> 布局-> 绘制-> 复合
    • 在执行这里操作时,不要对动画使用setTimout或者 when,因为JS引擎不会注意渲染管道。
    • 对于 IE9 - 在Polyfill中使用'requestanimationframe'。

    Webworkers

    • Webworkers提供了一个用于在 background 中运行脚本的接口,在一个完全不同的范围内,也在单独的。
    • Webworkers和主线程可以互相通信。

    Web Worker

    的样式和布局( 重新计算样式)

    • 重新计算样式的成本随页面上元素的数量线性缩放。
    • 边界元: block 元素修饰符: 将这里样式用于CSS选择器。
    • 类匹配通常是现代浏览器中最快的选择器。
    • 缩短'重新计算样式'时间。
      • 减少受影响元素( 渲染树的更改更少)
      • 减少选择器复杂度( 选择元素的标记&类名称更少)
    • '强制同步布局'。当你要求浏览器运行时发生'布局'第一个 inside 部分,然后执行'样式'calcs and然后重新运行布局。 尝试避免它 Chrome 开发工具( 火焰图) 有助于识别这里问题。
    • 读取布局属性并批处理样式更改以避免尽可能多地运行布局。
    • 当你连续多次执行'强制同步布局'时,会发生布局抖动。

    重画和重排

    绘画是浏览器采取它的所有属性的抽象 Collection的过程,并实际计算要绘制的像素。 这包括计算框的阴影和渐变,以及调整图像的大小。 对更改可见性但不影响它的布局的元素的外观进行更改时发生重绘。 其中包括大纲。可见性或者 background 颜色。 根据 Opera,重绘很昂贵,因为浏览器必须验证DOM树中所有其他节点的可见性。

    回流对性能更加关键,因为它涉及影响页面( 或者整个页面)的布局的更改。 元素的回流会导致所有子元素和祖先元素的后续重排,以及在DOM中跟随的任何元素。 根据 Opera,大多数reflows本质上导致页面被渲染。

    因此,如果他们对性能非常糟糕,那么什么原因导致了回流?

    很遗憾,很多东西在编写CSS时,其中一些尤其重要:

    • 调整窗口大小。
    • 更改字体。
    • 添加或者删除样式表。
    • 内容更改,例如用户在输入框中键入文本。
    • 激活CSS伪类( 如 :hover ) ( 在激活兄弟类的伪类中)
    • 处理类属性。
    • 处理DOM的脚本。
    • 计算offsetWidth和 offsetHeight。
    • 设置 style 属性 的 值

    有关完整列表,请查阅爱尔兰gist的保罗。

    的合成和绘画

    • 更新层树:当 Chrome 引擎( 闪烁) 内部发生了什么层需要页面时发生。 它查看元素的样式,并指出所需要的顺序和需要多少层。
    • 你可以将页面的独立元素添加到它自己的图层。 但是,添加一个大量的层次结构会带来成本- 所以在任何意义上使用它。
    • 使用CSS添加图层:
      • 常规方式- 在所有浏览器中都支持: transform: translatez(o);
      • 新方法- Chrome/Firefox 支持/无 edge: will-change: transform;
    • 复合图层:浏览器将页面放在一起以居中显示屏幕的位置。

    感谢 Paul 和卡梅隆Pittman在 Udacity上的课程,这对这个主题提出了深入的见解。

    其他链接:

    引入了 rails: 一个以用户为中心的性能模型。

    轨道性能模型


    bro  浏览  SMO  优化  
    相关文章