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.snapshotRectAPI的方式，让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的计划是什么？（What’s next for RemoteDebug）

RemoteDebug的重心，还是会继续放在（如何）安利标准化（standardized）Core Debugging Protocol，这样的话，协议就不会被一些（自以为拥有）成熟的协议标准模型制订经验（open governance model）的浏览器厂商所持有，而是能够让更多的浏览器厂商加入进来。
RemoteDebug应该会把“RemoteDebug测试全家桶”（RemoteDebug test suite）加入进来，这样的话，在跨运行时（across runtime）的过程中，我们就可以自己来验证RemoteDebug是否存在兼容性问题，来确保VS Code等工具能够被正常使用。虽说我们还没开始开发RemoteDebug测试全家桶，不过，我觉得这并不妨碍你们在一些场景使用RemoteDebug iOS WebKit Adapter，除了Chrome浏览器自身实现针对RemoteDebug测试的指标（test target）之外，我们已经有针对RemoteDebug测试的指标啦。

最后，恳请大家尝试一下RemoteDebug iOS WebKit Adapter，在使用过程中，欢迎大家给我们提issue，在GitHub上欢迎大家提关于有哪些地方需要改进的建议。