浏览器渲染流水线解析(四)

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介:

5 非合成器动画性能分析和优化指南

前面已经我们已经把非合成器动画区分为 Blink 触发,无法由合成器运行的动画和由 Timer/RAF 驱动的 JS 动画两类,因为前者可以认为是后者的一个简化版本,所以这一章主要讨论 Timer/RAF 驱动的 JS 动画。

5.1 动画流水线

Blink Animation

从上图可以看出非合成器动画的流水线比合成器动画更长更复杂,并且非合成器动画的后半段跟合成器动画是一致的。

  1. JavaScipt 部分是页端实现的逻辑,可能包含了计算的部分,和调用浏览器提供的 API 的部分(修改 DOM 树,CSS 属性等),最终改变了网页的内容;
  2. 网页内容被改变会导致 Blink 生成新的 MainFrame,MainFrame 包括了重排版,更新图层树,和重新记录发生变更的图层的内容,生成新的 DisplayList,等等;
  3. Blink 生成新的 MainFrame 后需要向合成器发起 Commit 的请求,合成器在 Commit 过程中根据 MainFrame 生成自身的图层树,Blink 在 Commit 的过程中保持阻塞状态,Commit 完成后再继续运行;
  4. 合成器实际上有两棵图层树,新提交的 MainFrame 生成的是 Pending 树,用于绘制 Draw 的是 Active 树,只有当 Pending 树当前可见区域部分的分块全部完成 Rasterize 后,才会进入 Active 步骤,在 Active 的过程中,Pending 树相对于 Active 树的变更部分才会被同步到 Active 树;
  5. Active 后,合成器会向 UI 线程的窗口管理器发起重绘请求,窗口管理器会在下一个 VSync 的时候开始绘制新的一帧,后面的流程就跟合成器动画是一样的了;

上述流程的一些关键点是:

  1. 在合成器动画中,分块没有完成光栅化,出现空白是被允许的,这样浏览器可以更好地保证合成器动画的帧率,但是在非合成器动画中出现空白是不被允许的,因为新的 MainFrame 常常会带来大面积的变更,如果允许空白的话可能会出现非常不好的视觉效果。这样就导致合成器需要使用两棵图层树来构建一个类似双缓冲的机制,只有当 Pending 树在后台完成可见区域的光栅化时才被允许同步到 Active 树;
  2. 在非合成器动画过程中,Main Frame N,Main Frame N Active;Compositor Frame N,GL Frame N 这四个 Block 基本上可以认为是可以并发运行的(唯一会阻塞的环节是 Commit,不过 Commit 耗时一般不长),理论上我们要实现 60 帧的非合成器动画,只需要保证其中每个 Block 的耗时总和小于 16.7 毫秒即可。当然实际的状况下,在移动设备上很难实现这么多线程完全并发运行,加上过多线程带来的互相通讯的开销,使得每个 Block 的最大允许耗时实际上是小于 16.7 毫秒的;

5.2 动画耗时分析和优化指南

  1. JavaScipt 的耗时是由页端自己的逻辑决定的,一般超过 10 毫秒就基本上很难实现 60 帧的非合成器动画了;
  2. MainFrame 的耗时主要取决于网页 DOM 树,图层树的复杂程度和变化程度,在变更很小,比如只有几个元素的内容发生变化,图层树不变的情况下,一般耗时都是在 3 ~ 5 毫秒左右,如果变更很大,几十甚至几百都是有可能的;
  3. Commit 的耗时主要取决于图层树的复杂程度,一般耗时都很短,大概 2 ~ 3 毫秒上下;
  4. Rasterize 的耗时范围变化极大,取决于网页内容的复杂程度和新 MainFrame 在当前可见区域内网页内容发生变化的总面积,另外图片解码也发生在这个阶段,而图片解码也是光栅化耗时最多的一个环节,光栅化的耗时从几毫秒到几百毫秒都有可能(图片在第一次被光栅化时被解码,一直在可见区域内的图片不会被反复重解码);
  5. Active 跟 Commit 的耗时类似,主要取决于图层树的复杂程度,一般耗时很短,大概 2 ~ 3 毫秒上下;

