Electron 專案將在 2024 年 12 月暫停，然後在 2025 年 1 月恢復全速運作。

透過 GIPHY

十二月將維持不變的事項​

1. 零時差漏洞和其他主要的安全相關版本將在必要時發布。安全事件應透過 SECURITY.md 進行報告。
2. 行為準則報告和審核將繼續進行。

十二月將有所不同的事項​

1. 2024 年的最後一個穩定分支版本（包括 Electron 31、32 和 33）將在 12 月 1 日的那週發布。12 月將不會有其他計畫的版本發布。
2. 12 月最後兩週沒有 Nightly 和 Alpha 版本。
3. 除了少數例外，沒有任何提取請求審核或合併。
4. 任何儲存庫都不會進行問題追蹤器更新。
5. 維護人員不會在 Discord 上提供偵錯協助。
6. 沒有社群媒體內容更新。

2025 年見！

Electron 專案將在 2023 年 12 月暫停，然後在 2024 年 1 月恢復全速運作。

透過 GIPHY

十二月將維持不變的事項​

1. 零時差漏洞和其他主要的安全相關版本將在必要時發布。安全事件應透過 SECURITY.md 進行報告。
2. 行為準則報告和審核將繼續進行。

十二月將有所不同的事項​

1. Electron 28.0.0 將於 12 月 5 日發布。在 Electron 28 之後，12 月將不會有新的穩定版本發布。
2. 12 月最後兩週沒有 Nightly 和 Alpha 版本。
3. 除了少數例外，沒有任何提取請求審核或合併。
4. 任何儲存庫都不會進行問題追蹤器更新。
5. 維護人員不會在 Discord 上提供偵錯協助。
6. 沒有社群媒體內容更新。

展望未來​

這已是我們第三年進行靜默期實驗，到目前為止，我們在平衡一個月的休息時間與維持之後的正常發布節奏方面取得了很大的成功。因此，我們已決定將此作為我們未來發布日曆的常規部分。我們仍然會在每個日曆年的最後一個穩定版本中加入提醒。

2024 年見！

第一個提交到 electron/electron 儲存庫的時間是 2013 年 3 月 13 日¹。

經過 10 年和 1192 位獨特貢獻者的 27,147 次提交，Electron 已成為當今建置桌面應用程式最受歡迎的框架之一。這個里程碑是慶祝和反思我們迄今為止的旅程，並分享我們一路學到的經驗的絕佳機會。

如果沒有每位投入時間和精力為專案做出貢獻的人，我們今天就不會在這裡。儘管原始碼提交始終是最可見的貢獻，但我們也必須承認那些報告錯誤、維護使用者領域模組、提供文件和翻譯以及參與網路空間中 Electron 社群的人們的努力。每一項貢獻對我們維護者來說都非常寶貴。

在我們繼續進行部落格文章的其餘部分之前：謝謝您。❤️

我們是如何走到這裡的？​

Atom Shell 是作為 GitHub Atom 編輯器的骨幹而建置的，該編輯器於 2014 年 4 月公開測試發布。它從頭開始建置，作為當時可用的基於網路的桌面框架（node-webkit 和 Chromium Embedded Framework）的替代方案。它有一個殺手級功能：嵌入 Node.js 和 Chromium，為網路技術提供強大的桌面執行階段。

在一年內，Atom Shell 的功能和受歡迎程度開始大幅成長。大型公司、新創公司和個別開發人員都開始使用它建置應用程式（一些早期採用者包括 Slack、GitKraken 和 WebTorrent），並且該專案被恰當地更名為 Electron。

從那時起，Electron 就開始快速發展，從未停歇。以下是我們隨著時間推移的每週下載量，數據來自 npmtrends.com

Electron v1 於 2016 年發布，承諾提高 API 穩定性，並提供更好的文件和工具。Electron v2 於 2018 年發布，引入了語義化版本控制，讓 Electron 開發人員更容易追蹤發布週期。

到了 Electron v6，我們轉為配合 Chromium 的發布週期，定期每 12 週進行一次主要版本發布。這個決定改變了專案的心態，將「擁有最新的 Chromium 版本」從可有可無變成優先事項。這減少了升級之間的技術債務，使我們更容易保持 Electron 的更新和安全。

從那時起，我們就像一台運轉良好的機器，在每次 Chromium 穩定版發布的同一天發布新的 Electron 版本。當 Chromium 在 2021 年將發布週期加速到 4 週時，我們也能輕鬆地將發布週期相應地增加到 8 週。

