浅谈移动前端性能优化

Question

随着 Html5 的正式定稿，移动前端步入APP世界的步伐也随之加速。目前主流的两大手机系统厂商（google、苹果）都是 Html5 的参与者，所以这两大系统在对 html5 的支持上基本是没什么问题的。然而对于很多开发者来说，也许仅仅是因为使用前的一番可行性分析便放弃这种方案。因为很多资料都叙述着 Html5 相比原生 App 的各种不足。其中最尴尬的一条莫过于“性能”问题。

前端性能问题与优势

因为这个问题，刚开始接触的时候我也有很强的抵触情绪。但后来慢慢的发现，其实很多时候性能本就不是问题。适当的调整Html和Css，我们的网页同样可以无限接近原生程序。而且个人认为，大多数时候程序是否流畅并非取决于某种编程语言，而是取决于写程序的人。相比通过各种代码填充来完成目标任务，我更喜欢把技术当做艺术，写代码也应该有所追求。

其实，Html5 相比原生 App 的开发有很多诱人的方面。

• 其一：可快速迭代。 最简单最直接的一个：IOS 程序每次上传都需要通过漫长的审核时间，如果赶时间的话这是个问题，而且耐心等待之后未必就能得到一个我们想要的结果，审核不通也不是不可能。Html5 开发完成之后也不用再次上传审核。（若与原生程序有交互变更，此项无效）
• 其二：跨平台。Html 跨平台的特性早已不是一天两天的事了。IOS 开发完成的同时，Android 也基本完成。开发效率和成本上相比原生应用确实有较明显的优势。
• 其三：转发率高。现在打开微信朋友圈就能看到各种分享。如：文章分享，产品分享，XX 店铺等。通过连接转发可以实现快速分享，提高流量。

谈完优势，再说说自身经历。本是一名老老实实的 C# 程序员，没事就学习各种程序优化（sql 为主）的我在几个月前突然转向移动网页开发。在一个不算小的团队里前端工程师是一枚传统前端工程师。除能完成简单的手机布局外其他一窍不通，于是乎关于 JavaScript、前端性能优化等各种重担都落到了我这里。由于前端所完成的仅仅是以 html 的形式展现出效果图的模样，很少涉及到性能问题。于是漫长的学习之路由此开始了。

究竟什么样的页面是需要优化的页面？

• 1、页面上下滑动时感觉卡顿不流畅或是基本不动；
• 2、动画效果卡顿，看上去感觉一帧一帧的跳动；

简单点说，就是感觉卡。也许 iphone6 不卡但是 iphone4 上会卡，也许iphone上不卡三星上感觉卡、魅族、小米、华为、联想？国内屌丝机各有个的长相各有各的特色，比如魅族的MX，其他手机都很正常的时候它就卡。Html兼容一直都不是一件容易的事。

上述问题该如何破？

解决问题的关键在于找到问题的所在。砍柴还得有装备，工具很重要。以前用chrome，是因为感觉这货比较好使（直到放弃多年来一直钟爱的IE）。几个月前才发现这是一个调试工具也很好使的浏览器（简直就是神器）。其实关于html性能问题，很多博客上都有解释重绘这个事。下面主要谈谈如何用chrome鉴别重绘元素。

打开 chrome，开启开发者工具 F12。打开模拟器，并选择需要模拟的设备，在Console中选择Rendering 选中第一条（Show paint rectangles）。若打开开发者工具后没看见下方 Console 这块可以按下Esc。

完成上述操作后，请将视线移动到左侧网页上的绿色矩形框上。

PS：一直都很喜欢淘宝的广告，创意从未间断过。

这个绿色框就是浏览器重绘的部分。这个框越大，说明重绘的区域也就越大。重绘并没什么问题，这很正常，不正常的是大面积重绘，比如上图中的时间跳动，如果仅仅是时间那个区域重绘并没有什么问题，要是整个页面都一直闪着个绿框框那就完蛋了。为何大面积重绘会出现性能问题，这个还得从浏览器渲染上谈起。那是一个很长的故事，有兴趣的朋友可以找些资料看看。

简单的举例就是，浏览器把 html 文档解析成网页展现到我们面前，其中间是一个“漫长”的过程。再载入文档之后需要对 html 进行分割、读取并计算其样式大小、然后进行图层绘制、合并图层等一系列操作。整个过程其实使用最多的部件是 CPU 和 GPU。

重绘的面积大小和回流（reflows）有关，关于回流其实可以这样理解，当改变一个元素后对其它节点元素产生影响。就如同可石子投入水中引起的波纹一样，波纹所到之处基本都会有所影响。而在Html中子节点的变化会引起祖先的回流，同时也会影响到部分兄弟节点，大部分的回流将导致页面的重新渲染。那么如何降低回流，减小重绘面积呢？淘宝时间不也只更新了一小块么！这里提供两种方法：

