（簡單來說），有了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上歡迎大家提關於有哪些地方需要改進的建議。