我們現在已經到了 Electron v23（並且還在持續增加），並且仍然致力於為建構跨平台桌面應用程式打造最佳的執行環境。即使近年來 JavaScript 開發工具蓬勃發展，Electron 仍然是桌面應用程式框架領域中穩定且經過實戰考驗的支柱。如今，Electron 應用程式無處不在：你可以使用 Visual Studio Code 進行程式設計、使用 Figma 進行設計、使用 Slack 進行溝通，以及使用 Notion 進行筆記（還有許多其他使用案例）。我們為這項成就感到非常自豪，並感謝所有讓這一切成為可能的人。

我們一路走來學到了什麼？​

通往十年里程碑的道路漫長而曲折。以下是一些幫助我們運行一個可持續的大型開源專案的關鍵要素。

透過治理模型擴展分散式決策​

我們必須克服的一個挑戰是，當 Electron 初次爆紅後，如何處理專案的長期發展方向。我們如何處理一個由數十位分佈在不同公司、國家和時區的工程師組成的團隊？

在早期，Electron 的維護者團隊依賴非正式的協調，這對於較小的專案來說快速且輕量，但無法擴展到更廣泛的協作。2019 年，我們轉為採用治理模型，其中不同的工作組有正式的責任領域。這對於簡化流程以及將專案所有權的部分分配給特定的維護者至關重要。現在每個工作組 (WG) 的責任是什麼？

• 發布 Electron 版本（發布工作組）
• 升級 Chromium 和 Node.js（升級工作組）
• 監督公共 API 設計（API 工作組）
• 保持 Electron 安全（安全工作組）
• 運行網站、文件和工具（生態系統工作組）
• 社群和企業拓展（拓展工作組）
• 社群管理（社群與安全工作組）
• 維護我們的建置基礎設施、維護者工具和雲端服務（基礎設施工作組）

在我們轉向治理模型的同時，我們也將 Electron 的所有權從 GitHub 轉移到 OpenJS 基金會。雖然最初的核心團隊現在仍然在 Microsoft 工作，但他們只是構成 Electron 治理的更廣泛協作者群體的一部分。²

雖然這個模型並不完美，但它在全球疫情和大環境經濟逆風中非常適合我們。展望未來，我們計劃修改治理章程，以引導我們度過 Electron 的第二個十年。

社群​

開源的社群部分很困難，尤其是當您的拓展團隊只是十幾位穿著寫著「社群經理」字樣風衣的工程師時。也就是說，身為一個大型開源專案意味著我們有很多使用者，而利用他們的能量來為 Electron 建立使用者生態系統，是維持專案健康至關重要的一部分。

我們為了發展社群影響力做了哪些努力？

建立虛擬社群​

• 2020 年，我們啟動了社群 Discord 伺服器。我們之前在 Atom 的論壇中設有一個版塊，但決定建立一個更非正式的訊息平台，讓維護者和 Electron 開發人員可以進行討論，並提供一般除錯協助。
• 2021 年，在 @BlackHole1 的協助下，我們建立了 Electron 中國 使用者群組。這個群組對於 Electron 在中國蓬勃發展的科技領域的使用者成長至關重要，他們在這裡可以合作交流想法，並在我們的英語空間之外討論 Electron。我們也想感謝 cnpm，他們的工作是在他們的中國 npm 鏡像中支援 Electron 的每晚發布。

參與高知名度的開源計畫​

• 自 2019 年以來，我們每年都會慶祝 Hacktoberfest。Hacktoberfest 是由 DigitalOcean 組織的年度開源慶典，每年我們都會收到數十位熱情的貢獻者，他們希望在開源軟體中留下自己的印記。
• 2020 年，我們參與了 Google Season of Docs 的初始迭代，與 @bandantonio 合作重新設計了 Electron 的新使用者教學流程。
• 2022 年，我們首次指導了一位 Google Summer of Code 學生。@aryanshridhar 做了一些很棒的工作，重新設計了 Electron Fiddle 的核心版本載入邏輯，並將其打包工具遷移到 webpack。

自動化所有事情！​

今天，Electron 的治理團隊約有 30 位活躍的維護者。我們中只有不到一半是全職貢獻者，這意味著有很多工作要做。我們讓一切順利運行的訣竅是什麼？我們的座右銘是電腦很便宜，而人類的時間很昂貴。以典型的工程師方式，我們開發了一套自動化的支援工具，讓我們的生活更輕鬆。

Not Goma​

Electron 的核心程式碼庫是 C++ 程式碼的龐然大物，而建置時間一直是限制我們發布錯誤修復和新功能速度的因素。2020 年，我們部署了 Not Goma，這是 Google Goma 分散式編譯器服務的客製化 Electron 特定後端。Not Goma 處理來自授權使用者機器的編譯請求，並將處理程序分佈在後端的數百個核心上。它還會快取編譯結果，以便其他編譯相同檔案的人只需要下載預先編譯的結果。

