@FunC
2017-04-23T12:55:51.000000Z
字数 1867
阅读 2139
未分类
目前屏幕一般刷新率为60Hz
要在1000ms内渲染60帧，每帧要在16ms内完成渲染（但浏览器还要处理些别的任务，实际上只有10~12ms可供渲染）
构建DOM和CSSOM
↓
非视觉元素不出现在render Tree，如meta，head等标签，display:none的元素
注意：height：0、position：absolute;left：99999px;的元素仍会出现在render tree
↓
关于layout，其实有其作用域（layout scope）。大部分情况下尽管只改变app的一小部分，还是会触发整个页面的reflow，意味着上千个节点受到影响。
想拥有layout boundary（布局边界），需满足以下条件：
- 根标签为.
- 的文本或搜索域.
或者- display不为 inline 或 inline-block
- 不含有百分比高度
- 不含有隐式的或值为auto的宽高
- overflow有显式的值(即scroll, auto 或 hidden).
- 不是的子元素.
↓
从矢量数据（vector）转换成栅格化数据（raster）(即填充到像素格子里)（Paint）
绘制位图（draw Bitmap）（浏览器解析图片数据并进行缩放：Image Decode+Resize）
↓
（处理图层部分为：composite layers）
单独绘制的图层（layers）（在CPU上发生）
发送图层和图像块给GPU，让其合成并展示
↓
layout很复杂，一般假设layout scope为整个DOM
js/css animation/web animation api > style > layout > paint > composite
用js和css触发上述管道不一定每一次都完整走完，三种情况
1. 改变了layout相关属性（如width），则全部触发
2. 仅改变了paint相关属性（background-color），不触发layout
3. 仅改变图层相关属性，不触发layout和paint
注意，三种情况中style每次都会进行计算，因为改变了style（即样式属性发生了变化）
区别：使用flexbox时，resize不用重新计算style，因为style属性没有变化
区别2：如果有resize handler触发style变化，或者触发media query使style变化，都要进行style计算
到csstrigeer.com查看那些元素会触发layout、paint和composite，尽可能选择耗能低的
不总需要保持60fps（如更改颜色方案、有滑入/滑出动画时）
网络应用的生命周期四阶段：RAIL（便于记忆、实际顺序是LIAR）
R：Response | 100ms
A：Animation | 16ms/帧（实际10~12ms）
I：Idle（闲置）| 50ms
L：Load | 1s
加载（Load）完后，一般处于闲置（Idle）状态，等待用户去互动（Interact），此时是执行要推迟（defer）的任务的绝佳时间，从而达到1s加载完毕的感觉。
通常闲置时间为50ms
以新闻app的文章页面为例（有文本，图片，视频，评论区）
因核心目的为阅读新闻，所以文本必须先加载（用户会花时间阅读文本，留出idle时间）
闲置时间适宜加载的内容：image、videos、comments section等，
不适宜加载的内容：文本和基础且必要的功能
对用户的操作作出反应
1. 简单的：点击按钮
2. 复杂的：会触发动画的（因为要求16ms/帧）
原理：一旦浏览器完成了性能消耗高的动画，逆向进行将变得简单。看起来高耗时的计算位置工作在click到animation begin之间的100ms（response可接受时间）内完成（实际能满足）
先计算一开始的位置（First），可使用getBoundingClientRect()；计算最后的位置，应用动画（配合opacity，因为性能优秀）
菊花图是否应该在触发视频时发起请求？
答案：否，可能超过16ms。即使不超过16ms，额外的时间也会拖长这一帧使其超过16ms。
在idle时可加载的内容
答：非首屏内容都可尝试进行加载（包裹FLIP的计算）
尽管有一定的时间可以用于计算，但注意时间不是无限的。减少影响的元素的数量有助于优化计算时间