Swift 週報 第二十四期

前言

本期是 Swift 編輯組自主整理週報的第十五期，每個模組已初步成型。各位讀者如果有好的提議，歡迎在文末留言。

歡迎投稿或推薦內容。目前計劃每兩週週一釋出，歡迎志同道合的朋友一起加入週報整理。

一個人真正覺悟的時候，就會去追尋內心世界真正的財富。Swift社群渴望走進你的內心，與你一起擁抱財富！

週報精選

新聞和社群：蘋果高管確認，新品即將上市

提案：圍繞 Macros 提出多個提案

Swift 論壇：新發布 VSCode devContainers 的新功能

推薦博文：使用 async/await 完成後臺任務管理

話題討論：

程式設計師養生喝什麼？

新聞和社群

蘋果高管確認，新品即將上市

眾所周知，蘋果對待還未正式釋出的產品，向來採取較為嚴格的保密政策。 不過，在去年 3 月舉辦的蘋果春季釋出會上，蘋果對新品的一波預告，似乎成了近些年來罕有的例外。

蘋果硬體工程高階副總裁 John Ternus 在釋出會結尾，暗示了即將要推出新款 Mac Pro 的訊息。

實際上這也並不稀奇，蘋果早在 2020 年就曾宣佈了一項「兩年計劃」，預計在兩年時間內將旗下所有 Mac 產品都轉向自研晶片，徹底拋棄英特爾。

而如今兩年之期已到，Mac 產品線中，也僅剩 Mac Pro 一款產品還未搭載 M 系晶片。

就在許多期待這款新 Mac 的小夥伴望眼欲穿之際，另一位蘋果高管為我們帶來了與之相關的最新訊息。

近期，蘋果全球產品營銷副總裁 Bob Borchers 接受了 India Today 的採訪，並針對一些產品問題進行了回覆。

Bob Borchers 表示，在將大部分 Mac 產品都搭載 M 系晶片後，現階段蘋果的「兩年計劃」還在進行中。

也就是說，蘋果的終極目標是將 Mac 產品線完成全系自研後，將自研晶片擴充套件至所有蘋果產品中，其中自然也包括新款 Mac Pro。

從這兩年的蘋果的一系列動作來看，推動 Mac 全面自研化的程序已經接近收官，目前只差 Mac Pro。

對等組基準指標現已在“App 分析”中釋出

App Store Connect 中的“App 分析”是一款實用的工具，它具備豐富的功能，可幫助你瞭解和改進你的 App 在 App Store 中的表現。藉助與獲客率、使用和盈利策略相關的指標，你可以通過“App 分析”監控客戶生命週期 (從認知到轉化再到留存) 中各個階段的結果。對等組基準指標會將你 App 的表現與 App Store 中類似的 App 進行比較，從今天開始，你可以使用此功能在有效情境中衡量 App 的表現。現在，你將獲得更多見解，更有效地發現業務增長機會。

對等組基準指標會在整個客戶旅程中提供獨到且實用的新見解，幫助你更準確地瞭解 App 在哪些方面表現出色，並找到改進的方向。系統會根據 App 的 App Store 類別、商業模式和下載量將 App 歸入不同的對等組中，以確保比較資料的相關性。此外，對等組基準指標使用行業領先的差分隱私技術，提供相關且切實可行的見解，同時確保單個 App 表現的私密性。

檢視新的基準指標資料，然後利用 App Store Connect 中的其他工具來改善轉化率、收益、崩潰率和使用者留存率。你可以測試產品頁上的不同元素以找出最能引起使用者共鳴的部分，創建出額外的產品頁版本以重點推介特定功能或內容，獲得有關 Beta 版 App 的反饋，提供 App 內活動以鼓勵參與，等等。

提案

正在審查的提案

SE-0382 Expression Macros 提案重新恢復審查。該提案已在 二十期週報 正在審查的提案模組做了詳細介紹。

SE-0388 增加 Async[Throwing]Stream.makeStream 方法 提案正在審查。

改天建議引入輔助方法來建立 AsyncStream 和 AsyncThrowingStream 例項，使開發者使用起來更加方便。

SE-0389 Attached Macros 提案正在審查。

Attached Macros 是 Swift 中 Macros 願景的一部分，該提案以 SE-0382 Expression Macros 的思想和動機為基礎，涵蓋了大量新的用例，將參考該提案以瞭解 Macros 如何整合到語言中的基本模型。

SE-0390 引入 @noncopyable 提案正在審查。

該提案引入了 @noncopyable 型別（也稱為 move-only 型別）的概念。 @noncopyable 型別的例項始終具有唯一所有權，這與可以自由複製的普通 Swift 型別不同。

SE-0391 Package Registry 公開發布 提案正在審查。

Package Registry 公開發布後，可以對外公開可用。 從 Swift 5.7 開始，SwiftPM 支援使用任何實現與 SE-0292 一起提出的服務規範的登錄檔的依賴項解析和包下載。

Swift論壇

