宣布 React Native 0.66
今天我們發布了 React Native v0.66,以支援 Android 12 和 iOS 15,並提供修正程式和一般更新。
今天我們發布了 React Native v0.66,以支援 Android 12 和 iOS 15,並提供修正程式和一般更新。
React Native 在提升行動開發標準方面非常成功,無論是在 Facebook 內部還是業界其他地方。隨著我們以新的方式與電腦互動以及新裝置的發明,我們希望 React Native 能為所有人服務。雖然 React Native 最初是為了建置行動應用程式而建立,但我們相信,專注於多個平台並針對每個平台的優勢和限制進行建置具有共生效應。當我們將這項技術擴展到桌上型電腦和虛擬實境時,我們看到了巨大的好處,並且我們很高興分享這對 React Native 未來的意義。
在過去一年中,我們的世界發生了巨大的變化,React Native 也不例外。我們歡迎新成員加入我們的團隊(我們很高興最終能親自見面!),我們的專案已經成熟,並且出現了新的機會。我們很高興在這篇文章和即將發表的其他文章中與您分享這一切!
在 Facebook,我們的團隊以半年為週期工作。每半年,我們都會檢討策略、制定計畫並在內部共享。今天,我們想與您,我們的社群分享我們下半年的計畫。
2021 下半年對 React Native 來說是令人興奮的半年。我們的重點領域包括培育社群、開始向開源社群推出全新架構以及推動技術向前發展。
今天我們發布了 React Native 0.65 版本,其中包含新版本的 Hermes、無障礙功能改進、套件升級及更多內容。
Hermes,Facebook 針對 React Native 優化的開源 JavaScript VM,已升級至 0.8.1 版。此版本中一些突出的功能包括
Intl
) 現在已內建於 Android 版 Hermes 中並預設啟用,每個 API 大小僅額外增加 57-62K(相較於 JSC 的 6MiB)。透過此變更,Hermes 使用者不再需要地區設定 Polyfill。非常感謝 @mganandraj 和 Microsoft 的其他合作夥伴推動實作以實現這一目標!Function.prototype.toString
的變更,修正了由於不正確的功能偵測而導致的效能下降,並支援原始程式碼注入用例。您可以在此處找到完整的 Hermes 變更日誌。
請按照此處的步驟,如果您尚未選擇將您的應用程式加入 Hermes,以利用這些新功能和優勢!
去年,Facebook 承諾 GAAD,以改善 React Native 中的無障礙功能。0.65 分享了此承諾的結果和其他無障礙功能的勝利!一些值得注意的變更包括
getRecommendedTimeoutMillis
API。這公開了使用者在 Android 無障礙功能選項中設定的偏好預設逾時值,適用於可能需要額外時間來檢閱或觸及控制項等的使用者。disabled
和 unselected
。您可以在此處追蹤或貢獻我們的未解決的無障礙功能問題!
react-native-codegen
版本 0.0.7
作為 package.json
中的 devDependency
。此版本包含來自 61 位貢獻者的超過 1100 次提交。感謝所有貢獻和支援此版本的人!您可以在此處找到完整的變更日誌。
自 Facebook 承諾 GAAD 承諾 使 React Native 更易於存取以來,已經過了一年,而該專案已超出我們的預期。我們很高興宣布此專案將在 2021 年繼續進行,並希望向大家更新我們目前的進度。在去年徹底分析 React Native 中的無障礙功能差距後,開始填補這些差距的工作。
我們從 90 個未解決的差距分析問題開始,從 2021 年 3 月專案在 GitHub 上啟動到現在
社群已關閉 11 個問題。
React Native 團隊已評估並關閉 19 個問題。
已合併 9 個提取請求。
已將 1 個提取請求合併到 React Native 文件中。
我們要感謝 React Native 社群在過去一年中為實現更易於存取的 React Native 所做的重大進展。每位貢獻者的努力都對改善 React Native 無障礙功能有所貢獻。
自我們與 GitHub 社群聯繫以來已經過了四週,我們提供了經過徹底審查的差距分析和問題清單,以改善 React Native 的無障礙功能。在 React Native 社群的幫助下,我們在改善無障礙功能方面已經取得了很大的進展。社群成員一直在幫助貢獻者、審查測試,並關注先前的無障礙功能問題。自 3 月 8 日以來,社群已關閉六個問題,包含四個提取請求,還有七個其他提取請求正在審查中。
在這些工作持續進行的同時,Facebook 的 React Native 和無障礙功能團隊正在評估在此倡議之前提交的無障礙功能錯誤和問題,以確定它們是否已包含在我們目前的差距分析中,或者是否有其他需要納入專案的問題。已經發現一個新問題並已移至專案中,另外四個問題直接對應到現有問題,預計透過解決解決其問題根本原因的現有問題,將關閉另外兩個問題。
感謝所有參與的社群成員。您們確實正在推動使 React Native 對所有人更易於存取!
今天我們發布了 React Native 0.64,其中包含對 iOS 版 Hermes 的支援。
Hermes 是一個開源 JavaScript 引擎,針對執行 React Native 進行了優化。它透過減少記憶體使用量、縮減下載大小並縮短應用程式變得可用或「可互動時間」(TTI) 來提高效能。
在此版本中,我們很高興宣布您現在也可以使用 Hermes 在 iOS 上建置。若要在 iOS 上啟用 Hermes,請在您的 Podfile
中將 hermes_enabled
設定為 true
,然後執行 pod install
。
use_react_native!(
:path => config[:reactNativePath],
# to enable hermes on iOS, change `false` to `true` and then install pods
:hermes_enabled => true
)
請記住,iOS 版 Hermes 支援仍處於早期階段。我們將其保留為選擇加入,因為我們正在進行進一步的基準測試。我們鼓勵您在自己的應用程式上試用,並讓我們知道它的運作情況如何!
內聯需求是一個 Metro 配置選項,透過延遲 JavaScript 模組的執行直到它們被使用時,而不是在啟動時執行,來改善啟動時間。
此功能已存在並被推薦作為選擇加入配置選項幾年了,列在我們文件的效能部分中。我們現在預設為新應用程式啟用此選項,以幫助人們擁有快速的 React Native 應用程式,而無需額外配置。
內聯需求是一個 Babel 轉換,它採用模組匯入並將其轉換為內聯。例如,內聯需求將此模組匯入呼叫從檔案的頂部轉換到它被使用的地方。
之前
import {MyFunction} from 'my-module';
const MyComponent = props => {
const result = MyFunction();
return <Text>{result}</Text>;
};
之後
const MyComponent = props => {
const result = require('my-module').MyFunction();
return <Text>{result}</Text>;
};
有關內聯需求的更多資訊,請參閱效能文件。
在過去一年中,Facebook 資助了 Major League Hacking fellowship,以支援對 React Native 的貢獻。Jessie Nguyen 和 Saphal Patro 新增了使用 Chrome DevTools 上的效能標籤來視覺化您的應用程式在使用 Hermes 時的執行情況的功能。
有關更多資訊,請查看新的文件頁面。
我們已將 Proxy 支援新增到 Hermes,以實現與流行的社群專案(如 react-native-firebase 和 mobx)的相容性。如果您一直在使用這些套件,您現在可以將您的專案遷移到 Hermes。
我們計畫在即將發布的版本中將 Hermes 設定為 Android 的預設 JavaScript 引擎,因此我們正在努力解決人們在使用 Hermes 時遇到的剩餘問題。如果還有其他問題阻礙您的應用程式採用 Hermes,請在 Hermes GitHub 儲存庫上開啟問題。
React 17 不包含新的開發人員導向功能或重大的重大變更。對於 React Native 應用程式,主要變更是一個 新的 JSX 轉換,使檔案不再需要匯入 React 才能使用 JSX。
有關 React 17 的更多資訊,請參閱 React 部落格。
感謝數百位貢獻者協助實現 0.64!0.64 變更日誌包含此版本中包含的所有變更。
在 2020 年 5 月,Facebook 是第一家承諾 GAAD 承諾 的公司,透過這樣做,他們承諾使無障礙功能成為 React Native 開源專案的核心部分。自 5 月以來,Facebook 花費時間仔細審查和記錄 React Native 內部的無障礙功能差距。到目前為止,差距分析已浮現 90 個問題,所有問題都已轉換為 GitHub 問題。
總體而言,我們發現 React Native API 為無障礙功能提供了強大的支援。但是,我們也發現許多核心組件尚未完全利用平台無障礙功能 API,並且缺少對某些平台特定功能的支援。
貢獻者的熱情和多樣性始終在 React Native 的開發中發揮關鍵作用,而這些無障礙功能差距是當前和新貢獻者的絕佳機會。如果您一直對貢獻 React Native 感興趣,我們鼓勵您加入我們,使 React Native 更易於存取。
為了表彰貢獻者的努力,當無障礙功能問題關閉並附加到提取請求時,貢獻者將從我們的社群經理那裡獲得在 Twitter 上的表揚。其提取請求被接受到程式碼庫中的貢獻者將在我們每月在 React Native 部落格上的問題更新中重點介紹。
請加入我們,使 React Native 對所有人更易於存取。
對需要更多努力的問題感興趣的貢獻者應造訪改善 React Native 無障礙功能專案頁面,以查看需要他們 React Native 知識的 GitHub 問題。
對更新 React Native 文件以反映正在關閉的無障礙功能差距感興趣的技術作家應造訪React Native 文件。
與可能能夠提供幫助的任何人分享此倡議!
在 Twitter 或 Facebook 上追蹤 React Native GAAD 承諾開源無障礙功能社群經理,以隨時了解進度。
去年,我們進行了使用者訪談並發送了調查,以了解更多關於人們如何以及何時使用 React Native 文件的資訊。透過從 24 次訪談和超過 3000 份調查回覆中收集的資料和指導,我們得以努力改進 React Native 的文件,並且我們很高興今天分享該進度
Pressable
和 React Native 組件介紹 文件非常感謝所有參與訪談、調查和我們文件工作的人!您的協作使這一切成為可能。
Facebook 的 React Native 團隊遵循一些原則,這些原則有助於確定我們如何優先處理我們在 React Native 上的工作。這些原則特別代表我們的團隊,並不一定代表 React Native 社群中的每個利害關係人。我們在此分享這些原則,以更透明地了解是什麼驅動我們、我們如何做出決策以及我們如何集中精力。
我們對 React Native 的首要任務是符合人們對每個平台的期望。這就是為什麼 React Native 渲染到平台原生元件的原因。我們重視原生外觀和風格,而不是跨平台一致性。
例如,React Native 中的 TextInput 渲染到 iOS 上的 UITextField。這確保了與密碼管理器和鍵盤控制的整合可以立即運作。透過使用平台原生元件,React Native 應用程式也能夠與 Android 和 iOS 新版本的設計和行為變更保持同步。
為了符合原生應用程式的外觀和風格,我們也必須符合其效能。這就是我們投入最雄心勃勃的努力的地方。例如,Facebook 創建了 Hermes,一個專為 Android 上的 React Native 從頭開始建置的全新 JavaScript 引擎。Hermes 顯著提高了 React Native 應用程式的啟動時間。我們也正在進行重大的架構變更,以優化執行緒模型,並使 React Native 更容易與原生程式碼互操作。
Facebook 應用程式中的數百個螢幕是使用 React Native 實作的。Facebook 應用程式被數十億人在各種裝置上使用。這就是為什麼 我們投資於大規模的最具挑戰性的問題。
在我們的應用程式中部署 React Native 讓我們能夠識別在較小規模下看不到的問題。例如,Facebook 專注於改善從最新的 iPhone 到許多舊世代 Android 裝置的廣泛裝置範圍內的效能。這種關注為我們的架構專案(如 Hermes、Fabric 和 TurboModules)提供了資訊。
我們已證實 React Native 也能擴展到大型組織。當數百名開發人員在同一個應用程式上工作時,逐步採用是必須的。這就是為什麼我們確保 React Native 可以一次採用一個螢幕的原因。很快地,我們將更進一步,讓現有原生螢幕的個別原生視圖也能遷移到 React Native。
專注於大規模擴展意味著我們的團隊目前沒有處理許多事情。例如,我們的團隊不推動 React Native 在業界的採用。我們也不會積極為我們看不到大規模的問題建立解決方案。我們很自豪我們有許多合作夥伴和核心貢獻者,他們能夠專注於社群中那些重要的領域。
良好的使用者體驗是迭代創建的。在運行的應用程式中,應該只需幾秒鐘就能看到程式碼變更的結果。 React Native 的架構使其能夠在開發期間提供近乎即時的回饋。
我們經常聽到團隊表示,採用 React Native 大幅提高了他們的開發速度。這些團隊發現,開發期間的即時回饋讓他們更容易嘗試不同的想法,並在不必為每個小變更中斷編碼過程的情況下,添加額外的潤飾。當我們對 React Native 進行變更時,我們會確保保留開發者體驗的這種品質。
即時回饋並不是 React Native 提高開發者速度的唯一方法。團隊可以利用快速成長的高品質開源套件生態系統。團隊還可以在 Android、iOS 和 Web 之間共享業務邏輯。這有助於他們更快地發布更新,並減少平台團隊之間的組織孤島。
當我們在 2014 年推出 React Native 時,我們以「一次學習,隨處編寫」的座右銘呈現它 — 而我們指的是任何地方。開發人員應該能夠接觸到盡可能多的人,而不受設備型號或作業系統的限制。
React Native 的目標平台非常廣泛,包括行動裝置、桌面電腦、Web、電視、VR、遊戲主機等等。我們希望在每個平台上實現豐富的體驗,而不是要求開發人員為最低公分母而建置。為了實現這一點,我們專注於支援每個平台的獨特功能。這涵蓋了從不同的輸入機制(例如觸控、筆、滑鼠)到根本不同的消費體驗,例如 VR 中的 3D 環境。
這個原則影響了我們決定以跨平台的 C++ 實作 React Native 新核心架構,以促進跨平台的一致性。我們也在改進針對其他平台維護者(例如 Microsoft 的 Windows 和 macOS)的公共介面。我們力求使任何平台都能支援 React Native。
我們不相信在每個平台上部署完全相同的使用者介面,我們相信使用相同的宣告式程式設計模型來展現每個平台的獨特功能。我們的宣告式程式設計模型是 React。
根據我們的經驗,React 普及的單向資料流使應用程式更容易理解。我們更喜歡將螢幕表示為宣告式元件的組合,而不是命令式管理的視圖。React 在 Web 上的成功以及新的原生 Android 和 iOS 框架的方向表明,業界也已接受宣告式 UI。
React 普及了宣告式使用者介面。然而,仍然存在許多 React 獨特地定位來解決的未解決問題。React Native 將繼續在 React 的創新基礎上發展,並保持在宣告式使用者介面運動的最前沿。