UC 开发者调试工具及使用

6.2 Control详解

Control中支持两种录制操作：录制网页交互和录制网页加载。为了便于分析，录制的时间不宜太长, 尽量避免不必要的交互操作。在录制之前点击Controls中的Screenshots复选框，可以在录制过程中捕获截屏，鼠标在Overview上移动则可以看到录制的动画。勾选Memory复选框, 可捕获Memory信息。 下图中红框区域是勾选Screenshots生成的, 篮框区域是勾选Memory生成的。

6.3 Overvie详解

通过鼠标或者区域边界上的灰色滑块来拖出一个指定区域范围，Flame Chart会跟着局部放大显示指定区域内的详情信息. 也可疑通过键盘上的W/S来放大/缩小指定区域，通过A/D来向左/向右移动指定区域。该区域包括三个图表:

• FPS  每秒帧数(Frames Per Second), 绿色柱状条越高，则每秒帧数越高, 出现的红色块表明这是一个长帧。
• CPU  标记CPU资源的使用情况，不同颜色的面积图表明不同事件消耗的CPU资源。其中蓝色代表HTML文件；黄色代表脚本文件；紫色代表样式文件；绿色代表媒体文件；灰色代表其它杂项文件。
• NET  标记请求资源耗时详情, 各种颜色的柱状条分别显示一种资源。柱状条越长，代表获取这个资源的时间越长。 其中较亮部分表示等待时间（当资源被请求时，直到第一个字节被下载的时间)；较暗的部分表示传输时间(在第一个和最后一个字节被下载之间的时间)。

对于NET图表, 点击具体资源, 在Panel左下角, 会显示加载该资源的概述。

UC支持在Timeline中标记size过大的资源, 具体表现为: UC对不同类型资源size设定了一个阈值(根据经验值), 当资源size超过阈值时, 自动在右上角添加红色三角形提示, 点击被红色三角形标记的资源, 在panel的左下角, 会显示对资源size的建议(下图蓝色框所示)。

UC开发者工具会根据实际情况调整阈值, 下图是目前不同资源的阈值。

6.4 Flame Chart详解

Chrome官方在Flame Char中标记了三条不同颜色的虚竖线。其中蓝色标记DOMContentLoaded event；绿色标记First Paint的时间点；红色代表load event； UC支持在Timeline中标记T2, 具体表现为: 在First T2时间点增加一条黑色的虚竖线(下图红色框圈出)。 T2标记线配合Overview里边的NET图表, 更直观地展示T2前加载的资源是否合理, 不合理的具体原因。

Timeline更多请参考官方文档,  想详细了解UC对Timeline的优化, 请参考文档 xxx(待补充)。

7. Profiles

在Profiles中可以追踪网页程序的内存泄漏问题，进一步提升程序的JavaScript执行性能。主要包括以下功能:

• Record JavaScript CPU Profile  显示网页中执行JavaScript函数耗时的位置。
• Take Heap Snapshot 显示网页中JS对象和相关的DOM节点的内存分布情况。
• Record Allocation Profile 从JS函数角度记录内存的分配信息。
• Record Allocation Timeline 从Heap角度记录内存的分配信息的时间轴信息，利用这个可以实现隔离内存泄漏问题。

7.1 Record JavaScript CPU Profile简介

选择Record JavaScript CPU Profile，点击Start，结合所要分析的具体场景(比如重新加载网页, 在网页上进行交互, 或者不操作)，最后点击Stop，完成记录操作。提供三种不同的视图供分析：

• Chart 按时间先后顺序显示。
• Heavy(Bottom Up) 根据对性能的消耗影响列出所有的函数，并可以查看该函数的调用路径。
• Tree(Top Down) 从调用栈的顶端（最初调用的位置）开始，显示调用结构的总体的树状图情况。

接下来以Chart视图为例分析下JS的性能. Chart视图以时间顺序展示CPU的性能情况，视图主要分成两块：

• Overview 录制结果的鸟瞰图，柱形条的高度对应调用堆栈的深度，即柱形条越高，调用堆栈越深。
• Call Stacks 函数调用堆栈图, 横轴表示时间，纵轴表示调用栈(自上而下地表示函数调用情况, 即上面的函数调用在它下面的函数)。

在Call Stacks区域, 鼠标移到函数上会显示函数名称和执行时间等相关数据，具体提供的信息有：

• Name 函数名称。
• Self time 本次调用函数运行的时间，仅包含该函数本身的运行时间，不包含它调用的子函数的运行时间。
• Total time 本次调用函数运行的总时间，包含它调用的子函数的运行时间。
• URL 函数在文件中的位置，其格式为file.js:100，表示函数在file.js文件的第100行。
• Aggregated self time 本次录制中函数调用运行的总时间，不包含它所调用的子函数的时间。
• Aggregated total time 本次录制中所有的函数调用运行的总时间，包含它所调用的子函数的时间。

更多使用请参考官方文档。

8. Application

