Hugohua，荔枝 2014-01-07 移动端性能调优

• 浏览器的工作原理 • 调试 • 优化 • Css • js • 其他 移动端性能调优

浏览器的工作原理 1. 减少步骤 2. 解析（html，css） 3. 渲染

减少执行步骤 当我们仅仅更改了color，visibility等属性，会重新执行以 上部分。

减少执行步骤 当我们更改了dom的大小和位置，就会重新执行以上部分。

解析渲染 DOM Tree：HTML解析器，解析算法，树构建算法，容错。 Style Rules：css解析器，选择器匹配，样式计算。 构建呈现树 然后 重新布局 最后 渲染到屏幕。 tips • 减少css层级 • 选择器尽量用class • 简写，精简代码 • 遵循编码规范，减少容错

通过调试，展现webapp的真面目

调试  Weinre.qq.com  Fiddler  Android: Chrome+ADB plugin  iOS: Mac+ Safari +iphone

Chrome 和 safari 开发这工具 Ios： http://atnan.com/blog/2011/11/17/enabling-remote-debugging-via-private-apis-in-mobile-safari/ Android： https://developers.google.com/chrome-developer-tools/docs/remote-debugging

Chrome ADB plugin ① Chrome开启“Enable Developer Tools experiments” ② Crhome安装ADB插件 ③ 手机连接电脑，并开启“ USB调试” ④ 访问chrome://inspect即可调试 ⑤ 在插件“ setting”设置转发端口可映射本地电脑文件

iOS ① Iphone连接Mac，打开 Mac 和 Iphone中的 Safari . ② 在iphone的 “设置”里，找到safari，开启“ web检查器” ，并退出 隐身浏览模式。 ③ 找到 Safari 的“ Develop 开发”菜单，第一个菜单分隔线的后面应 该是你要连接的 IOS 设备的名字。在子菜单选择你想调试的页面。

16ms 60FPS

• 显示设备通常的刷新率通常是50~60Hz • 60 fps是所有的iOS的内置动画运行的速度 • 1000ms / 60 ≈16.67ms

No content

Timeline 加载(Receive Data) 加载完成(Finish Loading(文件)) 脚本事件 重新计算样式(Recalculate Style) 计算布局(layout) 绘制(paint Setup/Paint(sizexsize)) 合成(Composite Layers) Web渲染过程：计算应用到DOM元素的新样式（重新计算），生成几何形状（box盒模型） 与为每个元素定位（layout布局），然后为每个元素填充像素插入layers(Paint setup and paint 绘制设置与绘制)，最后把layers输出到屏幕（Composite layers 合成层）。 注：在firefox中，Layout的过程叫reflow，Painting过程叫repaint 实例

profiling

样式和页面渲染优化 • 测试方案chrome • css引发浏览器某些行为 • 触发条件和渲染优化 • 其他样式瓶颈

测试方案 实例

 改变一个元素，可能会导致该元素及其子元素重新计算  若元素的溢出影响到其他元素，则发生连带反应，所有相临近、相关联的Dom树都会重新计算  Dom树越大，结构越复杂，所花费的layout布局时间会越长 优化策略：尽量避免触发layout

CSS行为表

触发条件 重新计算样式 •style ="" •className= "" •classList.add() •clasList.remove() •appendChild() 布局渲染 •display •Float •Position •scrollTop() •Offset() •clientLeft() * 更多触发条件可查看文章：How (not) to trigger a layout in WebKit

渲染优化 • 避免在document上直接进行频繁的DOM操作 • 使用classname代替内联修改样式 • 缓存Layout属性值 • 设置元素的position为absolute或fixed • 读写分离,批量操作 • 不要在css里面写expression • 不要在16ms内发生多次渲染行为

避免在document上直接进行频繁的DOM操作 • 先将元素从document中删除，完成修改后再把元素放回原来的位置 • 将元素的display设置为“none”，完成修改后再把display修改为原 来的值 • 如果需要创建多个DOM节点，可以使用DocumentFragment创建 完后一次性的加入document

使用classname代替内联修改样式

设置元素的position为absolute或fixed 将元素脱离文档流，避免发生渲染树的连带 渲染行为。

不要在css里面写expression css里有expression，每次都会重新计算一遍

缓存Layout属性值

读写分离,批量操作

不要在16ms内发生多次渲染行为 • 在touchmove、mouseover、scroll、resize等高频率事 件中使用requestAnimationFram保证事件在正确的时间 进行渲染 • 注意函数节流

No content

CSS属性性能 • 不同CSS属性，性能不一样 • 同一CSS属性，但不同的值，性能也不一样 • 不同CSS属性组合，CSS性能也不一样