自推出 Not Goma 以來，維護者的編譯時間已從數小時縮短到數分鐘。穩定的網路連線成為貢獻者編譯 Electron 的最低要求！

持續因素驗證​

持續因素驗證 (CFA) 是圍繞 npm 雙因素驗證 (2FA) 系統的一層自動化，我們將其與 semantic-release 結合使用，以管理我們各種 @electron/ npm 套件的安全和自動化發布。

雖然 semantic-release 已經自動化了 npm 套件發布流程，但它需要關閉雙因素驗證，或傳入繞過此限制的秘密權杖。

我們建置 CFA 以為 npm 2FA 提供基於時間的一次性密碼 (TOTP) 給任意 CI 作業，讓我們能夠利用 semantic-release 的自動化，同時保持雙因素驗證的額外安全性。

我們將 CFA 與 Slack 整合前端一起使用，讓維護者可以從他們擁有 Slack 的任何裝置驗證套件發布，只要他們手邊有 TOTP 產生器即可。

警長​

Sheriff 是我們編寫的開源工具，用於自動管理 GitHub、Slack 和 Google Workspace 的權限。

Sheriff 的主要價值主張是權限管理應該是一個透明的過程。它使用單個 YAML 設定檔，指定上述所有服務的權限。有了 Sheriff，在儲存庫上取得協作者身分或建立新的郵寄清單就像取得 PR 核准並合併一樣簡單。

Sheriff 還有一個稽核記錄，會發布到 Slack，警告管理員 Electron 組織中任何地方發生可疑活動。

…以及我們所有的 GitHub 機器人​

GitHub 是一個具有豐富 API 擴充性和第一方機器人應用程式框架的平台，稱為 Probot。為了幫助我們專注於工作中更具創造性的部分，我們建立了一套較小的機器人，幫助我們完成繁瑣的工作。以下是一些範例

• Sudowoodo 自動化 Electron 從開始到結束的發布流程，從啟動建置到將發布資產上傳到 GitHub 和 npm。
• Trop 透過嘗試根據 GitHub PR 標籤將修補程式 cherry-pick 到先前的發布分支，自動化 Electron 的回溯流程。
• Roller 自動化 Electron 的 Chromium 和 Node.js 相依性的滾動升級。
• Cation 是我們用於 electron/electron PR 的狀態檢查機器人。

總之，我們這個小小的機器人家族極大地提高了開發人員的生產力！

下一步是什麼？​

當我們作為一個專案進入第二個十年時，你可能會問：Electron 的下一步是什麼？

我們將與 Chromium 的發佈節奏保持同步，每 8 週發佈 Electron 的新主要版本，使框架與來自 Web 平台和 Node.js 的最新和最佳技術保持同步，同時為企業級應用程式保持穩定性和安全性。

我們通常會在即將推出的計畫變得具體時宣布相關消息。如果你想了解未來的版本、功能和一般專案更新，你可以閱讀我們的部落格並關注我們的社交媒體個人資料（Twitter 和 Mastodon）！

從 Electron 23 開始，Electron 將終止對 Windows 7、Windows 8 和 Windows 8.1 的支援。

根據 Chromium 的棄用政策，從 Electron 23 開始，Electron 將終止對 Windows 7、Windows 8 和 Windows 8.1 的支援。這與 Microsoft 終止對 Windows 7 ESU 和 Windows 8.1 extended 的支援時間於 2023 年 1 月 10 日一致。

Electron 22 將是最後一個支援早於 10 的 Windows 版本的 Electron 主要版本。Electron 23 及更新的主要版本將不支援 Windows 7/8/8.1。舊版本的 Electron 將繼續在 Windows 7 上運行，我們將繼續發布 Electron 22.x 系列的修補程式，直到 2023 年 5 月 30 日，屆時 Electron 將終止對 22.x 的支援（根據我們的支援時間表）。

為何要棄用？​

Electron 遵循計劃的 Chromium 棄用政策，該政策將在 Chromium 109 中棄用支援（在此處閱讀更多關於 Chromium 時間表的資訊）。Electron 23 將包含 Chromium 110，它將不支援舊版本的 Windows。

因此，包含 Chromium 108 的 Electron 22 將是最後一個受支援的版本。

棄用時間表​

以下是我們計劃的棄用時間表

