引言：
在现代Web开发中，能够实时调试和监控应用程序已经成为了开发者日常工作的一部分。针对那些需求复杂、跨平台、并且必须随时保证高可用性的Web应用，一个高效、稳定的远程调试工具至关重要。在这篇文章里，我们将详细介绍CDP的概念以及其devtools的工作原理，同时介绍一个devtools的扩展chii并展示它是如何实现的。让我们从基本概念开始，逐步深入了解这一有用的工具。
一 、CDP介绍
Chrome DevTools Protocol（CDP）在调试网页和DevTools之间的交流过程中扮演了数据通信协议的角色。CDP定义了一套用于与Chrome的各种内部组件通信的底层命令和事件集合，这些组件包括但不限于：渲染、布局、JavaScript执行环境等。
具体到CDP的定位和作用：
- 定位：CDP位于DevTools前端与浏览器的后端（也就是渲染进程、网络栈等）之间，作为两者交互的桥梁。
- 作用：
- 命令执行：通过CDP，DevTools可以执行各种命令，比如检查和修改DOM元素、监控和修改CSS样式、调试JavaScript代码、启动/停止性能记录等。
- 事件监听：CDP允许DevTools订阅内部事件，例如监听网络请求、DOM变化、JavaScript执行异常等事件。当这些事件发生时，它们将通过CDP传递给DevTools。
- 信息获取：通过CDP，DevTools可以查询浏览器内部状态，例如获取当前页面加载状态、捕获页面截图、获取性能数据等。
操作过程基本上是：当您进行某项操作时，比如点击DevTools中的“Elements”面板来检查页面元素，DevTools会通过CDP向浏览器发送一个命令，请求DOM树信息。浏览器接收到这个命令后，通过渲染进程查询具体的DOM信息，并将结果返回给DevTools，DevTools前端再将这些信息可视化呈现给开发者。
交换数据时的底层传输机制可能是IPC（适用于本地调试）或WebSocket（适用于远程调试），但无论具体使用哪种传输方式，CDP充当的角色和其功能不变。简言之，CDP提供了一种标准化的方式，让开发者能够以编程方式与Chrome浏览器互动，从而使自动化测试、远程调试等复杂的任务成为可能。
哪如果我们想实际给浏览器发送一个DCP命令该如何实现呢？
const WebSocket = require('ws'); // npm install ws
// 替换为实际的WebSocket调试URL，通常可以通过访问'http://localhost:9222/json'来获取
const wsUrl = 'ws://localhost:9222/devtools/browser/{sessionId}';
const ws = new WebSocket(wsUrl);
ws.on('open', function open() {
// 发送一个CDP命令
ws.send(JSON.stringify({
id: 1, // 消息ID，用于匹配响应
method: 'Runtime.evaluate', // 要执行的CDP方法
params: {
expression: 'console.log("Hello from CDP!");'
}
}));
});
ws.on('message', function incoming(message) {
console.log('Received: %s', message);
});
注意，实际应用中您需要先启动Chrome以便开启远程调试功能，通常可以通过以下方式来启动（以命令行为例）：
chrome --remote-debugging-port=9222
CDP的交互模式有两类：
- 本地模式：指打开一个页面，然后F12出现DevTools，两者的交互模式就是本地模式。本地模式下的通信实际上通常是通过IPC（进程间通信）来实现的
- 远程模式：像我们上面的示例代码。devtools和调试页面不在一个机器上。在这种模式下，可以用WebSocket来连接到远程实例并发送CDP命令，从而远程控制Chrome的实例
那么在远程模式下，我们如何去打开展示一个devtools呢？
二、devtools-frontend
devtools-frontend 是 Chrome DevTools 的前端部分的源代码，它是用来与用户直接交互的图形界面，包括我们在使用 Chrome 浏览器开发者工具时看到的各种面板（如 Elements、Console、Network、Sources 等）。
如果你要参与 DevTools 前端的扩展开发或者了解其底层工作原理，你通常需要查看或者操作 devtools-frontend 代码库。这份代码库是开源的，可以在 Chromium 项目的代码库中找到。这样的开源性使得开发者可以深入学习 DevTools 的实现，甚至可以自定义 DevTools 的功能。
以下是与 devtools-frontend 相关的一些基本操作介绍：
-
查看源代码：你可以在 Chromium 的代码库中或者 Google 的
devtools-frontend镜像库（如果有的话）中查看源代码。 -
运行 DevTools 前端：可以将
devtools-frontend源代码下载到本地开发环境中，然后运行它。这通常需要配置一些环境变量，可能还需要安装一些依赖项。 -
修改和扩展：你可以在本地修改
devtools-frontend的源代码，添加新的功能或者修改现有功能。这通常涉及到 JavaScript、HTML 和 CSS 的编写。 - 构建及部署：在完成代码修改后，你可以使用 Chromium 源代码中提供的构建系统来构建和测试你的更改。
devtools-frontend 是非常复杂的一套代码基础设施，它不仅包括用户界面，还有与后端（即浏览器引擎本身）的通讯逻辑。归功于 CDP，devtools-frontend 与浏览器的其他部分（例如渲染引擎、JavaScript V8 引擎等）保持不断的通信，这允许开发者实时监控和修改网页。
所以，我们可以自己部署一套devtools-frontend，我们先看本地模式的交互逻辑图：
本地模式
然后再看一下远程模式：
远程模式
对比我们可以看到：
在 Chrome DevTools 的体系中，后端充当了桥梁的角色，连接了正在调试的页面（也就是目标页面）和 DevTools 的客户端（用户界面）。
后端通常通过 WebSocket (ws) 协议与调试页面建立连接，使用 Chrome DevTools Protocol（CDP）来传送消息。而 DevTools 前端部分则通过一种叫做 IPC（Inter-Process Communication，即进程间通信）机制与后端（也就是浏览器的一部分）进行通信。
这里的过程可以大致描述如下：
目标页面与后端：
- 当开发者打开 DevTools 时，浏览器创建一个 WebSocket 服务器，该服务器监听某端口（例如，
ws://localhost:9222/devtools/page/{pageId}）。 - 目标页面通过该 WebSocket 连接与浏览器内部的 DevTools 后端通信。后端负责将 DevTools 发出的命令传送给页面，并将页面的信息回传给 DevTools。
前端与后端：
- DevTools 前端与浏览器后端不是通过 WebSocket 直接通信的，它们是在同一进程内的不同线程或者是不同的进程中运行（依赖于操作系统及浏览器架构）。
- DevTools 前端通过内置的 IPC 机制将命令发送给后端，后端将这些命令转发到目标页面，然后将目标页面的响应结果回传给前端。
- 这个 IPC 通信是浏览器内部实现的，通常对开发者来说是不可见的。
用户交互流程：
- 用户在 DevTools 中进行各种操作，如设置断点、刷新页面、查看元素等。
- DevTools 前端产生相应的 CDP 命令，通过 IPC 发送给后端。
- 后端通过 WebSocket 将这些命令转发给目标页面的 DevTools 代理。
- 目标页面执行这些命令并返回结果。
- 后端再将结果通过 IPC 送回前端，展示给用户。
这样的设计允许 DevTools 的前端和后端可以分离，甚至可以运行在不同的系统或者设备上，只要他们能够通过一些通讯协议（如 TCP/IP、WebSocket、IPC 等）交换 CDP 消息就可以了。
到这里为止我们发现远程调试的一个短板，就是需要chrome启动开debug端口，在这面向C端页面上是不可能的，你不能要求每个浏览器用户开启一个固定的端口。后来发现github有一个chii的项目，解决思路比较巧妙，下面我们一起来看一下。
三、Chii
Chii是一款web远程调试工具，其实现是对devtools-frontend的修改和扩展。它通过引入一层中介chobitsu，来解决我们上面所提到的需要浏览器开启debug端口的问题。chobitsu是CDP协议的JavaScript版本实现。其逻辑图如下：
chii逻辑架构图
它的使用非常的简单：
npm install chii -g
chii start -p 8080
在调试页面引入：
<script src="//host-machine-ip:8080/target.js" embedded="true"></script>
它本身分两种模式：
- 远程模式：不带属性embedded="true"
- 内嵌模式：带属性embedded="true"，内嵌模式就是打开后直接显示内嵌devtools，效果如图：
chobitsu也是chii团队提炼出的一个子功能。构思很是巧妙，目前基本能涵盖多数场景，比如Dom结构，Storage信息，CSS，Network，但仍然有关键的部位无法实现（js本身无法模拟）。
四、chobitsu的实现原理分析
首先，JavaScript是无法直接和CDP接口进行交互的。下面以它的一个DOM.ts
我们看到了什么？没错，是mutationObserver。到这里我们基本就对chobitsu实现理解有了了解。它并不是真正的去和浏览器的CDP接口进行交互，而是一种模拟实现。
再看一个Overlay.ts，鼠标在devtools的dom节点上滑动，调试页面会跟随高亮显示P:
也是模拟，监听鼠标move事件，然后通过LunaDomHighlighter组件，对划过的元素进行高亮显示。
从这两个例子我们大概就能理解，chobitsu会接收真实的CDP指令，然后进行模拟实现。所以就有一个问题，
像断点调试这种需要真正调用CDP接口的，它依然无法实现。虽然没有做到完美，但其实已经解决了90%的问题了，后续我们可以一起想想，有什么解决思路。
结语：
在本文中，我们一起探索了网页远程调试的概念，面对的挑战，以及可能的解决方案。但关键还是要把这些知识用于实战，解决实际中的问题。例如，借鉴Chii这类工具，我们可以构建一个在线的远程调试页面，这对于移动设备尤其有效，它让我们可以清晰地掌握到真实设备的运行情况。
此外，这项技术在低代码环境下同样可以发挥作用，成为其中的一个便捷调试工具。不过，除了技术本身，更让人觉得有价值的是它背后的创新思维。别人如何将旧技术变新应用，勇于尝试的态度，这是我们应该学习和思考的。技术永远在变，学会借鉴别人的创意和