总的来说对非合成器动画性能影响最大的通常是 JavaScript 和 Rasterize,要实现高性能的非合成器动画,页端需要很小心地控制 JavaScript 部分的耗时,并避免在每一帧中引入大面积的网页内容变化和大幅度的图层结构变化。另外非合成器动画的后半段就是合成器动画,所以对合成器动画的性能优化要求也同样适应于非合成器动画。

另外对于 WebGL 来说,当在 JavaScript 里面调用 WebGL API 时,这些命令只是被 Chrome 缓存起来,并不会在 Renderer 线程调用真正的 GL API,所以 WebGL API 在 JavaScript 部分的耗时只是一个 JS Binding 调用的 Overhead,最终绘制 WebGL 内容的 GPU 耗时实际上是被包含在最后的 GPU 的步骤里面。但是在移动平台上一个 JS Binding 调用的 Overhead 是相当高的,大概在 0.01 毫秒这个范围,所以每一帧超过 1000 个 WebGL API 调用的 WebGL 游戏,性能阻塞的瓶颈有很大概率会出现在 JavaScript 也就是 CPU 上,而不是 GPU。

目录
相关文章
|
23天前
|
存储 前端开发 开发者
|
7天前
|
域名解析 缓存 网络协议
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
浏览器中输入URL返回页面过程(超级详细)、DNS域名解析服务,TCP三次握手、四次挥手
|
10天前
|
缓存 前端开发 JavaScript
"面试通关秘籍:深度解析浏览器面试必考问题,从重绘回流到事件委托,让你一举拿下前端 Offer!"
【10月更文挑战第23天】在前端开发面试中,浏览器相关知识是必考内容。本文总结了四个常见问题:浏览器渲染机制、重绘与回流、性能优化及事件委托。通过具体示例和对比分析,帮助求职者更好地理解和准备面试。掌握这些知识点,有助于提升面试表现和实际工作能力。
42 1
|
13天前
|
缓存 自然语言处理 前端开发
浏览器渲染
【10月更文挑战第28天】浏览器渲染涉及将HTML、CSS和JavaScript代码转换为可视网页,主要步骤包括:解析HTML构建DOM树、解析CSS构建CSSOM树、合并DOM与CSSOM生成渲染树、布局确定元素位置和尺寸、绘制元素到屏幕、合成图层形成最终图像。此过程不断优化以提升性能。
|
22天前
|
Web App开发 SQL 数据库
使用 Python 解析火狐浏览器的 SQLite3 数据库
本文介绍如何使用 Python 解析火狐浏览器的 SQLite3 数据库,包括书签、历史记录和下载记录等。通过安装 Python 和 SQLite3,定位火狐数据库文件路径,编写 Python 脚本连接数据库并执行 SQL 查询,最终输出最近访问的网站历史记录。
|
1月前
|
前端开发 JavaScript 异构计算
简述浏览器的渲染原理
浏览器渲染原理主要包括以下步骤:1)解析HTML文档生成DOM树;2)解析CSS生成CSSOM树;3)结合DOM与CSSOM生成渲染树;4)布局计算(回流)确定元素大小和位置;5)绘制(Paint)将节点转为图形内容;6)合成(Composite)多层图像。整个过程从文档解析到最终输出完整网页,并通过优化技术提升性能。
|
21天前
|
JavaScript API
深入解析JS中的visibilitychange事件:监听浏览器标签间切换的利器
深入解析JS中的visibilitychange事件:监听浏览器标签间切换的利器
55 0
|
2月前
|
XML 编解码 JavaScript
从浏览器的解析规则认识XSS防御
从浏览器的解析规则认识XSS防御
40 2
|
3月前
|
弹性计算 运维 Serverless
项目管理和持续集成系统搭建问题之云效流水线支持阿里云产品的企业用户如何解决
项目管理和持续集成系统搭建问题之云效流水线支持阿里云产品的企业用户如何解决
75 1
项目管理和持续集成系统搭建问题之云效流水线支持阿里云产品的企业用户如何解决
|
3月前
|
敏捷开发 Java 测试技术
阿里云云效产品使用合集之如何下载流水线构建过程中生成的jar
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。

推荐镜像

更多