• 2022 年 12 月：Electron 團隊將進入節日期間的靜默期
• 2023 年 1 月：所有受支援的發佈分支都接受與 Windows 7 和 8 相關的問題。
• 2023 年 2 月 7 日：Electron 23 發佈。
• 2023 年 2 月 8 日 - 2023 年 5 月 29 日：Electron 將繼續接受 Electron 23 之前受支援版本的修復。
• 2023 年 5 月 30 日：Electron 22 達到其支援週期的結束。

這對開發人員意味著什麼

• Electron 團隊將接受與 Windows 7/8/8.1 相關的問題和修復，適用於穩定的受支援版本，直到每個版本達到其支援週期的結束。
  • 這特別適用於 Electron 22、Electron 21 和 Electron 20。
• 對於早於 Electron 23 的 Electron 版本，將接受與 Windows 7/8/8.1 相關的新問題。
  • 任何較新的發佈版本都不會接受新問題。
• 一旦 Electron 22 達到其支援週期的結束，所有與 Windows 7/8/8.1 相關的現有問題都將被關閉。

下一步是什麼？​

如果您有任何問題或疑慮，請隨時寫信至 info@electronjs.org 與我們聯繫。您也可以在我們的官方 Electron Discord 中找到社群支援。

Electron 專案將於 2022 年 12 月暫停，然後於 2023 年 1 月恢復全速運轉。

透過 GIPHY

十二月將維持不變的事項​

1. 零日漏洞和其他主要的安全相關版本將根據需要發佈。安全事件應透過 SECURITY.md 回報。
2. 行為準則報告和審核將繼續進行。

十二月將有所不同的事項​

1. 12 月沒有新的穩定版本。12 月的最後兩週沒有夜間版和 Alpha 版發佈。
2. 除了少數例外，沒有任何提取請求審核或合併。
3. 任何儲存庫都不會進行問題追蹤器更新。
4. 維護人員不會在 Discord 上提供偵錯協助。
5. 沒有社群媒體內容更新。

為什麼會這樣？​

由於 2021 年 12 月靜默月的成功，我們希望在 2022 年再次實施。12 月仍然是大多數公司的靜默月份，因此我們希望讓我們的維護人員有機會充電。每個人都期待 2023 年，我們期望會有好事發生！我們鼓勵其他專案考慮類似的措施。

上個月，Electron 的維護人員團隊在加拿大溫哥華會面，討論了該專案在 2023 年及以後的方向。在會議室裡待了四天，核心維護人員和受邀的合作者討論了新的計畫、維護痛點和一般的專案健康狀況。

展望未來，團隊仍將全力致力於發布定期且快速的 Chromium 升級、修復錯誤，並讓 Electron 對每個人都更加安全和高效。我們還有一些令人興奮的專案正在進行中，我們很樂意與社群分享！

變革性的新 API​

Electron 專案中需要共識的主要 API 提案會經過徵求意見（RFC）流程，該流程由我們的 API 工作組成員審查。

今年，我們推動了兩項主要提案，這些提案有可能為 Electron 應用程式解鎖新的功能維度。這些提案具有高度實驗性，但以下是你可以期待的內容搶先看！

新的原生附加元件增強功能（C API）​

此提案概述了新的 Electron C API 層，該層將允許應用程式開發人員編寫自己的原生 Node 附加元件，這些元件與 Electron 的內部資源介面連接，類似於 Node 自己的 Node-API。有關擬議的新 API 的更多資訊可以在此處找到。

範例：使用 Chromium 資源為應用程式增壓​

許多 Electron 應用程式都維護自己的分支，以便直接與 Chromium 內部結構互動，否則這些內部結構將無法使用 vanilla（未修改）的 Electron 存取。透過在 C API 層中公開這些資源，此程式碼可以改為作為與 Electron 並行的原生模組存在，從而可能減少應用程式開發人員的維護負擔。

公開 Chromium 的 UI 層（Views API）​

在底層，Chrome 使用者介面（UI）的非網站部分（例如工具列、標籤或按鈕）是使用名為 Views 的框架建置的。Views API 提案將此框架的部分內容作為 Electron 中的 JavaScript 類別引入，最終目標是允許開發人員為其 Electron 應用程式建立非 Web UI 元素。這將防止應用程式必須拼湊 Web 內容。

使這組新 API 成為可能的基礎工作目前正在進行中。以下是您在不久的將來可以期待的一些第一件事。

範例：使用 WebContentsView 重構視窗模型​

我們計劃的第一個變更是在 Electron 的 API 介面上公開 Chrome 的 WebContentsView，它將取代我們現有的 BrowserView API（儘管有這個名稱，但它是與 Chromium Views 無關的 Electron 特定程式碼）。透過公開 WebContentsView，我們將擁有一個可重複使用的 View 物件，可以顯示 Web 內容，從而為將 BrowserWindow 類別製作成純 JavaScript 並消除更多的程式碼複雜性打開了大門。

