Swift 週報 第二十四期

語言: CN / TW / HK

前言

本期是 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 方法 提案正在審查。

改天建議引入輔助方法來創建 AsyncStreamAsyncThrowingStream 實例,使開發者使用起來更加方便。

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-0382A 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

摘要: 在本文中展示了一系列異步實現示例,並在最後給出三個組件(Futureasyncawait)的使用説明。

話題討論

程序員養生喝什麼?

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

關於我們

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

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

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