Application记录网站加载的所有资源信息，包括存储数据（Local Storage、Session Storage、IndexedDB、Web SQL、Cookies）、缓存数据、字体、图片、脚本、样式表等。主要4大块窗格(Pane):

• Clear storage: 用于快速清除页面存储的数据,主要是storage和cache。
• Storage: 显示当前页面所有的storage数据。
• Cache: 显示当前页面的cache。
• Frames: 将页面上的资源按frame类别进行组织显示。

选中资源,右键即弹出四个选项,点击第一个”Reveal in Network Panel”, 即跳转到Network中。

9. Security

Security用于调试当前网页的安全和认证等问题, 并确保网站正确地实现HTTPS。如果网页是安全的，则会显示这样一条消息：This page is secure (valid HTTPS).。

但是，Chrome57版本该功能不完整, 不能正确检测网页是否安全, UC目前也存在这个问题, 检测结果如下图

同样, 各链接中给的证书也无法打开(对比Chrome高版本可以打开)。

10. Audits

Audits对当前网页进行网络利用情况、网页性能方面的诊断，并给出一些优化建议。强烈推荐使用UC适配的Lighthouse Lighthouse Lighthouse(x3 重要事情说三遍)。

选中Network Utilization、Web Page Performance，点击Run按钮，将会对当前页面进行网络利用率和页面的性能优化作出诊断，并给出相应的优化建议, 比如列出所有没有用到的CSS文件等。

11. Lighthouse

在 Lighthouse 之前，一般基于 Performance API 以及 Devtools 来做页面性的能监控和优化。Performance API 给出的是页面加载过程的关键时刻数据，如 Time to First Byte(TTFB)、Fist Meaninful Paint 等指标，这些数据很有用，但不足以反映页面的整体情况及用户的真实感受。Devtools 功能很强大，但对于使用者的专业素养要求较高，而且每次都要人肉去分析（当然，对于特定问题，人肉分析还是无法避免），对于一些常用的有规律可循的检测无法沉淀。 Lighthouse 的出现一定程度上解决了 Performance AP 指标单一、 Devtools 难以驾驭的问题。使用 Lighthouse，除了在性能优化的道路上能走得更远，在最佳实践、SEO、Accessibility、PWA 以及扩展业务指标也大有可为。

UC lighthouse 除了 fork 了官方代码，也适配了 U4 内核，同时也提供了业务扩展能力, 目前包括但不限于提供加载性能、滚动性能、渲染性能等检测, 目前可执行的案例有：

• Chrome cases（chrome原生)
• uc default cases
• load performance
• rendering
• memory analyze

11.1 执行用例

点击界面左上角的”+” 或者点击界面中间的”Perform an audit”按钮（如下图）,进入案例选择。

勾选用例（单选），点击”Run audit”，即可执行案例。

11.2 Chrome cases

UC Lighthouse将Chrome原生的多个案例归一为Chrome cases, 具体包括: PWA支持检测(Progressive Web App), 性能检测(Performance), 最佳实践检测(Best Practices)。 结果具体含义参考官方文档。

11.3 load performance

加载性能有多个检测项, 主要包括对关键指标t0t1t2, 图片压缩格式, 资源size, 资源请求, 排版渲染, Localstorage读写频率, JS执行耗时, 整体耗时, 缓存命中等维度的检测。 这些检测项的通过标准基于经验值。

11.4 rendering

渲染性能有四个检测项, 主要包括对惯性滚动性能, 图层合成复杂度, 图层合成稳定性和惯性滚动过程中发生光栅化性能的检测。 和加载性能一样, 这些检测项的的通过标准基于经验值。

ps: 想了解以上四个检测项的详情,可参考以下ATA文档 惯性滚动性能测试 https://www.atatech.org/articles/75082 光栅化性能测试 https://www.atatech.org/articles/75080 图层复杂度和稳定性 https://www.atatech.org/articles/75081

11.5 uc default cases

uc default cases案例包括最佳实践, 加载性能和渲染性能三大部分。其中加载性能同 11.3 load performance, 渲染性能同 11.4 rendering,  这里不再详述。

最佳实践只有两个检测项:

• 页面meta是否设置viewport。 通过标准是 <head>中有<meta name="viewport">标记, 此节点包含content 属性，且该属性值是包含文本width=
• 页面内容宽度是否等于视口宽度。 如果内容宽度小于或大于视口宽度，则通常表明页面没有针对移动设备屏幕进行优化。通过标准是window.innerWidth === window.outerWidth。

11.6 memory analyze

memory analyze根据经验值分析各种 RAM/ROM 下可能出现内存使用不正常的场景。各项结果的意义参考ATA文档 https://www.atatech.org/articles/93961

ps: 本章节的测试基于sina.cn 想了解UC对Lighthouse的优化, 请参考文档 xxx(待补充)。

问题与反馈

工具兼容devtools，更多使用可以参考： https://developer.chrome.com/devtools

http://plus.ucweb.com/?locale=en-us https://github.com/uc-developers/devtools/issues