【前端优化之渲染优化】大屏android手机动画丢帧的背后

简介:
前言

上周我与阿里的宇果有一次技术的交流,然后对天猫H5站点做了一些浅层次的分析,后面点时间基本天天都会有联系,中途聊了一些技术细节、聊了双方团队在干什么,最后聊到了前端优化。因为我本身参与了几次携程H5站点的优化,在这方面有一些心得,但是与宇果交流的过程中发现我们在优化的时候忽略了一些细节。

携程做优化的时候整个重心基本放到了尺寸的缩减,和宇果的交流过程中他提出了渲染优化,其实渲染优化无非是减少回流,对于减少回流我们也有一些概念,我一直认为这个事情应该业务开发关注而不是框架关注(事实上框架也无法关注),所以对一些BUG采取了表现层面的解决,却对真相视而不见的做法,现在想来真的有点无知,这里便以一个原来的渲染BUG为切入点,将最近与宇果的交流所得整理下。

宇果博客:http://www.ghugo.com/

回流与重绘

首先,我们再次复习一下回流与重绘的知识,浏览器会解析三个东西:HTML、Javascript、CSS。

浏览器首先会根据HTML生成DOM Tree,其次会根据CSS生成CSS Rule Tree,javascript可以通过DOM API与CSS API操作DOM Tree与CSS Rule Tree,从而引起页面变化。

浏览器解析结束会通过DOM Tree与CSS Rule Tree形成render tree,只有display不为none的元素才会形成render Tree,render Tree形成后浏览器会调用GUI绘制页面,在此之前做的一件事情便是layout或者说reflow。上面的描述简单而言可以分为以下流程:

l  生成DOM树

l  计算CSS样式

l  构建render tree

l  reflow,定位元素位置大小

l  绘制页面

在这个过程中,若是javascript动态改变DOM Tree便会引起reflow

页面中的元素改变,只要不影响尺寸,比如只是颜色改变只会引起repaint不会引起回流

否则,reflow不可避免,这个时候便需要重新计算形成render Tree

reflow分为局部回流与全局回流,会影响下面的,不会影响上面的元素

reflow耗用的系统资源较大,DOM Tree中受到影响的节点皆会reflow,然后影响其子节点最坏的情况是所有节点reflow,该问题引发的现象便是低性能的电脑风扇不停的转,手机变得很热,并且非常耗电,以下操作可能引起reflow

l  操作dom结构

l  动画

l  DOM样式修改

l  获取元素尺寸的API

android大屏手机渲染BUG

这个是我们一个tab组件,这个组件按道理说非常简单:

 View Code
点击一下就让当前item获取class,然后文字样式会改变,下面一个横线也会动画滑动过去,但是这个东西在android大屏手机上却出了问题(比如note2),他会这样表现:



如图所示,class过去了,文字颜色也变了,但是下面对应的竖条却没有过去,我当时一看就知道是渲染的问题并且马上给出了一个解决方案:

 View Code
这里设置下划线width的时候触发了其回流,而setTimeout会在主程序执行结束后才触发,于是BUG修复了,核心代码如下:

 1 $(function () {
 2   var wrapper = $('.cui-tab-mod');
 3   wrapper.on('click', function (e) {
 4     var el = $(e.target);
 5     var toolBar = $('.cui-tab-scrollbar');
 6     if (el.hasClass('cui-item')) {
 7       wrapper.find('li').removeClass('cui-tab-current');
 8       el.addClass('cui-tab-current');
 9       //修复丢帧问题
10       setTimeout(function () {
11         toolBar.width('width', toolBar.width());
12       }, 0)
13     }
14   });
15 });
这个BUG解决后也没有再关注,时序纷飞,一年过去了却和宇果聊天过程中再次想起这个问题,才意识到自己忽略的是什么。

重新认识Timeline

我们常常有一个问题,如何知道页面哪里的渲染有问题,如何捕捉?

如果没有一个实际可用的工具的话,我们只能由外文或者博客获取这类知识,这个时候就和我解决上述问题差不多了,仅仅从皮毛上知道是渲染导致的问题,并且能使用回流解决问题,却是对渲染性能造成负担,所以如何捕捉渲染问题衡量渲染性能这个是第一位,好在chrome提供了Timeline:



以我们的页面为例,我们开始监控,这里稍微改变一下代码:

 1 var wrapper = $('.cui-tab-mod');
 2 wrapper.on('click', function (e) {
 3   var el = $(e.target);
 4   var toolBar = $('.cui-tab-scrollbar');
 5   if (el.hasClass('cui-item')) {
 6     wrapper.find('li').removeClass('cui-tab-current');
 7     el.addClass('cui-tab-current');
 8 //      setTimeout(function () {
 9 //        toolBar.width('width', toolBar.width());
10 //      }, 0)
11   }
12 });
13 
14 function setIndex(i) {
15   var els = wrapper.find('li');
16   els.removeClass('cui-tab-current');
17   els.eq(i).addClass('cui-tab-current');
18 }
我首先点击开始监控,然后鼠标不在页面做任何操作,在控制台输入一句:

