【文章內容使用 Gemini 1.5 Pro 自動產生】
宣布 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 互操作類型。我們建議您將此 Lint 加入到您的 analysis_options.yaml 檔案中，作為遷移您的 Web 套件的一部分。
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 載入系統網路函式庫進行互操作。
在未來的版本中，我們將繼續投資於進一步的互操作性 - 既包括完成上述函式庫，也包括支援 Swift。請參閱下面的路線圖部分以獲取詳細資訊。
pub.dev 套件儲存庫
pub.dev 是我們的套件儲存庫，社群可以在其中分享和查找具有豐富功能的套件。我們在此處進行了一些改進。首先，我們改進了對 主題 的支援：套件作者可以使用此機制使用套件所屬的類別（例如 Widget）對其套件進行標記。我們現在 彙整 涵蓋相同類別但使用略微不同的措辭的常見主題（例如 Widget 與 Widget）。
其次，我們新增了一個新的 pub unpack 命令。這提供了一種在檔案系統中快速下載套件的簡單方法。例如，如果您要運行套件的範例程式並在您的本地機器上運行程式，則可以使用它：
1 | $ dart pub unpack path |
第三，我們新增了一個新的 pub downgrade –tighten 命令。這可以用於檢查套件相依關聯中的所有版本約束。運行時，它會將下限約束更新到 pub 成功進行解析的最低版本。
Dart 路線圖更新
除了上述已完成的功能外，我們還在許多領域進行了工作，以使我們的長期路線圖取得進展。
大型 Monorepo 的 IDE 和分析器效能
「Monorepo」是對一組相關套件和應用程式進行建構的常見方式，將所有程式碼都放在同一個儲存庫中，例如 Flutter 的 套件儲存庫。Monorepo 不僅僅是將所有程式碼「放在一起」的便利性，而且還是確保儲存庫中單獨的套件和應用程式相互相容的關鍵工具。
我們從在大型 Monorepo 中工作的開發人員那裡收到了持續的回饋，表示我們的工具（特別是分析器）的效能可能存在缺陷。我們對這些問題的分析表明，根本問題在於我們最終會為每個套件及其 所有 相依關聯載入多個重疊的分析內容，導致儲存庫中每個套件的多次分析同時在記憶體中。我們認為根本的解決方案是在此類儲存庫中建立每個相依關聯版本的單一、共用解析，並且正在透過一個稱為 工作區 的新 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 使用者經常編寫的聲明式程式碼類型。舊的格式化程式無法產生那種輸出。重寫工作即將完成，並且很快就會發佈。如果您想嘗試一下，請使用 experiment 標誌 tall-style（標誌說明）。如果您看到奇怪的輸出，歡迎您 提供回饋。
結語
這就是我們今天要分享的內容。我們歡迎您提供回饋，無論是關於討論的路線圖項目，還是關於 Dart 3.5 中的新功能，這些功能可以在 Dart.dev 上獲得，或者捆綁在今天的 Flutter 3.24 版本 中。
宣布 Dart 3.5 以及 Dart 路線圖更新 最初發佈在 Dart 上的 Medium，人們在那裡透過突出顯示和回應這個故事來繼續討論。
undefined