怎么做网站教程 用的工具,永年企业做网站推广,superstore wordpress主题,网站做的漂亮的企业近期团队内在自研小程序#xff0c;我负责开发者工具中的调试部分。调试作为面向开发者的基础能力#xff0c;扮演了极为重要的角色。 本篇文章是导读文章。 调试能力从0到1一共经历了4个版本#xff0c;接下来的文章将会以这4个版本为主线分别进行介绍。
初始版 上图为调试…近期团队内在自研小程序我负责开发者工具中的调试部分。调试作为面向开发者的基础能力扮演了极为重要的角色。 本篇文章是导读文章。 调试能力从0到1一共经历了4个版本接下来的文章将会以这4个版本为主线分别进行介绍。
初始版 上图为调试还不存在时的一个通信关系图。
在彼时已经实现了逻辑代码与渲染代码的运行隔离其中逻辑代码是运行在一个vm中的。
渲染层通过Electron提供的IPC能力与electron进行通信。electron持有vm的引用在收到渲染层的请求后Electron会直接交给vm执行。vm中运行的代码会通过vm的Context方法将执行结果抛出。vm收到代码后直接通过渲染层容器BrowserView的引用通过executeJavaScript将结果返还给渲染层。
通过以上4步完成了一个简单的渲染层、逻辑层的通信闭环。这其中有渲染层代码、逻辑层代码、preload、electron、vm、BrowserView 6个角色参与。
这个阶段的特点是实现了渲染代码与逻辑代码的隔离还不具备基础的断点调试能力。
第一版 这一版比初始版要复杂了一些它实现了逻辑代码的断点能力。它的主要改进是
将vm转移到了独立的进程中。通过node --inspect-brk使逻辑层代码运行于调试状态。由于逻辑层代码运行于独立进程中所以使用了IPC使渲染层与逻辑层维持通信状态。加入了可视化的调试界面。可以对代码执行基本的调试控制操作可以从控制台看到渲染层的日志输出。
它的不足之处在于无法审查DOM结构也无法查看Network记录。
第二版 这一版比上一版的改进在于可以查看Network记录同时也可以审查基本的DOM结构。
运行示例
这一版将逻辑层代码运行于worker内。调试审查面板采用了electron自带的调试工具。
在worker内部运行逻辑代码解决了Network审查的问题。electron自带的调试工具可以以较小的成本在调试工具中增加一个Tab这里用了chrome extensions的能力。
为了不影响逻辑代码的执行这一版采用adapter扮演了上一版vm的角色使上层的逻辑代码无感知的进行了运行时环境的迁移adapter负责底层数据的通信。
这一版最大的难点在DOM结构的审查。这是因chrome extensions 运行于逻辑层容器上而DOM信息位于渲染层容器上。有人可能会问把扩展放到渲染层容器上不就解决了吗答案是否定的因为console network source 这些能力与逻辑层严格关联。而调试面板只有一个必须做出成本方面的取舍。
解决DOM审查的办法是将渲染层与逻辑层的审查通信通道打通。这里就不得不提到chrome extensions的实现chrome extensions主要由3部分组成
frontend.js 这个文件运行于调试面板tab内。backend.js 这个文件运行于网页的上下文中。background.js 这个文件负责frontend.js与backend.js的通信。
以下这张图简单的描述了它们三者之间的关系
这里以已经非常成熟的extensions vue-devtools来做说明。vue-devtools的结构和上图一样backend.js是负责从页面中获得Vue的组件树结构然后再通过background.js发送给frontend.js来展示的。
而在我们的小程序中backend.js所运行的环境中并没有Vue的组件信息这些信息在哪呢它位于渲染层的运行环境中。所以我们需要做一些适当的改造基于vue-devtools如下 就是将原本运行于逻辑层网页环境中的backend.js移植到了渲染层网页环境中执行。而之前在逻辑层网页环境中运行的backend.js变为了backend.proxy.js它负责内外环境的通信。这里的内是指extensions的proxy.js外是指electron.js。渲染层中的GlueLayout.js扮演了之前的proxy.js的角色负责backend.js与外部的通信适配。
以上仅仅是打通了逻辑层与渲染层的审查通信通道而这还不够。因为我们需要审查的是渲染层的DOM结构目前只能看到的是渲染层的Vue组件结构。所以还需要一些改造。
为了兼容DOM审查与数据审查两种能力我们想出了一种创新方式就是将组件结构与DOM结构合二为一。例如
# Main.vue
templatediv classmainHello/Hello/div
/template# Hello.vue
templatediv classhellospanThis is Hello components!/span/div
/template实际审查时会变为
div classmainHellodiv classhellospanThis is Hello components!/span/div/Hello
/div当点击组件节点时展示的是组件本身的信息完全是vue-devtools的能力而当点击DOM节点时展示的是元素本身的信息没有实现。
这一版相比上一版实现了DOM树结构的审查与组件数据审查也实现了Network的审查。而不足之处在于还不能够实现Elements本身的审查比如修改样式查看内外边距等基础能力。
第三版 这一版相比于上一版有了比较完善的能力
完整的DOM审查能力。Console控制台。Source调试。Network审查。页面数据审查。
与市面上的其它小程序开发者工具相比该有的基础能力都具备了。
这一版的调试面板又采用了第二版所使用的chrome devtools frontend方案。与第二版不同的在于逻辑代码的运行采用的是第三版的方案。
这一版遇到了三个很大的挑战
如何使用一个调试面板控制渲染层的DOM结构与逻辑层的代码逻辑如何在缺少资料的情况下在chrome devtools frontend项目中增加一个新的有完全能力的tab如何获得审查数据
这里简单分别说明一下以上三个问题是如何解决的。
问题1
chrome devtools frontend下文简称frontend是谷歌官方研发的给chrome使用的调试面板项目。
frontend在启动后会通过WebSocket连接到一个目标调试地址注意**这个地址只能是一个地址。**那么问题来了现在逻辑层、渲染层分别运行于两个独立的环境中我应该连接谁呢连接谁都不靠谱。
唯一的解决方案是我们提供一个调试中继服务让frontend连接这个中继服务这个中继服务分别去连接逻辑层调试服务与渲染层调试服务。如下图所示
问题2
由于frontend项目在今年完全改为了TS的写法导致每次修改、查看需要花费10多分钟的编译时间。而为了压缩这可观的时间顺藤摸瓜找到了在修改为TS写法之前的最后一个版本这个版本是用JS写的可以修改后直接在浏览器中预览效果。最大的好处在于可以实时的调试代码了这对了解frontend项目的运行原理大开方便之门。
有了以上条件还不够因为frontend项目不同于传统的前端项目它没有构建的过程庞大的项目全是依靠配置文件动态加载生成的。
经过一段时间的摸索和大量的调试找到了frontend从启动到最终渲染一个TAB的完整过程。知道了它是怎么加载的那增加一个TAB也是板上钉钉的事情了。
在frontend中增加一个TAB的关键代码一览 但问题到此就解决了不不不还早着呢。完成以上步骤仅仅是有了一个TAB但它里面是空的什么都没有那怎么往里面添加内容呢
下面这段代码是调试面板Element的初始化代码一部分 Emmm怎么说呢和我们一般见到的形式完全不同既不是原生DOM操作也不是JQuery、Vue这类的第三方框架这怎么下手呢
原来frontend封装了大量的组件上面代码中的ElementPanel所继承的UI.Panel.Panel就是一个组件。最开始我尝试使用这些组件但由于没有文档加上代码量庞大用起来非常的吃力效果也不好。最终通过代码阅读找到了这些组件暴露在外的element那么我将Vue挂载到这个Element上就可以使用vue的方式去实现这个TAB的内容了。如图所示 问题3
因为frontend是基于websocket与外界通信的element、console、source这些模块都是通过内置的websocket client与外界交换数据。而这个websocket实例被高度封装很难在Vue中直接使用。例如Element是通过这种方式去获取DOM数据的
注意这里的invoke_getDocument方法是动态合成的
这里不展开展示细节了。总之如果按照frontend的方式实现通信的过程改造难度非常大。这时我想另辟蹊径自建一条通信通道。但后来想想又放弃了这不是个好的办法。最终还是决定从内置的websocket上入手看看哪些关键的地方可以暴露给全局使用。最终经过不断的调试找到了这个关键的对象
这样一来我便可以随便使用了
export function sendMessage(method, params) {return new Promise((resolve, reject) {// self.target为通信关键对象self.target._router.sendMessage(, DataInspect, DataInspect.${method}, params, (error, result) {if (error) {console.error(Request method failed. JSON.stringify(error));reject(null);return;}resolve(result);})})
}target这个对象可以保证请求与回调完全一一对应不出错不混不乱。这为我后来实现主动监听逻辑层回调提供了实现思路。
Final
*小程序的调试技术从0到1一共经历了3个版本的演化才达到了一个完善的状态虽然演化的过程中被不断推翻之前的方案但带来的结果终究是完美的。这是一个必然的过程因为不踩坑不知道坑的存在。
小程序调试这块对我来说最大的挑战在于每一步几乎都在摸索。假设、实现、验证无限循环不断完善。实际上调试涉及的最核心的技术应该是通信比如逻辑层与渲染层的通信、调试面板与调试源的通信经历了各种复杂的角色才完成了一项基础能力。 最后贴一下第三版基本调试能力实现全图
数据审查面板
Source面板
Console控制台
DOM审查面板
调试中断
Network网络资源审查
Network XHR审查
好导读文章就到这里。接下来会分几篇文章详细介绍第三版的完整实现。