最耗性能的CSS属性 1. transform 2. Positon:fixed 3. background-position: fixed 4. border-radius 5. background-size 6. box-shadow 7. gradients

滚动卡顿 页面加载并渲染完毕，为什么滚动页面还会 卡顿？ 重绘是一个阻塞操作！

滚动渲染原理 ① 浏览器查看带样式的DOM树，找出滚动时它认为看起来是一样的元素。 ② 这些元素组合在一起，并且为它们生成一张图片，即合成“层”。 ③ 每一层需要被绘制和栅格化为一种结构，然后合成在一起。 ④ 滚动页面时，浏览器可能会需要绘制这些层（有时也被称为合成层）里的一些像素。 ⑤ 通过元素分组，当某个层的内容改变时，我们只需要更新该层的结构，并仅仅重绘和 栅格化渲染层结构里变化的那一部分。 优化方向：滚动时减少绘制！

优化策略 • 银弹：requestAnimationFrame • 绝对定位 • 开启GPU加速: -webkit-transform :translateZ(0) • Canvas • 禁止图像缩放（使用实际大小的图片非常重要） • 根据实际页面情况慎用耗性能的CSS属性

JS性能优化实例 1. 帧 2. 强制布局 3. 高性能的拖动 和 3d加速对性能的影响

帧 和 requestAnimationFrame 实例 • 帧没有被充分使用，出现跳帧。 • requestAnimationFrame是根据网 页渲染帧率来设计的，就是为了更好 的渲染动画。 • Settimeout则是根据浏览器cpu空闲 时间来将事件加入队列。

强制触发layout 实例 • offsetTop属性需要计算整个dom文 档中的布局才能得到自身的offset-x 的值。 • 强制布局引起的多次计算，但是没 有渲染到屏幕上，资源浪费。

高性能的拖动 实例 做了三种方案来实现这个拖动 1. Position 2. Transform 3. 3d加速

高性能的拖动 position 实例 上图是更改left和top的值来拖动弹框的timeline记录。 问题：不停触发layout，由于页面有很多dom，所以特别耗时。

高性能的拖动 Transform 实例 虽然比起position的拖动，没有的layout，但是还是会重新渲染到屏幕 上，依然会有额外的开销。

有没有可能只让弹出框绘制，背景不变呢？ 像ps图层一样

高性能的拖动 transform3D 实例 近乎完美的图层合并，和36.6ms的帧率。

实例 性能的差别就在这三种实现上 影响性能的当然不止这些，还有 • 用requestAnimationFrame 来优化拖动的动画，将计算和渲染分开。 • 及时释放无用的事件绑定 • 减少内存回收

实例 自从有了3d加速，再也不用 担心动画会卡了！ 真的吗？

3d越多越好？ 多了也会卡，因为每次拖动需要合并图层。耗时都在这。

3d加速的原理 GPU GPU 计算就是运用 GPU (图形处理器) 搭配 CPU 来加速通用科学和工程应用程序。

通过GPU的绘制优化 • 减少重绘，速度优化。 • GPU会创建独立的线程，但同时会消耗更 多的内存 • 导致cpu响应迟缓等

根据GPU，程序可分为两种 • 图形密集型（GPU bound） 透明 • 计算密集型（CPU bound） 灰色 影响因素：3d加速的元素 多少和层的大小 测试方式：可以通过缩小 浏览器大小

最后 • 避免过度优化，损害用户体验。 • 优化策略依赖于环境和实际需求 • 通过Chrome开发者工具测量和了解你的样式所 带来的影响

参考 • google官方：https://developers.google.com/chrome-developer-tools/docs • 为什么web应用程序很慢：http://www.cnblogs.com/codemood/p/3213459.html • 图形图像：http://blogs.msdn.com/b/shawnhar/ • 性能杀手：http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/ • 16毫秒性能优化：http://velocity.oreilly.com.cn/2013/index.php?func=session&id=14 • 60fps layout and rendering: https://docs.google.com/presentation/d/1CH8ifryioHDLT1Oryyy8amusUmq2FytpCPCp k0G3E4o/edit#slide=id.p • 开发基于web技术的高性能动画: http://www.gbtags.com/gb/share/2498.htm • Chrome DevTools Revolutions 2013: http://www.html5rocks.com/en/tutorials/develop ertools/revolutions2013/ • Gone In 60 Frames Per Second A Pinterest Paint Performance Case Study: http://www.smashingmagazine.com/2013/06/10/pinterest-paint-performance-case- study/

Thanks！