（简单来说），有了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上欢迎大家提关于有哪些地方需要改进的建议。
