譯者：雨謹；校對：numbbbbb，pmst；定稿：Forelax

上個月，蘋果公司 在 Swift.org 論壇上宣布，正在著手為 Swift 和 C 語言支持 Language Server Protocol（語言服務器協(xié)議，LSP）。

對于蘋果公司而言，為所有 Swift 開發(fā)者 —— 包括非蘋果平臺上的 —— 提供高質量的工具支持非常重要。我們希望與開源社區(qū)合作，將精力集中在構建 Xcode 和其他編輯器、其他平臺可以共享的公共基礎設施上。為實現(xiàn)這一目標，[……]，我們決定支持 LSP。

Argyrios Kyrtzidis，2018 年 10 月 15 日

這可能是蘋果自 2014 年將 Swift 作為開源軟件發(fā)布以來，為 Swift 做出的最重要的決定。 這對于 APP 開發(fā)者來說是一件大事，對于其他平臺上的 Swift 開發(fā)者來說更是一件大事。

為了理解其中的原因，本周的文章將研究 Language Server Protocol 解決了什么問題，它是如何工作的，以及它的長期影響可能是什么。

更新：sourcekit-lsp 項目現(xiàn)在已經(jīng)可以 在 GitHub 上訪問 了。

想象這樣一個矩陣，每一行表示不同的編程語言（Swift、JavaScript、Ruby、Python 等），每一列表示不同的代碼編輯器（Xcode、Visual Studio、Vim、Atom 等），這樣每個單元格表示特定編輯器對一種語言的支持級別。

然后，你就發(fā)現(xiàn)各種組合形成了一種支離破碎的兼容。有些編輯器和部分語言深度集成，但除此之外幾乎什么都干不了；其他編輯器則比較通用，對很多語言都提供了基本的支持。（IDE 這個術語通常用來描述前者。)

舉個奇葩的例子：你不用 Xcode 來開發(fā) APP，卻偏用來干其他事情。

為了更好地支持某一特定的語言，編輯器必須編寫一些集成代碼（integration code）—— 要么直接寫在項目里，要么通過插件。由于不同語言和編輯器的實現(xiàn)機制不一樣，因此比方說 Vim 改進了對 Ruby 支持，但這并不能讓它更好地支持 Python，也不能讓 Ruby 在 Atom 上運行地更好。最終的結果是：大量精力浪費在了不同技術的兼容上。

我們上面描述的情況通常被稱為 M × N 問題，即最終的集成方案數(shù)量為編譯器數(shù)量 M 與語言數(shù)量 N 的乘積。Language Server Protocol 所做的事情就是將 M × N 問題變成 M + N 問題。

編輯器不必實現(xiàn)對每種語言的支持，只需支持 LSP 即可。之后，它就能同等程度地支持所有支持 LSP 的語言。

Tomohiro Matsuyama 在 2010 年寫的 "Emacs は死んだ" ("Emacs 已死") 這篇文章就對這種問題做出了一個很好的論述。Matsuyama 描述了 Emacs 腳本語言的局限性（不支持多線程、底層 API 過少、用戶基數(shù)太?。J為編寫插件的首選方法應該是與外部程序進行交互，而不是原生實現(xiàn)。

Language Server Protocol 為支持的語言提供了一套通用的功能集，包括：

• 語法高亮（Syntax Highlighting）

• 自動格式化（Automatic Formatting）

• 自動補全（Autocomplete）

• 語法（Syntax）

• 工具提示（Tooltips）

• 內(nèi)聯(lián)診斷（Inline Diagnostics）

• 跳轉到定義（Jump to Definition）

• 項目內(nèi)查找引用（Find References in Project）

• 高級文本和符號搜索（Advanced Text and Symbol Search）

各種工具和編輯器可以將精力用于提升可用性和提供更高級的功能，而不是為每種新技術再造個輪子。

Language Server Protocol 的工作原理

如果你是一個 iOS 程序員，那么一定很熟悉 server 和 protocol 這兩個術語在 Web 應用程序的 HTTP + JSON 通信場景下的含義。實際上 Language Server Protocol 差不多也是這么工作的。

對于 LSP，client 是指編輯器 —— 或者更寬泛一點，是指工具，server 是指本地獨立進程里運行的一個外部程序。

至于名字中包含 protocol，是因為 LSP 類似于一個精簡版的 HTTP：

• 每個消息都由報頭部分和內(nèi)容部分組成。

• 報頭部分包含一個必填的 Content-Length 字段，用于說明內(nèi)容部分的大?。ㄒ宰止?jié)為單位），以及一個可選的 Content-Type 字段（默認值為 application/vscode-jsonrpc; charset=utf-8）。

• 內(nèi)容部分使用 JSON-RPC 描述請求、響應和通知的結構。

每當工具中發(fā)生了什么事情，比如用戶需要跳轉到符號的定義，工具就會向 server 發(fā)送一個請求。server 接收到該請求，然后返回適當?shù)捻憫?/p>

以下是 LSP 如何在幕后實現(xiàn)這種交互：

首先，當用戶打開 Swift 代碼時，若 Swift language server 并未運行，編輯器將在一個獨立進程中啟動它，并執(zhí)行一些額外的配置。

當用戶執(zhí)行 "跳轉到定義（jump to definition）" 指令時，編輯器向 Swift language server 發(fā)送以下請求：

