還有很多其他方法可以優化 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 應用程序。并非所有應用都適用于每個應用，也不是你所做的每件事都會顯著提高性能。有時問題很清楚，解決它們會使應用程序具有高性能，在其他情況下，問題很復雜，很難增加任何性能改進。但總而言之，優化你的代碼是一個有趣的旅程，你可以學到很多東西，大多數時候，學習一個交易技巧，你覺得為什么我之前不知道這一點?

　　經常花時間重構代碼，經常花時間評估性能，因為如果你不這樣做，它可能會突然變得太晚。