局域网中用adb调试手机_快应用调试器的研究2

接上文的前置知识。这一篇是上文的具体应用。

快应用调试器又包含调试器内核和调试器app容器。调试器内核先放到一边，我们从调试器的容器开始入手。

1、点击调试之后的过程

点击 开始调试 的时候，调试器会发送一个post请求到快应用项目启动的server。由于快应用server的端口是可以变化的，ip也会变化。

那么往哪个server发？在扫码的时候，调试器会记录当前项目的server的ip和端口号。点击调试就会向该ip:port发送调试的post请求。

如果上次记录的地址发生变化，那就需要重新扫码。

该调试请求（/postdbg）的请求头中会携带相关信息，用于server解析。（/postdbg 等同于之后的/poststdbg）

继续，该请求的body中会携带如下信息

这些信息是什么呢？

包含：调试器容器启动了一个server，端口是38474（这个端口不是固定的，每期启动调试器就会随机产生，这个示例用38474举例），这个端口上又有多个路径。

其中/inspector就是之后跟chrome进行cdp协议通信的ws协议

这个接口不是http协议的，所以通过http协议访问不到，需要ws协议访问。

/status记录该调试器的一些相关信息。

ok，这个接口返回的东西和上文提到的post请求的body体一致。

调试器的这个server地址是多少呢？ip:39517，39517是和android同学约定的。

调试器在39517端口起了一个server用于跟node server进行通信。

这个server除了在启动是发送/postdbg请求外，还会serve一些接口服务。

比如/update。这个接口非常重要，调试器server接收到这个请求后会向快应用项目server拉取最新的rpk包，然后重新执行rpk。对chrome重新发送cdp消息。

服务流程图大致是这样的。

2、WIFI环境。

初始版本的调试器只支持网络调试，就是只能通过wifi连接到调试器的server。

我们看下在wifi环境下/postdbg的请求

header里的host就是快应用的项目server，这里是在8000端口启动的，如果8000端口被占用会向后搜索可用端口。

由于在局域网内可以访问到调试器的对外端口，所以可以直接访问该端口并发送请求。这个没有什么问题。

所以我在pc上直接访问手机的server的39517端口的/update接口就可以让手机获取最新rpk

这样的话，只要其他人拿到我手机的ip，就可以任意请求，导致我的项目疯狂更新rpk。有点厉害！

3、不使用WIFI环境，使用USB调试。

如果使用usb调试，那么手机无法在局域网内。手机的调试器端口外部无法访问，这就需要我们的前置知识了。我们就需要使用adb的功能了。

我们看下点击调试后/postdbg的请求

header里的host就是快应用的项目server，现在这里不是8000端口了，而是12306端口。

这里我们和android同学约定好了，在调试模式下访问12306端口。

这是通过adb reverse 命令 将快应用的8000端口反向代理到手机的12306端口了。

看到没，现在我们在手机访问127.0.0.1:12306/就是调试页面了。

也就是手机需要访问快应用项目的接口只需要访问本地12306即可，所以发送/postdbg请求到127.0.0.1:12306 就可以了。

同理，调试器启动的端口（比如上面所说的39517端口 以及随机的ws端口）都使用adb forward转发到本机。

这样访问127.0.0.1:39517就相当于访问手机调试器端口，访问本机随机启动的端口也相当于访问对应的手机端口。

这样我们启动的chrome页面连接的本地的ws端口就相当于链接手机调试器ws端口。

大体流程我再画一张图。

总结：

这就是快应用调试器在wifi环境和use调试环境下的基本原理。其他的业务逻辑具体看代码。

调试器的ws端口和chrome如何建立页面DOM将在下一篇分析。