介绍
当前，开发 Hybrid 页面时，传统前端开发方式往往是在本地开发，通过浏览器如 Chrome 中响应式模式模拟移动设备来调试 Hybrid 页面。这种方式的问题在于：
兼容性：浏览器响应式模式通常只是修改了 UA 和模拟了移动设备视图呈现方式，但其与手机 Webview 的兼容性表现往往是不同的，因此可能出现各种 PC 浏览器中无法复现的兼容性问题，而开发人员在不借助工具的情况下无法调试页面，较难定位问题。
Native 交互：Hybrid 页面经常伴随着通过 JSBridge 与 Native 交互，PC 浏览器上即使可以提前通过 Console 等打印出交互内容，但在发布之前都无法确认交互的具体效果。
代理 Host：当开发 Hybrid 页面时，如果希望 APP 内的 Hybrid 页面可以访问测试环境，有两种方法：APP 将 APP 环境染色为测试环境，并在 Hybrid 页面请求时拦截并转发到测试环境；或者通过 Charles 等工具将手机网络请求代理到本地，走本地 Host 发起请求。前者需要 APP 接入，成本较高且可能对线上产生影响。后者学习成本相对较高，需要安装证书、配置一系列代理等操作。
本地开发项目调试：在上述方法中，想要在 APP 上访问本地开发项目，有两种方式：将本地项目发布到静态资源服务机器上；或者通过 Charles 等代理工具的 Map Local、Map Remote 等将 Hybrid 页面请求映射到本地开发项目资源。后者时间成本相对较低，但同样要求开发人员熟练使用 Chrales 等工具配置代理，学习成本相对较高。
当前较为成熟的真机调试工具主要有微信的开发者工具，能够实现从构建、调试、发布较为完善的 Work Flow。并支持在 PC 客户端上调试远程真机上的小程序，进行元素审查、Console 等操作，其基本类同于 Chrome 开发者工具的调试行为习惯，并能够将本地项目打包上传后打开小程序调试本地开发的项目，但目前暂不支持 HMR 热模块重载。
由于微信开发者工具是针对微信小程序等具有特定语法的应用开发而设计的，因此并不能够作为常规 Hybrid 页面调试工具的解决方案。
相对而言，谷歌远程调试协议 Chrome Devtools Protocol（以下简称 CDP，谷歌开发者工具协议）作为 Chrome 内置的开源调试协议，配合 Google 开源的 Chrome Devtools Frontend 调试前端（以下简称 CDF 也就是 Chrome F12 开发者工具，本质上是一个前端页面，由 Chrome 内嵌用于调试 Web 页面），可以实现跨端的基于 WebSocket 协议的 Webview 调试流程。并且鉴于 Chrome Devtools Frontend 对于前端开发人员的熟悉度与使用便利度，前端开发人员用起来会更加得心应手。
Chrome Devtools
Chrome devtools 大家普遍熟悉可以通过右键 inspector 打开控制台进行本地调试。还有一种方法就是可以通过一个浏览器调试另一个浏览器，或者通过 usb 连接手机调试手机 webView。这两种方式都属于在新启一个窗口远程调试目标页面。这个新启的窗口打开了一个 html 页面（inspector.html），它的长相与内嵌的 devtools 一样。在 inspector.html 调试目标页面就像在内嵌 devtools 里调试一样。
其官方解释是允许工具对 Chrome，Chromium 及其他基于 Blink 的浏览器进行调试、审查的协议。它划分了多个不同的功能模块（域），如 DOM, Debugger, Network, Timeline 等，每个模块以结构化 JSON 的形式都定义了一些命令和事件。