儘管此變更沒有為應用程式開發人員提供許多新功能，但它是一個大型重構，可以消除底層的許多程式碼，簡化 Chromium 升級並降低主要版本之間出現新錯誤的風險。

如果您是應用程式中使用 BrowserViews 的 Electron 開發人員：別擔心，我們沒有忘記您！我們計劃使現有的 BrowserView 類別成為 WebContentsView 的墊片，以便在您轉換到較新的 API 時提供緩衝。

請參閱：electron/electron#35658

範例：使用 ScrollView 的可捲動 Web 內容​

我們在 Stack 的朋友們一直積極推動將 Chromium 的 ScrollView 元件暴露給 Electron 的 API。有了這個新的 API，任何子 View 元件都可以水平或垂直捲動。

儘管這個新 API 僅實現了一個較小的功能，但團隊的最終目標是建立一套實用 View 元件，作為建立更複雜的非 HTML 介面的工具包。

參與貢獻​

您是 Electron 應用程式開發人員，對這些 API 提案的任何一個感興趣嗎？雖然我們還沒準備好接收額外的 RFC，請隨時關注未來的更多詳細資訊！

Electron Forge v6 穩定版本發佈​

自框架建立以來，Electron 的建置工具生態系統主要由社群推動，並由許多小型單用途套件組成（例如 electron-winstaller、electron-packager、electron-notarize、electron-osx-sign）。儘管這些工具運作良好，但對於使用者來說，要將一個可用的建置流程拼湊起來是很令人卻步的。

為了幫助 Electron 開發人員建立更友善的體驗，我們建立了 Electron Forge，這是一個將所有現有工具整合到單一介面中的一體化解決方案。儘管 Forge 自 2017 年以來一直在開發中，但該專案在過去幾年中一直處於休眠狀態。然而，鑑於社群對 Electron 中建置工具狀態的回饋，我們一直努力發布下一代穩定的 Forge 主要版本。

Electron Forge 6 隨附一流的 TypeScript 和 Webpack 支援，以及一個可擴充的 API，允許開發人員建立自己的外掛程式和安裝程式。

敬請期待：即將發布公告​

如果您有興趣使用 Forge 建立專案，或使用 Forge 的可擴充第三方 API 建立範本或外掛程式，請隨時關注我們本月稍晚發布的 Forge v6 穩定版本官方公告！

下一步是什麼？​

除了上述內容外，團隊一直在思考許多探索性專案，以使 Electron 體驗對應用程式開發人員和最終使用者更好。我們還在嘗試更新工具、API 審查流程和增強的文件。我們希望在不久的將來分享更多消息！

Electron 21 及更高版本將啟用 V8 記憶體隔離區，這對某些原生模組有影響。

在 Electron 21 中，我們將在 Electron 中啟用 V8 沙箱指標，遵循 Chrome 在 Chrome 103 中做出相同決策。這對原生模組有一些影響。此外，我們先前在 Electron 14 中啟用了一項相關技術：指標壓縮。當時我們沒有太多討論它，但指標壓縮對 V8 最大堆疊大小有影響。

這兩項技術在啟用後，對安全性、效能和記憶體使用率有顯著的好處。但是，啟用它們也有一些缺點。

啟用沙箱指標的主要缺點是不再允許指向外部（「堆外」）記憶體的 ArrayBuffer。這表示依賴 V8 中此功能的原生模組需要重構，才能繼續在 Electron 20 及更高版本中運作。

啟用指標壓縮的主要缺點是V8 堆疊的最大大小限制為 4GB。確切的詳細資訊有點複雜—例如，ArrayBuffer 與 V8 堆疊的其餘部分分開計算，但有其自身的限制。

Electron 升級工作小組認為，指標壓縮和 V8 記憶體隔離區的好處大於缺點。這樣做主要有三個原因

1. 它使 Electron 更接近 Chromium。Electron 在複雜的內部細節（例如 V8 配置）中與 Chromium 的差異越小，我們就越不可能意外地引入錯誤或安全漏洞。Chromium 的安全團隊非常強大，我們希望確保充分利用他們的工作。此外，如果錯誤僅影響 Chromium 中未使用的配置，那麼修復它不太可能是 Chromium 團隊的優先事項。
2. 它效能更好。指標壓縮將 V8 堆疊大小減少高達 40%，並將 CPU 和 GC 效能提高 5%–10%。對於絕大多數不會遇到 4GB 堆疊大小限制，且不使用需要外部緩衝區的原生模組的 Electron 應用程式而言，這些是顯著的效能提升。
3. 它更安全。有些 Electron 應用程式執行不受信任的 JavaScript（希望遵循我們的安全建議！），對於這些應用程式，啟用 V8 記憶體隔離區可以保護它們免受一大類惡意的 V8 漏洞攻擊。

