阅读 188

Chrome 80 开发者工具新特性

  • **本文参考自:**What's New In DevTools (Chrome 80)

  • developers.google.com/web/updates…

  • **注意:**新特性都是先在 Chrome 的 Canary、Beta 通道中发布的,要想第一时间体验新特性,请下载 Canary 或 Beta 通道版本的 Chrome。

  • 新特性一:Console 开始支持 let、class 的重复声明

    • 我们都知道 js 语法规定了 let、const、class 声明的变量是不能在同一个作用域层级下做重复声明的,否则会报语法错误;所以,在以前的 Chrome 中,Console 下是不支持 let 的重复声明的,但为了便于开发人员调试,在本次版本更新后,我们将可以在 Console 中对 let 和 class 做重复声明了( 还不支持 const 的重复声明),如下图:

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d86240d59d3?w=1208&h=744&f=png&s=206676)
    • **注意:**Console 允许重复声明,只是为了便于开发人员调试,并不代码这符合 JS 语法。

  • 新特性二:优化了 WebAssembly 的调试

    • 在此之前的 Chrome 版本中,开发者工具的对 WebAssembly 的调试支持度还非常不足——只支持查看文本形式的字节码、粗糙的调用栈信息,以及指令级调试,仅有的改善也只是通过利用现有的 source-mapping 格式把字节码映射成简单的 JS,而非编译前的语言;为了改善这种状况,本次 Chrome 开发者工具开始支持 DWARF 调试标准,支持在源码格式下进行断点设置、逐行调试、解析调用栈信息。
    • 相关链接
  • 新特性三:Network 面板下的 Initiator 标签中新增 initiator 链信息

    • 在上个版本(Chrome 79)中,Chrome 为每个请求的资源新增了一个 Initiator 标签,以便于更好的查看 initiator 调用栈;而这次,Chrome 又在这个新增的标签下新增了 initiator chain (发起链)信息,如下图:

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d863aea56b6?w=1680&h=862&f=png&s=356103)
    • 其中

      • 1. 粗体灰色背景的节点,表示的就是当前你所查看的资源
      • 2. 在其之上的节点表示的就是当前资源的发起链,上图中,当前资源就是在 bootstrap.js 中所发起的,而 bootstrap.js 又是在 web.dev 网页上发起的。
      • 3. 而在其之下的节点,则是由当前资源所发起的发起链
    • 另外,我们还可以按住 Shift 键,然后将光标移动到资源上,以此查看该资源的发起链,如下图:

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d863db21b0a?w=1494&h=1061&f=png&s=238593)
    • 其中,绿色背景的为发起当前资源的上有链,红色背景的为当前资源的下游链。

  • 新特性四:Network 面板下选中的资源,将会在时间线上同步高亮

    • 如图

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d86601656d2?w=1540&h=896&f=png&s=342424)
  • 新特性五:Network 面板新增 Path、URL 列

    • 默认情况,此两列不会展示,需要右击表头,然后勾选 Path、URL 才会展示

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d86b38cef58?w=1906&h=872&f=png&s=505669)
  • 新特性六:更新了预设的 User-Agent 字符串集,以此覆盖当前浏览器市场情况

    • 还不知道如何设置 User-Agent 字符串的,请看下图:

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d878581935d?w=1184&h=1008&f=png&s=258609)
  • 新特性七:全面改版了 Audits 面板的配置界面

    • Chrome 在本次更新中,调整了 Audits 的启动界面,采用了响应式的设计,并简化了 Throtting 配置项,新旧界面对比如下:

    • 旧界面

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d86b705b068?w=1976&h=1288&f=png&s=235668)
    • 新界面

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d86b04e6b28?w=1814&h=910&f=png&s=303113)
    • 注意: 在新界面中,Throtting(编注:节阀,用于控制网速和CPU性能)设置项转移到了右上角的齿轮菜单下,并缩减成了只有一项,即“Simulated Slow 4G, 4x CPU Slowdown”,取消了旧版的另外两个选项。

      • 取消的原因:
      • 1. 取消“No Throtting”(不设节阀),是因为该选项下得出的结果其实并不能代表实际情况,会出现误导性结果。
      • 2. 取消“Applied Slow 4G, 4x CPU slowdown”,是为了简化 Throtting 设置项——没有勾选“Simulated Slow 4G, 4x CPU slowdown”,就代表采用“Applied Slow 4G, 4x CPU slowdown”
        • 3. 鉴于有些小伙伴还不知道 “Simulated....” 和 “Applied....”这两个选项之间的区别,编者在此讲解下:Simulated (模拟)选项得出的结果,是通过内置模型对在全速网络/CPU下得出的结果进行计算,而模拟出来的结果,所以这种结果得出的速度会比较快,但其实也并不完全可靠;而 Applied 选项得出的结果则是真实通过在网络请求层面做节阀控制所得出的结果,其得出的速度会比较慢。要想得出更接近现实的结果,我们应该采用更加底层的节阀控制,对于节阀控制,行业中做了层级划分:最高层级就是我们提到的 Simulated 选项;第二层级则是网络请求层面的控制,即 Applied 选项(Request-level);第三层级则是网络代理层面的节阀(Proxy-level);最低层级也是最接近现实的层级,则是网络数据包层面的节阀控制(Packet-level)。
  • 新特性八:代码覆盖率支持代码块级别的测量

    • 在此版本之前,代码覆盖率(Coverage 小标签)都是按函数来进行测量的,即其细粒度只精确到了函数级别(per-function),且只要一个函数中有一行未被执着的代码,整个函数就会被视为未被用到,所以会导致结果并不准确——实际上被执行的代码量会比测量结果更高;为解决此问题,本版本的 Chrome 开发者工具,开始支持代码块级别的测量(per-block),但由于代码块级别的测量会更耗费资源,Chrome 保留了函数级别的测量,提供给了用户一个新的选项,以此选择测量级别,如下图:

      ![](https://user-gold-cdn.xitu.io/2020/1/27/16fe6d86d61890ba?w=1404&h=1106&f=png&s=352921)
    • **注意:**html 中的内联JS 与单独引入的 JS 文件的情况不一样,如果你采用的是函数级别的测量,chrome 会把内联代码视为一个整体,只要内联代码被执行了哪怕一行,整个内联块都会被视为“被使用过”。

  • 往期文档