• 1、使用 position 属性的 fixed 值或 absolute 值。
• 2、创建独立的Layer（层）（为避免和div（层）产生混淆文中尽量同一使用Layer）。

继续看淘宝：

第一种方法已经很明显了就不再赘述。说说第二种方法吧。首先说说在 Chrome 中如何查看独立的 Layer 呢。如上图，选择 Show composited layer borders 后在页面上独立的 Layer 上回显示一个橘黄色边框。那么又要如何才能建立独立的 Layer 呢？

在 Chrome 中创建独立的 Layer 仅需要符合下述条件之一：

1. 有 3D 元素的属性；
2. video 标签并使用加速视频解码；
3. canvas 元素并启用 3D；
4. 插件，比如 flash；
5. CSS 动画；
6. CSS 滤镜；
7. 有一个后代元素是独立的 layer；
8. 元素的相邻元素是独立 layer。

看上去挺多挺复杂的，其实最简单、最容易理解、也最容易滥用的是第一条。实现第一条仅需要在元素的样式里加上。transform:translateZ(0);-webkit-transform:translateZ(0); 就可以了。我们将淘宝往下滑动一点，找一个元素试试看。

还是看淘宝：

当加上css样式后对应的元素上出现了橘黄色边框，事实证明这招是有效的。而在Chrome中这样做可以启用GPU硬件加速。初次看到加速两个字让人觉得无比兴奋，仿佛找到了克敌制胜的无敌神招。可是，首先这是在chrome下，其次大量使用真的好吗？

其实就算是在chrome下GPU也未必能排上用场，首先需要确定你的GPU驱动程序不在chromium的黑名单中。因为某些GPU驱动程序存在错误，可能会影响浏览器稳定，所以会被加入到黑名单里。在chrome地址栏里输入 about:gpu 可以查看相关的GPU信息。

现在再说说GPU加速的事情吧，简单点解释就是通过GPU渲染的Layer，GPU会将图层信息缓存起来，到下次改变的时候就只需要重新渲染修改过的部分。这样固然是快，但是会加大系统RAM和GPU的内存开销。在配置参差不齐的移动设备上，过多的层不仅不能加速，反而会严重影响性能。很多时候我们在感觉到移动网页较卡的时候不防试试减少页面上的 Layer 试试。

通过 Chrome 我们还可以鉴别一些其他影响性能的方面。比如：

上面两幅图，左边一幅是百度.新闻的移动网页版，箭头指向的是这个页面的loading效果（就是一种一直一直转动的感觉）。右边是以前最常用的一种loading。在效果上两种方式都一样，一直不停的转动。而区别在于右边的loading是一个带有背景图片的div，通过css3使其产生转动效果；而右边则是一张Gif动态图片。

虽然效果上一样，但在浏览其中我们可以看到右边的loading会有一个不停闪动的绿色框（频率相当高）。gif动画会导致浏览器不断的进行绘制、栅格化、合成，整个过程相当影响性能，所以最好干掉它。

简而言之言而简之：

布局

• 1、减少重绘，减小重绘面积（改良布局，创建独立的Layer），降低重绘频率。
• 2、合理使用GPU加速，避免过度依赖GPU而导致性能下降。

动画

说完布局，再简单谈谈动画吧。

常用的JavaScript动画在移动web上很多时候都显得心有余而力不足（不给力啊）。这个原因很多，JavaScript动画通常是通过定时改变元素样式属性的方式来实现，JavaScript的运行是在一个独立线程里完成的，作为单线程程序，JavaScript会因为某个耗时动作而影响下一帧动画的执行。而且，JavaScript的定时也并没有想象中的那么守时，如在setinterval中设置每毫秒输出一个数，当输出到2000次的时候，当真就只需要2秒钟吗？相比之下更加推荐使用CSS3来完成相关动画效果。

首先Css由独立线程完成，它和JavaScript的运行并不冲突，其次Css3很多属性不会触发重绘（当然JavaScript里也可以是改变的css3的属性）。

从流畅度上来讲的话Css3基本上完胜JavaScript，而且操作较容易。关于Css3相关知识就不再赘述。

然而Css3的动画也并没有想象中那般完美。

• 首先，在动画控制上不够灵活，整动画过程不太好监控。
• 其次，其兼容性不太好。仅移动端而言，位移动画通常使用transform，但在某些浏览器中需要使用-webkit-transform（如微信里的浏览器）。

虽然Css3并非完美解决方案，但实际使用中大多数时候是完全可以解决我们所遇到的问题 （遇到复杂问题再解决吧，事在人为嘛，解决问题也是一种乐趣）。 且目前的移动应用上并不推荐过于复杂的效果设计。