最後，對於確實需要較大堆疊大小的應用程式，有一些解決方法。例如，可以將一個禁用指標壓縮的 Node.js 副本包含在您的應用程式中，並將記憶體密集型工作移動到子進程。雖然有點複雜，但如果您的特定使用案例需要不同的權衡，也可以建立禁用指標壓縮的 Electron 自訂版本。最後，在不久的將來，wasm64 將允許在 Web 和 Electron 上使用 WebAssembly 建立的應用程式使用明顯超過 4GB 的記憶體。

常見問題​

我如何知道我的應用程式是否受到此變更的影響？​

嘗試使用 ArrayBuffer 包裝外部記憶體將在 Electron 20+ 中於執行階段崩潰。

如果您的應用程式中未使用任何原生 Node 模組，則您是安全的—不可能從純 JS 觸發此崩潰。此變更僅影響在 V8 堆疊外部分配記憶體（例如使用 malloc 或 new），然後使用 ArrayBuffer 包裝外部記憶體的原生 Node 模組。這是一個相當罕見的使用案例，但某些模組確實使用此技術，此類模組需要重構，才能與 Electron 20+ 相容。

我如何測量我的應用程式正在使用的 V8 堆疊記憶體量，以了解我是否接近 4GB 限制？​

在渲染器程序中，您可以使用 performance.memory.usedJSHeapSize，它將以位元組為單位傳回 V8 堆疊使用量。在主程序中，您可以使用 process.memoryUsage().heapUsed，它具有可比性。

什麼是 V8 記憶體隔離區？​

有些文件將其稱為「V8 沙箱」，但該術語很容易與 Chromium 中發生的其他種類的沙箱混淆，所以我將堅持使用「記憶體隔離區」這個術語。

有一種相當常見的 V8 漏洞利用方式，如下所示

1. 在 V8 的 JIT 引擎中發現錯誤。JIT 引擎分析程式碼，以便能夠省略緩慢的執行階段型別檢查並產生快速的機器碼。有時邏輯錯誤表示它錯誤地分析了此分析，並省略了它實際上需要的型別檢查—例如，它認為 x 是一個字串，但實際上它是一個物件。
2. 濫用這種混淆來覆寫 V8 堆疊內部的某些記憶體位，例如，指向 ArrayBuffer 開頭的指標。
3. 現在您有一個指向您喜歡的任何位置的 ArrayBuffer，因此您可以讀寫程序中的任何記憶體，甚至是 V8 通常無法存取的記憶體。

V8 記憶體籠是一種旨在明確防止此類攻擊的技術。其達成方式是不將任何指標儲存在 V8 堆積區。相反地，所有對 V8 堆積區內其他記憶體的參照，都儲存為從某個保留區域起始的偏移量。如此一來，即使攻擊者設法破壞 ArrayBuffer 的基底位址，例如透過利用 V8 中的型別混淆錯誤，他們所能做的最壞情況，也只是讀取和寫入籠內的記憶體，而他們可能本來就已經可以這樣做。關於 V8 記憶體籠的運作方式，還有很多可讀取的資訊，因此我在此不深入探討—最適合開始閱讀的地方可能是 Chromium 團隊的高階設計文件。

我想重構一個 Node 原生模組以支援 Electron 21+。我該怎麼做？​

有兩種方法可以重構原生模組，使其與 V8 記憶體籠相容。第一種是在將外部建立的緩衝區傳遞給 JavaScript 之前，先將它們複製到 V8 記憶體籠中。這通常是一個簡單的重構，但當緩衝區很大時，可能會很慢。另一種方法是使用 V8 的記憶體配置器來配置你打算最終傳遞給 JavaScript 的記憶體。這稍微複雜一些，但可以讓你避免複製，這意味著大型緩衝區會有更好的效能。

為了使說明更具體，以下是一個使用外部陣列緩衝區的 N-API 模組範例

// Create some externally-allocated buffer.
// |create_external_resource| allocates memory via malloc().
size_t length = 0;
void* data = create_external_resource(&length);
// Wrap it in a Buffer--will fail if the memory cage is enabled!
napi_value result;
napi_create_external_buffer(
    env, length, data,
    finalize_external_resource, NULL, &result);

當啟用記憶體籠時，這將會崩潰，因為資料配置在籠外。重構為將資料複製到籠內，我們得到

