前言

前端在进行性能优化时，涉及到内核往往就会束手无策，常常感叹内核就是一个令人讨厌的黑魔盒，不知装了什么东西，也不知道页面在里面做了什么，页面显示时间就是耗费几秒钟，优化无从下手。如果有工具帮助定位页面每一个细节耗费时间，那么定位问题优化性能则事半功倍。 本文介绍前端性能分析最强大的工具-Trace，带开发者一起来了解如何借助该工具优化自己的业务。

Trace原理

Trace的原理并不复杂，它最本质的是日志，一般包括生成日志和使用日志两部分。

• 生成日志，是在内核各个函数进行打点，Trace数据格式请参考：Trace Event Format。
• 使用日志，是在devtools的Trace，Timeline，Lighthouse，等工具中，利用生成的Trace日志进行统计分析，比如，可以计算内核某个函数的调用次数和执行耗时。 Trace可以深入到内核函数的级别，它在页面性能分析方面是非常有效果的。

PC Chrome Trace调试

PC Chrome的Trace使用方法非常简单，步骤如下，

1. 启动PC Chrome浏览器，新建一个窗口并在地址栏输入chrome://tracing
2. Record → Javascript and rendering → Edit categories → select v8.execute and v8.compile → Record
3. 新建另外一个窗口，访问页面，例如：https://pages.test.com/xxxxxxx
4. 页面首屏展现完成，点击 Stop 停止记录，生成Trace文件，可以分析具体的函数执行情况。 细节请参考下面视频：

手机Trace调试

PC与手机的性能差异非常大，我们在开发手机端应用时，一定要使用手机去进行测试。需要注意的是，调试页面一定要使用开发者版本的应用。出于控制应用尺寸的原因，一般应用默认都不会带有Trace功能。 手机Trace的调试方法：

1. 【手机端】手机通过USB数据线连上PC（比如，Mac Pro）。
2. 【PC端】打开PC Chrome浏览器，新建一个窗口并在地址栏输入chrome://inspect/?trace
3. 【PC端】Record → Javascript and rendering → Edit categories → select v8.execute and v8.compile → Record
4. 【手机端】应用中加载待测试的页面。例如：https://pages.test.com/xxxxxxx
5. 【手机端】页面首屏展现完成。【PC端】点击 Stop 停止记录，生成Trace文件，可以分析具体的函数执行情况，比如，v8.run 代表JS执行耗时，下面视频中aplus_wap.js执行耗时162.364ms。 细节请参考下面视频：

手机Timeline调试

Trace一般用于宏观分析，分析页面耗时特别严重的模块，而Timeline更适合分析耗时的细节，比如，找出某个比较耗时的JS函数调用。 手机Timeline的调试方法： 1.【手机端】手机通过USB数据线连上PC（比如，Mac Pro）。 2.【手机端】应用中加载待测试的页面。例如：https://pages.test.com/xxxxxxx 3.【PC端】打开PC Chrome浏览器，新建一个窗口并在地址栏输入，chrome://inspect 4.【PC端】点击 Inspect 进入Remote Inspect调试界面。 5.【PC端】在 Timeline 的界面，点击 刷新 按钮，开始记录Timeline信息（注：不要勾选 Screenshots，否则可能会由于占用内存过多而导致应用崩溃）。 6.【PC端】等待完成，它会生成Timeline信息。（注：也可以自行点击 Stop 停止记录） 7.【PC端】在 Call Tree 界面，可以分析具体函数的耗时，比如，视频中的 startsWith／endsWith。 细节请参考下面视频：

Trace分析 - 页面整体性能

前面介绍了Trace和Timeline工具的基本使用方法，下面会继续介绍如何使用这些工具去分析页面的性能。 在分析页面性能时，我们一般需要先观察页面性能的整体情况，快速找出性能消耗的瓶颈。 上面是某应用页面的Trace信息，从整体来看，有非常多的JS在执行，而在最开始的阶段，有一个index-adf020bc01.js 执行耗时超过1.8秒， 很明显，它是在页面首屏（T2）主路径上执行的，它就是页面性能的瓶颈。

Trace分析 - 加载性能

我们下面从各个维度去说明Trace的实际应用，我们先看看资源加载的情况。 在看资源加载时，Edit categories 选择Trace日志类别时，需要选上 network。 从下面的视频我们可以看到，主文档的加载耗时496.133 ms，也就是说，如果这个文档资源能进zcache，或者能提前预加载，则可节省400多ms。 细节请参考下面视频：

Trace分析 - 排版性能

页面排版性能，一般是看HTMLDocumentParser::processTokenized，但排版本身的性能，基本没有太大的优化空间。 我们更需要检查的是，排版的内容是否合理，排版出现的时机是否合适。比如，下面的Trace中，JS执行的过程中，内核大部分时间在解析样式表（processStyleSheet），进行样式重计算，甚至是重排版。很明显，JS频繁修改样式表是这个页面排版性能问题的根源。

Trace分析 - 渲染性能

页面渲染性能分析，我们通常会看具体的资源或图片的渲染效率，但是，事实上这些意义并不大，渲染引擎的效率优化可不是简单的事情。 在分析页面渲染性能时，更关键的是，判断某个资源该不该在首屏被渲染，或者某些逻辑是否应该在首屏执行。那么，怎么在Trace上区分首屏和非首屏逻辑呢？很不幸，首屏和非首屏是没有非常清晰的界线的，甚至在目前的Trace根本就看不出来。但也不是毫无办法，一些可以尝试的思路， （1）在Timeline中勾选Screenshots，观察Timeline的截图，能大概分辨出首屏的位置。 注1：手机上勾选Screenshots，可能会由于占用内存过多而导致应用崩溃，所以只能在PC上测试。 注2: 勾选Screenshots，CPU和内存占用非常大，会很大程度上影响页面的性能，会间接影响分析结果的准确性。 （2）Chrome在高版本的Trace中，已绘制出FirstContentfulPaint和FirstMeaningfulPaint时间点的线，U4内核也可以将T2时间点的线绘制出来。 （3）U4内核将渲染帧的过程输出到Trace日志，开发者根据Trace信息确定T2时间点。 比如，下面视频中，我们可以看到，Frame_count:5, pixel_area:706320, max_pixel_area_:706320，即Frame个数为5的时候，渲染图片的面积为706320，检查完所有帧之后，我们发现页面首屏图片的最大面积也是706320，也就是说，Frame个数为5的时间点就是T2时间点，在此之后的JS执行就属于非首屏逻辑了，不会影响首屏渲染（注：如果要定位到查找的位置（比如，Frame_count:5），可以在空白地方点击一下，然后键盘输入 M，这样Trace界面就会在定位位置绘制出一条线）。 细节请参考下面视频：

Trace分析 - JS执行性能

现在前端渲染非常流行，页面的大部分逻辑都会由JS去完成，JS性能很大程度上决定了页面的实际性能。 那么，怎么去分析JS性能呢？一般来说，有几点是需要关注的。 1.JS解析编译耗时 2.JS对应的业务逻辑 3.JS具体函数执行耗时 在JS具体函数执行方面，一般会使用Timeline工具，当然，v8专用的调试工具，比如D8之类，可以看到更多细节。

后续

希望开发者在读完本文后能对Trace工具的使用以及如何借助该工具对自己业务进行优化有个初步认识。我们U4内核也在打造自己的性能测试平台-鲁班尺，这个平台最终的目标是开发者在平台上运行一次自己的业务后，平台就会给出优化页面的方案，敬请关注。