内容简介：RemoteDebug iOS Webkit Adapter（适配器）：一个可以让你（随时）随地调试Safari、iOS WebView（的...
（简单来说），有了RemoteDebug iOS WebKit Adapter，你就可以在Windows以及Mac上，通过使用Chrome DevTools、VS Code、Firefox debugger.html工具的方式来调试Safari、iOS WebViews啦
今天，非常开心能够跟大家介绍我们的新项目— RemoteDebug iOS Webkit Adapter （能够让你在Windows以及Mac上，利用 VS Code 、 Chrome DevTools 、 Firefox debugger.html 等 工具 来调试Safari、iOS WebViews）。
RemoteDebug iOS Webkit Adapter的用途（Purpose）
-
能够让一些基于 Chrome Debugging Protocol（CDP） 实现的工具也具备调试iOS Safari/Webkit能力。
-
能够提供协议适配器（protocol adapter），补充一句，该协议适配器主要是用于抹平（handle） Chrome Debugging Protocol 以及 Webkit Remote Debugging Protocol 之间API存在的差异性。
-
能够在 ios-webkit-debug-proxy 上进行二次开发，为啥呢？这是因为RemoteDebug iOS Webkit Adapter项目其实是基于ios-webkit-debug-proxy项目构建的，另外你也可以把RemoteDebug iOS Webkit Adapter项目看作是 ios-webkit-debug-proxy 项目的延伸
目标（Goal）
（一直以来），我都希望有一个开源的协议适配器，为啥呢？这是因为，有了开源的协议适配器，我们就没有必要重复造轮子，然后就可以合理分配我们的精力以及手上资源。（令人欣慰的是），截止到目前（until now），（普通的）协议适配器已经能够让一些（a various number of）工具、客户端（client）完成调试 Apache Cordova 、iOS WebKit/Safari的工作啦。另外，核心（central）协议适配器也能让职责变得非常明确（上述工具可以只关注API的实现，协议适配器只处理兼容性问题）。
架构（Architecture）
虽说协议适配器本身是用TypeScript实现的，不过也会存在依赖Node CLI工具的情景。这是因为，协议适配器需要ios-webkit-debug-proxy（译者注：ios-webkit-debug-proxy依赖node），所以协议适配器执行过程就会变成酱紫，Node CLI工具首先会去启动 ios-webkit-debug-proxy 实例，接着该实例就会去发现（detect）处于连接状态的iOS设备，最后根据iOS版本号来启动相对应的协议适配器。
对iOS版本号进行检测的操作，其实是依赖于 libimobiledevice 给出的ideviceinfo，（不过还真别说），上述操作还真有必要。这是因为通过WebKit Remote Debugging Protocol所暴露出的API，在（不同的）WebKit版本中会有细微的变化。在iOS 10降级到 iOS 8的过程中，将API的差异性作为切入点（as a starting point）的想法，已经被我们实现啦， 查看更多的实现细节 。
最后，协议适配器会暴露出WebSocket服务器以及HTTP服务器，（忘记说了），这些服务器都支持CDP协议。这也就意味着，对于外部工具（external tools，例如VS Code）来说，是和基于Chromium的运行时（runtime）建立连接还是和协议适配器建立连接，这两者似乎没有太大差别。
简单的描述一下适配器（The adapter in a nutshell）
协议适配器让一些（a broad range of）比较新的特性（features that hasn’t been working for a long time），在Chromium内核、WebKit内核所暴露出的API之间，也能找到属于自己的“极乐净土”（growing delta）。
-
DOM以及CSS（DOM／CSS）
实现了一套（a range of）基础DOM／CSS API接口，这些API接口不但能够让开发者审查DOM元素，而且还能够让开发者修改DOM元素的CSS。
-
控制台（Console）
和我们预想的一样，Console API实现函数console，不过这是通过将Webkit Remote Debugging Protocol API 映射 到新的Chrome Debugging Protocol API实现的。
-
网络请求查看工具（Network tool）
和我们预想的一样，Network tool 也同样实现了针对network tool的函数，并且可以通过设置cookie或者删除cookie的方式来激活cookie。
-
脚本调试（Script debugging）
在调试脚本的过程中，还能（让开发者）熟悉（enable）VS Code、debugger.html以及Chrome DevTools等工具中 debugger-statement 的用法。
-
录屏（Screencasting）
再说一个关于协议适配器的小彩蛋（As a little extra thing），通过借助Chrome开发者工具，协议适配器也可以完成简单的录屏操作（a basic version of screencasting）。当然，我们也发现，通过使用 Page.snapshotRect API的方式，让WebKit内核支持可视窗口（viewport）截屏的想法变成了现实。上面讲到的这些，都将会助力我们模拟出Chromium的录屏特性。至于性能预警特性，我们会通过原生的方式实现（with the caveat of performance is sub-pair with the native implementation），另外，touch行为模拟的不够彻底，虽说体验起来可能限制比较多，不过从协议适配器的角度来说，能做成酱紫应该还算可以（ but conceptually it works）。
开搞吧（Getting started）
首先，你要记住RemoteDebug iOS WebKit 适配器是可以运行在Windows以及MacOS平台上的。接下来，你可以通过NPM安装包的方式，来开始安装该适配器：
npm install remotedebug-ios-webkit-adapter -g
在安装过程中，你可能需要安装一些特殊的依赖包，至于到底要不要，这取决于你的系统，获取更多的安装细节，请 按照README文件所给出的依赖包安装教程，进行操作 。
在使用适配器的过程中，应结合使用 Chrome DevTools、VS Code、Firefox debugger.html工具（Using the adapter with Chrome DevTools, VS Code and Firefox debugger.html）
首先，你需要通过（自己喜欢的）命令行来启动适配器：
remotedebug_ios_webkit_adapter --port=9000
只要适配器跑起来啦，你就可以 按照指南 来配置Chrome DevTools，这样就可以在chrome://inspect#devices页面出现“discover network targets”，或者你也可以把适配器跑在 9222 端口，这样， Firefox debugger.html页面 也能出现 “iOS targets”。
或者（Alternatively），你也可以在开启 9000 端口的同时，使用下面给出的 launch.json 配置文件来 配置VS Code 。配置完成后，你就可以通过直接使用VS Code的方式，来轻松调试Safari、iOS WebViews啦。
{
"version": "0.2.0",
"configurations": [
{
"name": "iOS Web",
"type": "chrome",
"request": "attach",
"port:": 9000,
"url": "https://kenenth.io/*",
"webRoot": "${workspaceRoot}/src"
}
]
}
多亏了Microsoft团队发起这个项目（Thanks to Microsoft for sponsoring the work）
（我先给大家透露一些八卦），RemoteDebug iOS Webkit Adapter这个项目，其实一开始是作为Microsoft内部的实验项目，并且希望对接（target）不同运行时环境的这个过程，能够对Visual Studio、VS Code以及其它工具透明，为啥呢？这是因为我们目前已有的调试工具都是基于CDP协议，并且主要是针对Node以及Chrome环境。
今天，RemoteDebug iOS Webkit Adapter这个项目已经捐给 RemoteDebug GitHub组织 ，（另外，补充一句），RemoteDebug iOS Webkit Adapter项目也是基于MIT协议开源的。把RemoteDebug iOS Webkit Adapter项目开源，这也是我们Microsoft团队兑现自己的承诺，不过这意味着，Microsoft团队将不再继续维护该项目啦。
非常感谢我现在的东家（employer）Microsoft，让我担任RemoteDebug iOS Webkit Adapter项目的项目经理，同样感谢团队中的其他成员，他们为了能够完成这个项目，真的是操碎了心。另外，特别感谢 James Lissiak ，感谢他给出针对该项目的技术架构图，（他之所以能够给出该技术架构图），都是源于他对不同协议API的深入研究以及能够对screencasting bits问题给出解决方案。（译者注：此处应该有掌声）
展望未来（Going forward）
对于 RemoteDebug iOS WebKit adapter项目来说，接下来的任务，就是去 实现32个还有待于开发API ，（上面的这些API完成之后，那也就意味着），该适配器已全面完成对 Chrome Debugging Protocol（CDP）API的覆盖，不过这些工作我也希望社区也能参与进来。
尽管 RemoteDebug iOS WebKit adapter还不够完美，还很年轻（it’s still early days），不过该项目已经全面托管（take over）了 ios-webkit-debug-proxy 项目，而且让更多的工具能够在iOS上调试WebKit，这很了不起！性能分析（Profiling）仍然是我们需要解决的头等大事（is still one of the bigger things that needs to get tackled），不过这问题想想都觉得挺难的，这是因为Webkit Remote Debugging Protocol以及Chrome Debugging Protocol对于底层数据模型（underlaying data model）的实现，存在很大的分歧。这也就是说，如果可能的话，性能分析能够让一些工具也有被使用的场景，比如， Lighthouse 以及 CalibreApp 就可以分析WebKit内核浏览器的性能问题。
以上所述就是小编给大家介绍的《RemoteDebug iOS Webkit Adapter（适配器）：一个可以让你（随时）随地调试Safari、iOS WebView（的...》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