size_t length = 0;
void* data = create_external_resource(&length);
// Create a new Buffer by copying the data into V8-allocated memory
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// If you need to access the new copy, |copied_data| is a pointer
// to it!

這會將資料複製到 V8 記憶體籠內新配置的記憶體區域。此外，如果事後需要修改或參考新複製的資料，N-API 也可以提供指向新複製資料的指標。

重構為使用 V8 的記憶體配置器會稍微複雜一些，因為它需要修改 create_external_resource 函式，以使用由 V8 配置的記憶體，而不是使用 malloc。這可能或多或少可行，取決於你是否控制 create_external_resource 的定義。其概念是首先使用 V8 建立緩衝區，例如使用 napi_create_buffer，然後將資源初始化到 V8 配置的記憶體中。重要的是要保留對 Buffer 物件的 napi_ref，以確保資源的生命週期，否則 V8 可能會垃圾回收 Buffer，並可能導致使用後釋放錯誤。

Electron 正在變更其主要的 S3 儲存桶，你可能需要更新你的建置腳本

發生了什麼事？

大量的 Electron 建置成品會上傳到一個名為 gh-contractor-zcbenz 的 S3 儲存桶。作為 2020 年開始的持續基礎架構/所有權遷移的一部分，我們將變更所有使用 gh-contractor-zcbenz 的項目，從其在 S3 中的舊位置遷移到託管於 https://artifacts.electronjs.org 的新儲存系統。我們大多數資源使用的路徑前綴也略有變更。範例如下

變更前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib 變更後： https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib

這裡的重要變更是主機名稱已變更，以及 /atom-shell 前綴已變更。另一個範例，這次是針對偵錯符號

變更前： https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb 變更後： https://artifacts.electronjs.org/symbols/path/to/symbol.pdb

同樣地，主機名稱已變更，且 /atom-shell 前綴已變更。

這會如何影響你？

任何使用標準建置工具（如 electron-rebuild、electron-packager 或 @electron/get）的人都不必做任何事情。這應該是大多數人。

對於直接參照 S3 儲存桶的任何人，你必須更新你的參照，使其指向主機名稱並同時更新路徑。

那現有的資料呢？

gh-contractor-zcbenz 儲存桶上存在的大部分資料已複製到新的儲存系統中。這表示所有偵錯符號和所有標頭都已複製。如果你依賴該儲存桶中尚未複製的某些資料，請在 electron/electron 中提出問題並告知我們。

目前 gh-contractor-zcbenz S3 儲存桶不會被主動刪除。但是，我們無法保證該儲存桶會存活多久。我們強烈建議盡快更新以指向新的儲存桶。

Electron 專案將在 2021 年 12 月暫停，然後在 2022 年 1 月恢復全速運作。

透過 GIPHY

十二月將維持不變的事項​

1. 零日漏洞和其他主要的安全相關版本將根據需要發佈。安全事件應透過 SECURITY.md 回報。
2. 行為準則報告和審核將繼續進行。

十二月將有所不同的事項​

1. 12 月沒有新的 Beta 或 Stable 版本發布。12 月的最後兩週沒有 Nightly 版本發布。
2. 除了少數例外，沒有任何提取請求審核或合併。
3. 任何儲存庫都不會進行問題追蹤器更新。
4. 維護人員不會在 Discord 上提供偵錯協助。
5. 沒有社群媒體內容更新。

為什麼會這樣？​

簡而言之，雖然維護人員對專案感到高興並積極參與，但這個世界累了。12 月是大多數公司比較安靜的一個月，所以我們希望讓維護人員有機會充電。我們鼓勵其他專案考慮採取類似的措施。

我應該擔心 Electron 的未來嗎？​

不用。我們之所以能夠採取此步驟，是因為專案狀況良好。每個人都期待 2022 年，而且我們預期會發生好事！

從 2021 年 9 月開始，Electron 將每 8 週發布一個新的主要穩定版本。

在 2019 年，Electron 改為每 12 週發布一次，以符合 Chromium 的 6 週發布週期。最近，Chrome 和 Microsoft 都宣布了一些變更，導致我們重新考慮 Electron 目前的發布週期

1. Chromium 計劃每 4 週發布一個新的里程碑，從 2021 年 9 月 21 日的 Chrome 94 開始。 此發布週期還新增了一個每 8 週更新一次的擴展穩定選項，其中將包含所有更新的安全修正。

2. Microsoft Store 將要求基於 Chromium 的應用程式不早於 2 個主要版本。例如，如果 Chromium 最新發布的主要版本是 85，則任何基於 Chromium 的瀏覽器都必須至少使用 Chromium 版本 83 或更高版本。此規則包含 Electron 應用程式。

