還有很多其他方法可以優化 React 應用程序。并非所有應用都適用于每個應用,也不是你所做的每件事都會顯著提高性能。我最近被分配了一個任務,上面寫著“提高應用程序的性能”。這是我在記錄這段旅程。
步驟 1 — 查找性能開始下降的方案
我很幸運,當我被告知性能下降如此之大以至于用戶體驗絕對無法忍受時,我被告知了這種情況。要找出所有此類方案,需要嚴格地繼續在應用程序上執行各種操作,并在性能開始下降時繼續監視。沒有直接的方法可以做到這一點,唯一的方法是讓越來越多的人使用該應用程序并報告他們的經歷。另一種方法也可能是生成大量虛擬數據,并嘗試將所有這些數據加載到UI上,看看它的表現如何。此外,不要指望一次找到所有方案,你會不時發現它們,然后你可以執行以下步驟來提高每個方案的性能。
步驟2 - 調試并嘗試找到真正的罪魁禍首
下一步是調試并查看真正導致性能滯后或下降的原因。為此,你可以在開發工具中使用探查器,還可以突出顯示在特定操作上重新呈現的所有組件。對我來說,這兩個效果最好,因為它們可以幫助我理解重新渲染的內容,并且分析器也會告訴您原因。探查器還將告訴你哪些組件需要多少時間來呈現,以及你的應用總共需要多少周期才能達到就緒狀態。此外,如果我看到嵌套循環并查看這些循環是否花費大量時間才能完成,我也使用javascript中的conport.time()方法。在我的場景中,我得到了一些提醒,即我們使用的 React 上下文導致了主要問題。
單擊此處閱讀有關 React 分析器的所有信息。
步驟 3 — 使用以下技術提高性能
在本節中,我將列出我所做的幫助我提高應用性能的操作。
從狀態中刪除了實際上不需要重新渲染組件的變量:
我們有兩個上下文,并且大約有10-15個狀態變量。這樣做的問題是,每次由于setState而重新渲染上下文時,它都會繼續進行并導致使用上下文的所有子項重新渲染。我刪除了所有沒有理由繼續重新呈現組件的狀態變量,我還刪除了作為值傳遞給上下文提供程序的所有變量,這些變量可以派生或未在整個應用中的任何地方使用。這是一個重要的學習,我們傾向于把一切都放在上下文中,而你應該只添加你真正需要的東西。
在正確的地方使用了上下文:
我看到在一些組件中,我們調用了上下文,但沒有真正使用上下文的任何屬性。相反,我們將其作為道具傳遞給子組件。這會導致大量重新呈現,因為在上下文中重新呈現會觸發組件 A 重新呈現,這將導致組件 B、C 和 D 的所有子級重新呈現。只有組件 D 中才需要上下文,因此我直接將上下文移動到子組件。我對我看到的每個地方都這樣做了,上下文變量作為 prop 傳遞給子組件。
添加了空值和空檢查:
我看到我們呈現了一個子組件,該子組件需要來自父組件和子組件內部的一些數據,該組件添加了對存在數據的檢查。這種方法沒有錯,但是如果子組件作為少數組件使用Effects或正在調用其他API,則將數據作為空/空檢查移動到父組件是有意義的。您根本不需要將子組件呈現給 DOM,因為它沒有值。這將節省應用在呈現子項并調用其中的所有掛鉤和 API 時可能遇到的所有性能影響。
重構代碼:
我執行的一個一般步驟是嘗試理解編寫的代碼,特別是在數據作或添加到數組中,或者我們使用嵌套循環等。將數組轉換為有意義的映射,進一步從use中刪除變量效果依賴項數組,因為它們沒有添加任何值,最后還刪除了對沒有多大意義的數據的檢查。對于不同的應用程序,此步驟可能會有所不同,并且必須非常小心地完成,因為您不希望破壞已經工作的內容。因此,理想情況下,嘗試盡可能深入地首先理解邏輯,然后如果您有信心,請繼續重構它。
結論
使用上述方法,我能夠為我的應用減少大約 25-30 次重新渲染。將初始頁面加載時間縮短了幾秒鐘,并將響應時間縮短了一兩秒(在性能受到重大影響的情況下)。這是一段旅程,我仍在努力讓它變得更好:D
最后,還有很多其他方法可以優化 React 應用程序。并非所有應用都適用于每個應用,也不是你所做的每件事都會顯著提高性能。有時問題很清楚,解決它們會使應用程序具有高性能,在其他情況下,問題很復雜,很難增加任何性能改進。但總而言之,優化你的代碼是一個有趣的旅程,你可以學到很多東西,大多數時候,學習一個交易技巧,你覺得為什么我之前不知道這一點?
經?;〞r間重構代碼,經常花時間評估性能,因為如果你不這樣做,它可能會突然變得太晚。