2015-10-11 |

浅谈 WebApp 动画效率-前端杂谈

手机页面动画效率

前端杂谈 - 浅谈 WebApp 动画效率

自从 HTML5 诞生之后,关于 Web App 和 Native App 的讨论就从未间断过,孰优孰劣大家各执一词。但作为前端开发者的我们,心里其实是明白的,这个世界是你们的(Native App),也是我们(Web App)的,但终究还是我们的,如果几十年后再回头看这一路的话,会发现你们不过是一插罢了。

但现在摆在眼前的事实是,Native App 比 Web App 的市场大,大家更愿意去用 Java 或者 OC ,而不愿意用 Js。大家都不喜欢用 Web App ,究其原因无非就两点:兼容性、慢。

那我们就来谈谈慢这个问题。但貌似这个问题很庞大,这里就谈一些我了解的东西。

提高页面加载速度,这个问题老生常谈了,什么多域名、CDN、组件化、seajs都是解决办法,淘宝首页就是个很好的案例。这里我们就不再赘述,网上很多其它相关的资料。

动画才是我们今天要谈论的主要内容:如何做到 60fps。

60pfs 这是CRT显示器的刷新频率,也是人眼感觉不到卡顿的频率,也就是每秒 60 帧,每帧的时间间隔是 16ms。然后我们了解一下浏览器的渲染机制,计算机需要在 16ms 内完成下面这些任务:

  • 计算Js

  • 浏览器计算layout

  • 绘图paint

  • 在GPU上拼合图层composite

第一步 JS 计算是由开发者控制的,在这里的操作会影响到下面三步。在前端性能上我们经常遇到的问题就是回流,这就是由于开发者调用了一些方法触发了 layout,然后浏览器就接着 paint、composite。

所以在做动画的时候,不要用 JS 做计算密集型的任务,jQuery 返回的对象做好缓存,避免多次调用。layout 能不触发就不触发,paint 能不触发就不触发。那怎么做才能只触发 composite 呢? opacity 和 transform 这两个属性是不会触发 layout 和 paint 的。所以作为前端开发,我们很喜欢也很乐于做透明度淡入淡出,因为这个不会用太大的性能问题。

前端杂谈 - 浅谈 WebApp 动画效率

有的同学就要问了:咦?color 和 box-shadow 这些也不涉及到 layout 啊,那我可以大规模的运用吗?

答案是不行,为什么呢?因为在 layout、paint 和 composite 中,最消耗性能的就是 paint。具体有多消耗呢?

前端杂谈 - 浅谈 WebApp 动画效率

上面是我打开一个带有视差滚动效果的 medium 页面后,从上向下滚动时产生的数据,其中绿色部分就是 paint + composite。可以看到在桌面上,视差滚动勉强达到 60fps,这样的性能在手机上肯定是惨不忍睹的。其实在视差滚动中,元素的颜色大小位置都没有改变,理论上是不需要 repaint 的,那么如何才能避免它呢?

其中一种方法就是创建新的 layer,但这种方法有一定的代价,其中最出名的就是在高 DPI 屏幕下字体显示问题,还有子元素position:fixed错位等等一些事情。

前端杂谈 - 浅谈 WebApp 动画效率

上面的图片就是在 surface pro3 + chrome 访问 feedly 的截图,可以明显的看到文字发虚。

日子还是要过的,Native App 也是要被打败的,那么怎么办呢?

前端杂谈 - 浅谈 WebApp 动画效率

Flipboard 开发团队就发明了一种丧心病狂的办法:用 canvas 渲染。Canvas 直接与 GPU 打交道,渲染速度非常快。但在使用过程中还是有很多顾虑的,下面是会遇到的一些问题:

  • 文字换行如何处理

  • 图片需要加载后才能放入 canvas

  • 元素层级如何处理

  • 自定义字体

  • 如何排版

尤其是排版问题,CSS已经很成熟了,自己创立其它机制来排版无疑是搬石头砸自己的脚。所以 Flipboard 开发小组就将 DOM 和 Canvas 合二为一,利用 DOM 的排版优势和 Canvas 的渲染优势。

现在用手机访问 Flipboard 就可以看到他们的这一成果了,其方法就是文档结构按照正常的 DOM 来,但是不加任何的颜色样式,然后把这一层透明度改为 0 。在其上层再加入一层 canvas ,用来显示渲染的结果。效果还是很不错的:

总的来说,未来还是很光明的,虽然 web app 有各种各样的性能问题,但它还是向着越来越好的方向发展。只要我们合适的利用浏览器给我们的资源,我们还是可以做出优秀的效果的。

 

前端观察


发表评论

    评价:
    验证码: 点击我更换图片