從 2021 年 9 月開始，Electron 將每 8 週發布一個新的主要穩定版本，以符合 Chromium 的 8 週擴展穩定版本發布。

我們第一個使用 Chromium 擴展穩定版本的版本將是 2021 年 9 月 21 日的 Electron 15。

知道發布週期變更會影響其他下游應用程式，我們希望盡快通知我們的開發人員社群。請繼續閱讀以了解更多關於我們 2021 年發布排程的詳細資訊。

Electron 15：臨時 Alpha​

由於我們最初的 Electron 15 版本是以非擴展穩定版本（Chromium 的擴展穩定版本是基於其偶數編號版本）為目標，因此我們需要變更我們最初的目標發布日期。然而，Electron 應用程式必須使用 Chromium 的最新 2 個主要版本才能被 Microsoft Store 接受，這使得等待兩個 Chromium 版本變得不可行。

根據這兩項要求，我們的團隊面臨了時間上的難題。將 Electron 15 移至包含 Chromium M94 將允許應用程式開發人員使用 Chromium 的第一個擴展穩定版本；然而，它也會將 beta 到 stable 的週期縮短至僅 3 週。

為了協助這種轉換，Electron 將為 Electron 15 版本提供一個臨時的 alpha 建置版本。此 alpha 建置版本將允許開發人員有更多時間測試和規劃 Electron 15 的發布，並提供比我們目前 Nightly 版本更穩定的建置版本。

alpha 通道建置版本將於 2021 年 7 月 20 日發布 Electron 15。它將於 2021 年 9 月 1 日轉換為 beta 版本，目標穩定版本為 2021 年 9 月 21 日。後續的 Electron 版本將不會有 alpha 版本。

2021 年發布計劃​

以下是我們目前 2021 年的發布排程

加入 alpha 通道將 Electron 15 啟動之前的開發時間從 3 週延長至 9 週 - 更接近我們新的 8 週週期，同時仍符合 Windows Store 提交的要求。

為了進一步協助應用程式開發人員，在 2021 年剩餘時間至 2022 年 5 月期間，我們也會將我們支援的版本政策從最新的 3 個版本擴展到最新的 4 個 Electron 版本。這表示即使你無法立即變更你的升級排程，較舊的 Electron 版本仍會收到安全更新和修正。

解決疑慮​

我們很早就發布此文章是有原因的，因為此發布週期變更的排定時間還很早。我們知道更快的發布週期將對 Electron 應用程式產生實際影響 - 其中一些應用程式可能已經覺得我們的主要版本發布週期很激進。

我們已嘗試解決以下常見疑慮

❓ 為什麼要進行此變更？為什麼不維持 12 週的發布週期？​

為了在 Electron 中提供最新版本的 Chromium，我們的排程需要追蹤他們的排程。有關 Chromium 發布週期的更多資訊，請參閱此處。

此外，目前 12 週的發布週期對於 Microsoft Store 的新提交要求是不可行的。即使是最新穩定版本的 Electron 應用程式，也會在大約兩週的時間內，因為新的安全要求而可能遭到拒絕。

每個新的 Chromium 版本都包含新功能、錯誤修正/安全性修正以及 V8 的改進。我們希望身為應用程式開發人員的您能及時獲得這些變更，因此我們的穩定版本發布日期將繼續與其他每個 Chromium 穩定版本一致。身為應用程式開發人員，您將比以往更早獲得新的 Chromium 和 V8 功能以及修正。

❓ 現有的 12 週發布時程已經很快了。團隊正在採取哪些步驟來讓升級更容易？​

更頻繁發布的一個優點是發布的版本較小。我們理解升級 Electron 的主要版本可能很困難。我們希望較小的版本每次發布會引入較少的 Chromium 和 Node 主要變更，以及較少的重大變更。

❓ 未來的 Electron 版本是否會有 alpha 發布版本？​

目前沒有計畫支援永久的 alpha 版本。此 alpha 版本僅適用於 Electron 15，旨在協助開發人員在縮短的發布期間內更輕鬆地升級。

❓ Electron 是否會擴展支援版本的數量？​

我們將把支援的版本策略從最新的三個版本擴展到最新的四個 Electron 版本，直到 2022 年 5 月 Electron 19 發布為止。在 Electron 19 發布後，我們將恢復支援最新的三個主要版本，以及 beta 和 nightly 版本。

有問題嗎？​

📨 如果您有任何問題或疑慮，請發送郵件至 info@electronjs.org 或加入我們的 Discord。我們知道這項變更將會影響許多應用程式和開發人員，您的回饋對我們非常重要。我們很想聽聽您的意見！