1) 提議包管理器支援自定義巨集 介紹 巨集提供了一種通過對輸入原始碼執行任意句法轉換來生成新程式碼來擴充套件 Swift 的方法。 一個例子是之前在SE-0382 中提出的表示式巨集。該提案涵蓋了如何定義、構建和分發自定義巨集作為 Swift 包的一部分。 動機 SE-0382 和 A Possible Vision for Macros in Swift 涵蓋了巨集本身的動機，將它們定義為包的一部分將提供一種直接的方式來重用和分發巨集作為原始碼。 提議的解決方案 在外部程式中實現的巨集可以通過新的巨集目標型別宣告為包的一部分，定義在 CompilerPluginSupport 庫： Swift public extension Target { /// Creates a macro target. /// /// - Parameters: /// - name: The name of the macro. /// - dependencies: The macro's dependencies. /// - path: The path of the macro, relative to the package root. /// - exclude: The paths to source and resource files you want to exclude from the macro. /// - sources: The source files in the macro. static func macro( name: String, dependencies: [Dependency] = [], path: String? = nil, exclude: [String] = [], sources: [String]? = nil ) -> Target { } 類似於包外掛（SE-0303“包管理器可擴充套件構建工具”），巨集外掛被構建為主機的可執行檔案（即，執行編譯器的地方）。 編譯器從構建系統接收到這些可執行檔案的路徑，並將作為編譯過程的一部分按需執行它們。 巨集可執行檔案可自動用於任何通過包清單傳遞依賴於它們的目標。 包含巨集的實現、定義和客戶端的最小包如下所示： ```Swift import PackageDescription import CompilerPluginSupport

let package = Package( name: "MacroPackage", targets: [ .macro(name: "MacroImpl"), .target(name: "MacroDef", dependencies: ["MacroImpl"]), .executableTarget(name: "MacroClient", dependencies: ["MacroDef"]), ] ) ``` 巨集實現將在類似於 package plugins 的沙盒中執行，防止檔案系統和網路訪問。 這是一種鼓勵巨集不依賴於任何狀態的實用方法，除了它們被賦予擴充套件的特定巨集擴充套件節點及其子節點（但不是其父節點），以及巨集擴充套件上下文專門提供的資訊。 如果將來巨集需要訪問其他資訊，這將通過擴充套件巨集擴充套件上下文來實現，這也為編譯器提供了一種機制來跟蹤巨集實際查詢的資訊。

2) 新發布VSCode devContainers 的新功能 這些新功能它們讓我的生活更輕鬆，所以我將它們新增到可用容器的通用目錄中，以支援在 Swift:5.7 及更高版本中使用 .devContainer 設定。 具有三個獨立的功能： * jemalloc - 安裝 jemalloc 庫（如果你正在探索使用 package-benchmark 1 會很有幫助） * swiftpm - 安裝構建 SwiftPM 所需的 sqlite 和 libsqlite 庫 * foundationnetworking - 安裝 libcurl-openssl 以支援基礎網路

3) 提問如何測量結構例項的實際記憶體佔用量？ MemoryLayout.size(ofValue: theInstance) 但它只返回錯誤的大小（可能是指標的大小）。 將這個問題的範圍縮小到僅結構體。例如：測量僅包含結構體的字典結構佔用了多少記憶體。 回答： 一旦部分“值”沒有儲存在堆疊中，這個問題也變得沒有意義。 如果我說 let newDict = existingDict，佔用空間估計函式可能會說它們每個總共有 1024 個位元組，因此您可能會得出結論，它們加起來是 2048 個位元組。 但事實並非如此，因為 Dictionary 被記錄為像這樣的簡單副本共享儲存，直到一個值或另一個值發生變化； 實際總數大約是 1032 位元組。 同樣，您可以想象在這些字典中還嵌套了其他字典； 如果您修改其中一個頂級詞典，將分配新的儲存空間，但仍將共享巢狀詞典。 說“這個值能保持多少記憶體”絕對是有價值的，但在一種具有無處不在的引用計數（或垃圾收集，就此而言）的語言中，它沒有一個簡單的答案。

4) 討論為什麼有這麼多“@”表示式？ 我不是每天都使用 Swift，因為它實際上是 Apple 專用的語言。 所以當我最近回到它時，我發現了兩個新問題。 使用 Swift 5 編譯器編譯後執行良好的程式碼在使用 5.9-dev 編譯器構建時無法正確執行。 後者會產生以前不存在的執行時錯誤。 檢視一些示例程式碼，我看到比以前更多的 @ 表示式，例如 @frozen、@State、@stateobject 等。 有沒有完整的列表？ 這些都有什麼用？ 文件（在其存在的範圍內）含糊不清。 這些表示式不會降低程式碼的可讀性嗎？ 回答： 一些“@表示式”內置於編譯器中，如@available、@propertyWrapper、@dynamicMemberLookup。 大多數由 SwiftUI 等庫以 Property Wrappers 的形式提供 這些表示式不會降低程式碼的可讀性嗎？相反，與手卷替代方案相比，它們大大提高了可讀性。 屬性包裝器讓您可以提取自動應用於獲取或設定值的可重用行為（如 JS 2 中的處理程式方法或 Python 1 中的描述符）。 例如，每次寫入標記為@Published 的屬性時，您的 ObservedObject 都會自動發出一個 objectWillChange 事件。 如果 @Published 屬性包裝器不存在，程式碼中的 @ 符號就會減少，但您還需要在每次寫入屬性時執行類似 objectWillChangePublisher.send() 的操作。 這很費力，引入了瘋狂的重複和忘記這樣做的機會。 在不知不覺中，您會在論壇上看到類似以下的問題： 提問者：“為什麼當我更改此屬性時我的檢視沒有更新？” 回答者：“因為你忘記了 objectWillChangePublisher.send()。” 提問者：“為什麼框架不能自動為我呼叫它？” 因此，出現了屬性包裝器。

5) 提問SwiftUI 如何只啟動一次 onApper？

6) 提問選擇取消 macOS 上的自動 Foundation 連結？

7) GSoCSwift參加GSoC 2023！ 很高興與大家分享，Swift 將再次參加 Google Summer of Code 3！ 到現在為止，也許您已經看到潛在的參與者開始了一些話題 去年，我們設法運行了 5 個很棒且成功的專案。 如果您對它們是什麼感到好奇，您可以直接在 Swift 部落格 10 上從他們的參與者和導師那裡瞭解相關資訊。 今年，我們已經收集了一些潛在的專案想法以及他們自願參與 Swift 網站的導師：Swift.org - GSoC 2023 的專案想法 23。 今年我們準備了一個專門針對 GSoC 6 的新論壇類別，因為我們發現雖然有些專案有很好的空間來討論它（比如伺服器類別），但有些專案以前並沒有真正的討論空間（ 之後）他們開始了。 我們仍然鼓勵使用 gsoc-2023 標籤 2 來標記所有與 gsoc 相關的執行緒，並且並非所有執行緒都需要屬於這個新類別。 然而，這個類別應該有助於引導討論，否則沒有一個很好的歸宿。 與往常一樣，我們期待聽到您的專案想法，並建議在新論壇類別中開啟一個主題，描述您的專案想法以及您需要幫助以使其成為現實的領域。 如果某個專案看起來很有吸引力並且有可能在 GSoC 時間框架內實現，我們將盡最大努力為其尋找導師。 我們對有助於“Swift 專案”的專案感興趣，其中包括各個重點領域的各種專案。 以下是一些可能成為 GSoC 專案創意候選者的專案示例： Swift 編譯器 2 本身（型別檢查器、前端、後端、標準庫），專案可以包括改進除錯、效能、新增一個小功能， 相關包，如 Collections、Async Algorithms、SwiftSyntax、SourceKit-LSP、DocC、Distributed Actor Cluster 等 1， 主要由伺服器生態系統使用的包，包括為尚未支援的資料庫、佇列或其他 API 提議新的庫， Swift Package Manager 2、Swift 網站、文件或 Swift 的其他部分。 您可以在我們的 Swift 部落格上回顧去年的成功專案 10 ，瞭解接受了哪些型別的專案。 今年我們還為非 Apple 員工開放了導師角色。 如果您是一位經驗豐富的 Swift 貢獻者，並且有興趣作為 GSoC 導師為我們的參與者提供指導，請留意進一步的公告，或使用下面的聯絡方式與我聯絡。 這對我們來說是一個新流程，所以我們將看看它是如何運作的，但我們有興趣向更廣泛的 Swift 專案貢獻者開放指導。 作為 GSoC 體驗的一部分，我們也在考慮提供更多機會與其他 Swift 貢獻者會面。

8) GSoC有興趣使用 Swift 中的指令碼來改善使用者體驗

推薦博文

使用 async let 在 Swift 中並行執行後臺任務

摘要： 本文介紹瞭如何在後臺執行長期執行的任務並保持 UI 響應。async/await 提供了執行非同步任務的乾淨機制。允許並行執行多個後臺任務。

如何在 Swift 中取消後臺任務

摘要： Swift 5.5 中引入的 async/await 語法允許以可讀的方式編寫非同步程式碼。非同步程式設計可以提高應用程式的效能，同時很重要的一點是要取消不需要的任務，以確保暫時不需要的後臺任務不會干擾應用程式。本文演示瞭如何取消任務，並解釋瞭如何自動取消子任務。

如何在 Flutter 中使用 async/await

摘要： 在本文中展示了一系列非同步實現示例，並在最後給出三個元件（Future，async 和 await）的使用說明。

話題討論

程式設計師養生喝什麼？

歡迎在文末留言參與討論。

關於我們

Swift社群是由 Swift 愛好者共同維護的公益組織，我們在國內以微信公眾號的運營為主，我們會分享以 Swift實戰、SwiftUl、Swift基礎為核心的技術內容，也整理收集優秀的學習資料。

特別感謝 Swift社群 編輯部的每一位編輯，感謝大家的辛苦付出，為 Swift社群 提供優質內容，為 Swift 語言的發展貢獻自己的力量。

本文正在參加「金石計劃」