收到這個請求后，Swift language server 使用 SourceKit 等編譯器工具來標識相應的代碼實體，并在代碼的上一行找到其聲明的位置。然后 language server 用以下消息進行響應:

最后，編輯器導航到文件(在本例中，該文件已經(jīng)打開)，將光標移動到該范圍，并高亮顯示出來。

這種方法的美妙之處在于，編輯器完成所有這些操作時，除了 .swift 文件與 Swift 代碼相關以外，對 Swift 編程語言一無所知。編輯器需要做的就是與 language server 對話并更新 UI。而且編輯器知道如何做到這一點后，就可以遵循相同的過程，與任何帶有 language server 的語言所編寫的代碼進行交互。

Clang / LLVM 里的 Language Server Protocol

如果你覺得之前的 M + N 圖有點眼熟，那可能是因為 LLVM 也采用了同樣的方法。

LLVM 的核心是中間表示（intermediate representation，IR）。LLVM 所支持的語言使用 編譯器前端（compiler frontend） 生成 IR，再使用 編譯器后端（compiler backend） 將 IR 生成所支持平臺的機器碼。

如果你想了解 Swift 代碼編譯的更多細節(jié)，請查看 我們關于 SwiftSyntax 的文章。

Clang 是 C 語言的 LLVM 編譯器前端。Swift 與 Objective-C 的互操作性（inter-operability）就是靠它實現(xiàn)的。在最近的 5.0.0 版本中，Clang 添加了一個名為 Clangd 的新工具，它是 LLVM 對 Language Server Protocol 的實現(xiàn)。

2018 年 4 月，蘋果公司向 LLVM 郵件組宣布，將把開發(fā)的重心從 libclang 轉向 Clangd，以其作為創(chuàng)建交互工具的主要方式。

現(xiàn)在你可能會想，“那又怎樣？” 蘋果公司是 LLVM 項目最重要的支持者之一，該項目創(chuàng)始人 Chris Lattner 已經(jīng)在蘋果公司工作了十多年。蘋果公司決定從不透明的 Clang 工具切換到另一個，似乎是一個實現(xiàn)細節(jié)了(可以這么說)。

這個官宣很有趣的一點是，Clangd 似乎完全是在蘋果以外開發(fā)的，谷歌和其他公司也做出了重大貢獻。這個官宣標志著未來工具開發(fā)方向的重大轉變 —— 六個月后 Swift.org 論壇將證實這一點。

蘋果支持 Language Server Protocol 的潛在影響

根據(jù)蘋果公司 10 月份發(fā)布的 LSP 公告，我們預計在未來幾周內(nèi)（撰寫本文時，最早 11 月中旬）將看到該項目的首批代碼。

要感受這些發(fā)展的全部影響還需要一些時間，但請相信我：你的耐心是值得的。我相信以下是 LSP 在未來幾個月和幾年將會發(fā)生的一些事情。

Swift 變成一種更加通用的編程語言

雖然 Swift 主要用于 APP 開發(fā)，但它從一開始就被設計成一種功能強大的通用編程語言。在 Swift for TensorFlow、
SwiftNIO 和其他項目中，我們正開始看到 Swift 承諾的在 App Store 之外的使用。

到目前為止，阻礙 Swift 被主流采用的最大因素之一是它對 Xcode 的依賴。

人們會有很多質疑，當有那么多優(yōu)秀的、門檻低很多的替代方案可選的情況下，為什么還要讓 Web 開發(fā)者或機器學習工程師僅僅為了嘗試 Swift 而去下載 Xcode？支持 Language Server Protocol 可以讓蘋果生態(tài)圈以外的人更容易地使用他們熟悉工具去感受 Swift。

Xcode 變得更好

支持 LSP 不僅僅是讓 Swift 在其他編輯器中運行地更好，Xcode 也將受益匪淺。

看看蘋果 Swift 項目負責人 Ted Kremenek 的 這篇論壇帖子:

@akyrtzi 所描述的 LSP 服務將比今天的 SourceKit 更強大。

LSP 對 Xcode 團隊來說是一個機遇，讓他們使用一種新的方法實現(xiàn) Swift 集成，并可以將其應用在語言和工具自 1.0 版本發(fā)布以來四年中的所有改進上。

Xcode（最終）變得更強大

LSP 的好處并不限于 Swift 和 Objective-C，Argyrios 在那個帖子的另一個留言中指出：

Xcode 使用我們新的 LSP 服務，這意味著它也可以使用其他 LSP 服務，我們對此很感興趣，不過目前暫無具體計劃。

目前的工作重點是改進 Swift。但是，一旦實現(xiàn)了這一點，就應該能相對簡單地將這些優(yōu)化轉移到支持 LSP 的其他語言中。

軟件的架構反映了創(chuàng)建它的組織的結構和價值。在某種程度上，反之亦然。

通過讓 Xcode 支持開放的 Language Server Protocol 標準，蘋果正在履行其在蘋果生態(tài)系統(tǒng)之外的平臺上實現(xiàn) Swift 成功的承諾。我認為這是可行的：工具（或缺少工具）通常是技術獲得人心的關鍵決定因素。但或許更重要的是，我認為這一決定表明，公司內(nèi)部（至少是一小部分）對合作和透明度的意愿有所增強。

本文由 SwiftGG 翻譯組翻譯，已經(jīng)獲得作者翻譯授權，最新文章請訪問 http://swift.gg。