【文章內容使用 Gemini 2.0 自動翻譯產生】
宣布 Dart 3.5 和 Dart 路線圖更新
我們又到了季度 Dart SDK 發佈的時間。我們在互操作性方面進行了改進,在我們的 pub.dev 套件管理器中加入了新功能,並且我們已將新的 Web 整合 API 升級到穩定版和 1.0 版。
我們的大部分時間都花在更大、跨多個季度的努力上,因此我們也更新了 Dart 路線圖,詳細說明了我們希望在未來幾個季度取得的進展。

Dart 3.5 的新功能
Dart 3.5 具有以下討論的許多新功能。核心函式庫 API 也有一些較小的變更,以及大約 10 個非常小的重大變更,這些變更涵蓋在 變更日誌 中。
Web 平台和 JS 互操作性
在 Dart 3.4 和 Flutter 3.22 中,我們引入了對 將 Flutter Web 應用程式編譯為 WebAssembly 的支援。編譯為 WebAssembly 需要使用我們新的 Dart 到 JS 互操作模型,該模型之前處於預覽階段。從 Dart 3.5 開始,它現在被認為是穩定且完整的,我們已將 package:web(它取代了舊的 dart:html 函式庫)中的瀏覽器 API 繫結更新到 1.0 版。
我們鼓勵所有 Web 套件作者 遷移到 package:web。我們計劃在下一個 Dart 版本中棄用舊的互操作 API(dart:html、dart:js、package:js 等),並在明年晚些時候完全停止使用它們。我們邀請您在 追蹤議題 中就此計劃提供回饋。我們還計劃更新 pub.dev 套件管理器上的 評分,以獎勵支援新互操作模型的 Web 套件。
我們還加入了 一個新的 lint,它驗證您的程式碼是否正確使用了新的 JS 互操作類型。我們建議您在遷移 Web 套件時將此 lint 加入到您的 analysis_options.yaml 檔案中。
Dart 原生互操作性
我們還對原生互操作性進行了一系列改進,它支援從 Dart 直接調用到 C、Java、Kotlin、Objective-C 和 Swift。
C 互操作由我們的 FFI(外部函式介面)函式庫啟用,我們已經支援了幾年。在 Dart 3.5 中,我們進行了漸進式改進,以支援將 Dart TypedData 物件的指標直接傳遞給 FFI,避免必須先將記憶體從 Dart 複製到原生(詳細資訊)。
Java 和 Kotlin 互操作由 JNIgen 生成器(目前處於預覽階段)啟用,它自動建立繫結程式碼,以透過 Java 原生介面 (JNI) 從 Dart 調用到 Java 和 Kotlin。我們改進了效能,並加入了對 Java 異常和 Kotlin 頂層函式的支援。我們還停止了以前的 基於 C 的繫結,因為現在替代的僅 Dart 繫結具有相當的效能和功能,並且更容易使用。有關詳細資訊,請參閱 變更日誌。
Objective-C 互操作建立在 FFI 和我們的 FFIgen 生成器(目前處於預覽階段)之上。我們加入了對 Objective-C 協議和常見類型(例如 NSString)的支援。有關使用 FFIgen 建立的套件的大型範例,請參閱 cupertino_http,它與 Apple 的 URL Loading System 網路函式庫互操作。
我們將繼續在未來的版本中進一步投資互操作性——無論是在完成上述函式庫方面,還是在支援 Swift 方面。有關詳細資訊,請參閱下面的路線圖部分。
Pub.dev 套件儲存庫
Pub.dev 是我們的套件儲存庫,社群可以在其中分享和找到具有豐富功能的套件。我們在這裡進行了一些改進。首先,我們改進了對 主題 的支援:套件作者可以透過這種機制使用它們所屬的類別(例如 widget)來標記他們的套件。我們現在 整合 涵蓋相同類別但措辭略有不同的常見主題(例如 widgets vs widget)。
其次,我們加入了一個新的 pub unpack
命令。這提供了一種快速簡便的方法來將套件下載到您的檔案系統。例如,如果您想在本地機器上運行套件的範例程式,可以使用此命令:
1 | $ dart pub unpack path |
第三,我們加入了一個新的 pub downgrade --tighten
命令。這可以用於檢查套件相依中的所有版本限制。運行時,它會將較低的限制更新為 pub 能夠解析的最低版本。
Dart 路線圖更新
除了上述已完成的功能外,我們還在許多領域開展了工作,以推進我們的長期路線圖。
大型 monorepos 的 IDE 和分析器效能
「monorepo」是一種常見的程式碼結構方式,用於將一組相關套件和應用程式的程式碼放在單個儲存庫中,例如 Flutter 的 套件儲存庫。monorepo 不僅僅是為了方便將所有程式碼「放在一起」,而且還可以作為確保儲存庫中的各個套件和應用程式相互相容的關鍵工具。
我們一直收到在大型 monorepos 中工作的開發人員的回饋,認為我們的工具,尤其是分析器的效能可能不足。我們對這些問題的分析表明,根本原因是我們最終為每個套件及其所有相依載入了多個重疊的分析上下文,導致記憶體中同時存在多個套件分析副本。我們相信根本的解決方案是在此類儲存庫中建立每個相依版本的單個共用解析,並正在透過一個名為 workspaces 的新 pub 功能來開發此功能。我們將在下一個 Dart 版本中分享更多關於此的資訊,但現在您可以先看看這是如何 最近應用 於 Flutter 引擎儲存庫的。
Pub.dev 套件儲存庫
pub.dev 套件儲存庫的使用者長期以來一直要求改進 每個套件的使用/下載 指標。這對於套件作者來說,可以作為一個指標,表明有多少使用者從他們的工作中受益;對於套件使用者來說,可以作為一個指標,表明其他開發人員正在使用哪些套件。我們很高興地與大家分享,我們在這項功能上取得了良好的進展,並希望在年底前推出預覽版。
Dart 原生互操作
對於使用 JNIgen 的 Java 和 Kotlin 互操作,我們預計將在接下來的兩個季度內完成核心支援,並從實驗版升級到穩定版 1.0。有關詳細資訊,請參閱 JNIgen 追蹤器。對於 ObjectiveC 互操作,我們有一個類似的目標;請參閱 Objective-C 追蹤器。
接下來,我們正在研究與 Swift 程式碼的直接互操作。初步實驗看起來很有希望,我們希望在明年年初加入實驗性支援。
原生互操作和原生程式碼的捆綁
在許多情況下,直接互操作用於調用到作業系統中存在的 API,這意味著這些 API 在這些主機平台上始終可用。但是,在某些情況下,Dart 互操作的程式碼是主機上未直接包含的原生程式碼,這對使用此類互操作的套件作者提出了一個實際挑戰:如何在不將大量手動步驟推給套件使用者的情況下捆綁和構建該原生程式碼?為了支援這一點,我們正在探索一個 原生資源系統,它可以支援發佈包含原生程式碼的 Dart 套件,以及一個標準化協議,以啟用 dart 和 flutter CLI 工具自動構建和捆綁該程式碼。我們預計這將啟用一組新的互操作使用案例,同時為使用依賴原生程式碼的套件的開發人員提供簡單的使用者體驗。
Dart 語言和巨集
Dart 語言和編譯器團隊目前的大部分時間都花在推進大型語言功能巨集上,我們在 Dart 3.4 部落格文章 中介紹了巨集。正如我們當時所說,這是一項巨大的任務,可能會在我們的一些核心使用案例(例如熱重載)中造成回歸,因此我們正在採取一種徹底的方法,並且在我們能夠分享下一步的詳細資訊之前,可能需要幾個季度的進一步工作。
除了巨集之外,我們還同時探索許多其他較小的語言功能,如 Dart 語言漏斗 中所述。
自去年秋季以來,我們一直在重寫 Dart 格式化程式。舊的設計在很多年裡都運行良好,但隨著 Flutter 的成功,我們希望轉向 一種新風格,這種風格更適合 Flutter 使用者經常撰寫的宣告式程式碼。舊的格式化程式無法產生這種輸出。重寫工作接近完成,很快就會發佈。如果您想試用它,請傳遞實驗旗標 tall-style(旗標說明)。如果您看到奇怪的輸出,歡迎提供 回饋。
結語
這就是我們今天要分享的全部內容。我們歡迎您提供回饋,無論是關於討論的路線圖項目,還是關於 Dart 3.5 中的新功能,這些功能可以從 Dart.dev 獲取,或捆綁在今天的 Flutter 3.24 版本 中。
宣布 Dart 3.5 和 Dart 路線圖更新 最初發佈在 Dart 上的 Medium,人們在那裡透過突出顯示和回應這個故事來繼續討論。