setIndex(1)
于是页面会发生改变,这个时候,我们得到的图是:



这张图其实最初我也是看热闹的,昨天根据宇果的指点,才稍微看出点门道了:



首先请看上图中的一个个透明框,每个透明框便是两次显示器刷新周期中等待的时间,其中有一个非常关键的单位叫做fps,这个60fps是个什么东西呢?

60fps与16ms



所谓60fps便是说屏幕1s会刷新60次,意思是大概16.5ms屏幕会刷新一次,在这一次刷新中浏览器会干很多事情,这里还是以图示为例,这里有2个前提:

① 我们鼠标并未操作

② 我们页面很单一

所以在我们执行setIndex前,浏览器根本没有任何消耗,每一次的刷新干了这几件事情:



刚刚整个过程一过经过了2.29秒,浏览器发生了这些事情:



从白条来看,浏览器处理整个动作大概花费320ms,这里出了4种颜色,这个也比较关键。

4种颜色

黄色是说明正在执行javascript脚本,从这里可以看出,js执行的速度是非常快的,这里包含了设值class、移除class,获取width等一系列操作,浏览器会等一次结束后才发生渲染。

紫色是说明正在回流,也就是我们传说中的渲染,这个是非常耗费性能的,我们这里具体跟进去看看:



接下来触发了css3过渡transition的动画,下面的滚动条开始了不停的移动:

可以看到,后续所有的运动只影响了一个元素,这个元素便是滚动条,这里为了验证刚刚所说,我们做两个事情:

① 使用click触发索引更改

② 为下划线添加子元素



这里有个非常不同的就是,我鼠标在界面操作了,不可避免的会引起一些move样式改变,所以有重绘有回流,都比较轻,比较关键的是,其中多了一个click操作(Event),但是下面动画时候影响的元素仍然只是一个,这个有点不明原因,我这里特别将transform改成了left,因为transform更加平滑,我想找出原因,却发现了另一个现象:





可以看出transformd导致的动画只会执行一次paint,便是最初那一次,而使用left的话却在不停的paint,这个是资源消耗的对比:





可以看出,使用left时候出现了锯齿状,这个时候我们可以得出一个结论,transform的动画确实比left节省性能。

至此我们对chrome的Timeline有了一个新的认识,但是我们这里的观察全部是在PC端发生的,而手机端是怎么样的呢?

移动端的渲染



这个图与上图形成了鲜明对比,PC端就只有很小的波动,手机端却引起了很多涟漪,导致这个问题的原因是硬件设施(这里是盗图):



PS:这里苦于没有Android设备,chrome电脑又暂时抽风不能真机调试,便去同事那里草草截图,哎......

丢帧的发生

如前所述,浏览器一次的刷新约16ms,以一次原子行为来说是这样的:

脚本运行时间+渲染时间+绘制时间<16ms
如果中间有一次的操作比如渲染的时间大于了16ms而导致浏览器没有来得及绘制,那么那次的操作便失效了,这个就是所谓的丢帧。

我们在note2上运行程序时会导致丢帧,应该就是其中一次超出了时限,因为class变化会引起样式重新计算,但是只是文字变化的话只是会引起重绘,所以主要问题发生在transition动画。

而我们的解决方案是setTimeout,这个造成的影响是:



