跟着 Apple、Google 大佬学优化

今天在这抛个砖，分享一点我的拙见

一、初识 Performance 

打开开发者工具，点击 Performance 标签：

点击左上角的 Record 按钮开始记录，然后你模拟正常用户使用网页。测试完毕后，点击 Stop。

概览面板（overview）

1 . FPS

FPS：每秒帧数，对于动画而言标准是保持在 60FPS

☆ 优化

绿色越高越好，出现红色则表示 FPS 低（这就是你为啥觉得页面卡顿了），你可以在线程面板的Frames中看到具体的 FPS 值

2 . CPU

CPU: 处理各个任务花费的时间，选择一段 CPU 统计可以在区域四的Summary看到统计表格

☆ 优化

比重占的大的颜色可能有问题，表示耗费时间多，一般是执行脚本或渲染

3 . NET

NET：各个请求花费时间 这块可以再network里看，更清晰些

线程面板

1 . Frames

Frames：帧线程，鼠标悬浮绿色块可以看到 fps

2. Main

Main：主线程，负责执行 Javascript, 解析 HTML/CSS, 完成绘制。 可以看到主线程调用栈和耗时情况，每个长条都是一个事件，悬浮可以看到耗时和事件名

• x 轴指时间 最上面的第一条就是事件触发的地方，直到结束，这条线是最长的

• y 轴指调用栈 上面的 event 调用了下面的子 event，越到下面数量越少（瀑布

颜色代表各个事件类型，以下列出一些常见的事件

3. 其他线程

统计面板

• Summary 统计图：展示各个事件阶段耗费的时间

• Bottom-Up 排序：可以看到各个事件消耗时间排序

  self-time 指除去子事件这个事件本身消耗的时间

  total-time 这个事件从开始到结束消耗的时间（包含子事件）

• Call Tree 调用栈：Main选择一个事件，可以看到整个事件的调用栈（从最顶层到最底层，而不是只有当前事件）

• Event Log 事件日志

   多了个start time，指事件在多少毫秒开始触发的

   右边有事件描述信息

渲染面板

另外还有一个非常好用的渲染工具

二、利用 Performance 检查运行时性能

模拟移动设备的 CPU

移动设备的 CPU 一般比台式机和笔记本弱很多。当你想分析页面的时候，可以用 CPU 控制器（CPU Throttling）来模拟移动端设备 CPU。

准备开始

1. 打开 Chrome 的匿名模式。匿名模式可以保证 Chrome 在一个相对干净的环境下运行。比如说，你安装了许多 chrome 插件，这些插件可能会影响我们分析性能表现。

2. 在匿名模式下打开右边这个链接，DEMO，这个网页就是我们要用来分析的 DEMO。这个页面里都是很多上下移动的蓝色小方块。

分析并定位瓶颈

注意 Summary 面板，你会发现 CPU 花费了大量的时间在 rendering 上。

因为提高性能就是一门做减法的艺术，你的目标就是减少 rendering 的时间

展开 Main 图表，Devtools 展示了主线程运行状况。X 轴代表着时间。每个长条代表着一个 event。长条越长就代表这个 event 花费的时间越长。Y 轴代表了调用栈（call stack）。在栈里，上面的 event 调用了下面的 event。

在事件长条的右上角出，如果出现了红色小三角，说明这个事件是存在问题的，需要特别注意。

双击这个带有红色小三角的的事件。在 Summary 面板会看到详细信息。注意 reveal 这个链接，双击它会让高亮触发这个事件的 event。如果点击了 app.js:95 这个链接，就会跳转到对应的代码处。

在 app.update 这个事件的长条下方，有很多被触发的紫色长条。如果放大这些事件长条，你会看到它们每个都带有红色小三角。点击其中一个紫色事件长条，Devtools 在 Summary 面板里展示了更多关于这个事件的信息。确实，这里有很多 reflow 的警告。

在 summary 面板里点击 app.js:70 链接，Devtools 会跳转到需要优化的代码处

作业题：此处怎么优化？

三、思考

先看一下 https://www.apple.com.cn/ 的首页渲染过程：

可以看到右上角分别有 FPS、CPU、NET、HEAP：

1. FPS 对应的是帧率，红色代表帧率低，可能会降低用户体验；绿色代表帧率正常，绿色条越高，FPS 越高。

2. CPU 部分上有黄色、紫色等色块，它们的释义请看图的左下角。谁的占比高，说明 CPU 主要的时间花在哪里。

• 蓝色(Loading)：网络通信和 HTML 解析

• 黄色(Scripting)：JavaScript 执行

• 紫色(Rendering)：样式计算和布局，即重排

• 绿色(Painting)：重绘

• 灰色(other)：其它事件花费的时间

• 白色(Idle)：空闲时间

      3. HEAP 就是堆内存占用。

通过查看性能图和调用树，大家发现了什么问题没有？

假如我想让页面初始渲染的时候尽可能快的展示出来，我需要优化掉那个模块？

。。。。。。

对，没错，假如跳过脚本执行这一步，页面是不是唰的一下就出来了？

这是因为在执行脚本的过程中会去请求数据，触发动画，进而造成重排重绘等等一系列耗时的操作。

因此，我们也经常用协商缓存来提高加载速度，用 CSS 动画、requestAnimationFrame 来提高动画的流畅度，以及通过图层来避免重排重绘等等......

针对页面的初始渲染，常用的做法是使用骨架屏，小程序也提供了骨架屏，但骨架屏会等待数据加载完成，才会展示渲染好的页面。

我们都知道小程序的页面分为逻辑层和视图层，视图层需要等待逻辑层初始化完毕，才会展示出来

那有没有一种方法，让视图层不用等待逻辑层发送数据，而直接展示出来呢？

嘿嘿嘿，你还别说，还真有！

这真是巧儿她爹要打巧儿-巧极了

它就是初始渲染缓存

使用前： 

   使用后：