我们发现了,就算没有动画,重新计算样式那里依旧是主要导致的回流的因素,是他挤掉了后续的操作吗?他重新计算样式中的因素有很多,我怀疑的目光首先放到了这段css:

    .cui-tab-mod li:nth-of-type(1).cui-tab-current ~ .cui-tab-scrollbar { -webkit-transform: translate3d(0,0,0); 
-moz-transform: translate3d(0,0,0); -ms-transform: translate3d(0,0,0); transform: translate3d(0,0,0); }
测试下来,似乎与他相关:

 1 <!DOCTYPE html>
 2 <html xmlns="http://www.w3.org/1999/xhtml">
 3 <head>
 4   <meta name="viewport" content="width=320.1,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,minimal-ui">
 5   <title></title>
 6   <style type="text/css">
 7     body { -webkit-text-size-adjust: none; -webkit-tap-highlight-color: rgba(0,0,0,0); -webkit-font-smoothing: antialiased; -moz-user-select: none; }
 8     ul, ol { list-style: none; margin: 0; padding: 0; }
 9     .cui-tab-mod { display: -webkit-box; display: -moz-box; display: -ms-flexbox; display: -webkit-flex; display: flex; height: 43px; line-height: 43px; border-bottom: #bcbcbc 1px solid; background-color: #fafafa; color: #666; font-size: 15px; position: relative; display: table\9; width: 100%; }
10     .cui-tab-mod li { text-align: center; -webkit-box-flex: 1; -moz-box-flex: 1; -webkit-flex: 1; -ms-flex: 1; flex: 1; display: table-cell\9; }
11     .cui-tab-mod li.cui-tab-current { color: #099fde; }
12     .cui-tab-mod .cui-tab-scrollbar { position: absolute; left: 0; height: 4px; bottom: -1px; background-color: #099fde; -webkit-transition: -webkit-transform 300ms ease ; transition: transform 300ms ease ; z-index: -1; -webkit-backface-visibility:hidden; backface-visibility:hidden;     }
13     .cui-tabnum2 { width: 50%; }
14     .cui-tabnum3 { width: 33.33333%; }
15     .cui-tab-mod li.cui-tab-current ~ .cui-tab-scrollbar { z-index: 2; }
16   </style>
17   <script id="others_zepto_10rc1" type="text/javascript" class="library" src="http://sandbox.runjs.cn/js/sandbox/other/zepto.min.js"></script>
18 </head>
19 <body>
20   <ul class="cui-tab-mod">
21     <li data-key="0" data-index="0" class="cui-item cui-tab-current">中国</li>
22     <li data-key="1" data-index="1" class="cui-item">美国</li>
23     <li data-key="2" data-index="2" class="cui-item">日本</li>
24     <i class="cui-tab-scrollbar cui-tabnum3"><span>1</span></i>
25   </ul>
26   <script type="text/javascript">
27     var wrapper = $('.cui-tab-mod');
28     var toolBar = $('.cui-tab-scrollbar');
29     var els = wrapper.find('li');
30     wrapper.on('click', function (e) {
31       toolBar.css({
32         '-webkit-transform': 'translate3d(100%,0,0)',
33         'transform': 'translate3d(100%,0,0)'
34       })
35       var el = $(e.target);
36     });
37   </script>
38 </body>
39 </html>
如果这样,我直接操作toolBar便可以绕过该BUG,但是我还是不太确定,所以有了这段代码:

 View Code
 1 var wrapper = $('.cui-tab-mod');
 2 var toolBar = $('.cui-tab-scrollbar');
 3 var els = wrapper.find('li');
 4 
 5 wrapper.on('click', function (e) {
 6   var el = $(e.target);
 7   els.removeClass('cui-tab-current');
 8   el.addClass('cui-tab-current');
 9   toolBar.css('left', '0');
10 
11   //      setTimeout(function () {
12   //        toolBar.width('width', toolBar.width());
13   //      }, 0)
14 });
 

 

 

 

 

 

 

 

 

这一段代码也可以解决BUG,似乎解决bug的元素是导致了absolute元素的回流而与其它无关,这里再次对比Timeline:





两次对比没有什么差距,这个BUG导致的原因还需要深究,待我哪天去真机测试...... 

setTimeout动画

另外,最好也不要使用setTimeout之类的定时器来实现动画,下面这个动画操作也是非常消耗的:



这里如果使用requestAnimationFrame便可以避免Timer的影响。

fixed元素

一般来说,fixed元素在手机上尤其卡,我们这里也来追踪一下原因:





可以看到,fixed元素与left一样的都会不断的Paint,所以他卡呢,至于如何避免不同的团队有不同的方案。

结语

今天回顾了与宇果的交流过程中的渲染优化相关,这里还停留在比较浅的层次,需要继续学习,希望对各位有用,文中有误请您提出,最后微博求粉:



本文转自叶小钗博客园博客,原文链接:http://www.cnblogs.com/yexiaochai/p/4314260.html,如需转载请自行联系原作者
相关文章
|
20天前
|
缓存 监控 Java
构建高效Android应用:从优化用户体验到提升性能
在竞争激烈的移动应用市场中,为用户提供流畅和高效的体验是至关重要的。本文深入探讨了如何通过多种技术手段来优化Android应用的性能,包括UI响应性、内存管理和多线程处理。同时,我们还将讨论如何利用最新的Android框架和工具来诊断和解决性能瓶颈。通过实例分析和最佳实践,读者将能够理解并实施必要的优化策略,以确保他们的应用在保持响应迅速的同时,还能够有效地利用系统资源。
|
26天前
|
调度 数据库 Android开发
构建高效Android应用:Kotlin协程的实践与优化
在Android开发领域,Kotlin以其简洁的语法和平台友好性成为了开发的首选语言。其中,Kotlin协程作为处理异步任务的强大工具,它通过提供轻量级的线程管理机制,使得开发者能够在不阻塞主线程的情况下执行后台任务,从而提升应用性能和用户体验。本文将深入探讨Kotlin协程的核心概念,并通过实例演示如何在实际的Android应用中有效地使用协程进行网络请求、数据库操作以及UI的流畅更新。同时,我们还将讨论协程的调试技巧和常见问题的解决方法,以帮助开发者避免常见的陷阱,构建更加健壮和高效的Android应用。
35 4
|
18天前
|
Java Android开发 开发者
构建高效Android应用:Kotlin协程的实践与优化
在响应式编程范式日益盛行的今天,Kotlin协程作为一种轻量级的线程管理解决方案,为Android开发带来了性能和效率的双重提升。本文旨在探讨Kotlin协程的核心概念、实践方法及其在Android应用中的优化策略,帮助开发者构建更加流畅和高效的应用程序。通过深入分析协程的原理与应用场景,结合实际案例,本文将指导读者如何优雅地解决异步任务处理,避免阻塞UI线程,从而优化用户体验。
|
1天前
|
缓存 移动开发 Android开发
构建高效Android应用:从优化用户体验到提升性能表现
【4月更文挑战第18天】 在移动开发的世界中,打造一个既快速又流畅的Android应用并非易事。本文深入探讨了如何通过一系列创新的技术策略来提升应用性能和用户体验。我们将从用户界面(UI)设计的简约性原则出发,探索响应式布局和Material Design的实践,再深入剖析后台任务处理、内存管理和电池寿命优化的技巧。此外,文中还将讨论最新的Android Jetpack组件如何帮助开发者更高效地构建高质量的应用。此内容不仅适合经验丰富的开发者深化理解,也适合初学者构建起对Android高效开发的基础认识。
2 0
|
2天前
|
存储 缓存 前端开发
前端如何利用indexDB进行数据优化
使用IndexedDB作为浏览器内置的客户端数据库,用于存储大量数据和实现离线支持。它能缓存常用数据,减少服务器请求,提高用户体验。IndexedDB支持数据索引、复杂查询及版本管理,允许离线操作并同步到服务器。但需熟悉其异步API,可借助Dexie.js、localForage等库简化使用。
|
5天前
|
机器学习/深度学习 前端开发 算法
使用机器学习优化前端用户体验
在当今高度竞争的互联网市场中,用户体验是至关重要的。本文将探讨如何利用机器学习技术来优化前端用户体验,从而提高用户满意度和留存率。我们将介绍如何利用机器学习算法分析用户行为数据,优化网站性能和内容推荐,以及如何实时调整界面设计和交互方式,从而实现个性化、智能化的用户体验。
|
6天前
|
前端开发 算法 JavaScript
如何优化前端性能:探索图片压缩与延迟加载技术
本文深入探讨了前端性能优化中的关键问题:图片压缩与延迟加载技术。通过介绍图片压缩的原理和方法,并结合实例说明了如何有效减少图片大小、提升加载速度;同时,详细解析了延迟加载技术的实现原理及其在提高页面加载性能中的作用,为前端开发者提供了实用的优化方案。
|
8天前
|
缓存 前端开发 JavaScript
如何优化前端网页加载速度:7个实用技巧
在当今互联网时代,网页加载速度对用户体验至关重要。本文将介绍7个实用的技巧,帮助前端开发者优化网页加载速度,提升用户体验。从压缩资源到异步加载,从图片优化到缓存策略,这些技巧将帮助你在前端开发中取得更好的效果。
|
12天前
|
XML 开发工具 Android开发
构建高效的安卓应用:使用Jetpack Compose优化UI开发
【4月更文挑战第7天】 随着Android开发不断进化,开发者面临着提高应用性能与简化UI构建流程的双重挑战。本文将探讨如何使用Jetpack Compose这一现代UI工具包来优化安卓应用的开发流程,并提升用户界面的流畅性与一致性。通过介绍Jetpack Compose的核心概念、与传统方法的区别以及实际集成步骤,我们旨在提供一种高效且可靠的解决方案,以帮助开发者构建响应迅速且用户体验优良的安卓应用。
|
16天前
|
前端开发 JavaScript UED
如何优化前端网页性能提升用户体验
本文将探讨如何通过一系列前端优化技术,提高网页加载速度、减少资源请求次数,从而优化用户体验。我们将介绍一些常用的性能优化技巧,包括资源压缩、懒加载、CDN 加速等方法,帮助开发者更好地构建高效、流畅的前端网页。

热门文章

最新文章