# 性能優化
在內部，React 使用一些聰明的技巧來最小化昂貴的 DOM 操作需求來更新 UI。對于許多應用，使用 React 可以生成一個快速的用戶交互界面而不用做太多工作進行特別優化性能。閉關i平。有幾種方式可以加速你的 React 應用。
## 使用產品化構建
If you're benchmarking or experiencing performance problems in your React apps, make sure you're testing with the minified production build:
如果你在你的 React 應用中測試或者體驗性能問題，確保你使用了壓縮的產品化構建：
對于創建 React App，需要運行 npm run build 并遵循說明
對于單文件版本，我們提供了產品化之后的 .min.js 版本
對于 Browserify，你需要運行它，使用 NODE_EVN=production
對于 Webpack，需要添加這個到產品化配置文件的 plugins 中：
* For Create React App, you need to run npm run build and follow the instructions.
* For single-file builds, we offer production-ready .min.js versions.
* For Browserify, you need to run it with NODE_ENV=production.
* For Webpack, you need to add this to plugins in your production config:
~~~
new webpack.DefinePlugin({
'process.env': {
NODE_ENV: JSON.stringify('production')
}
}),
new webpack.optimize.UglifyJsPlugin()
~~~
開發版本包括了額外的警告，可以在構建應用時提供幫助，但是由于額外的這些記錄，會導致變慢。
## 避免 調節 （Avoid Reconciliation ）
React 構建和維護一個內部的渲染 UI 的表征。它包括你從組件中返回的 React 元素。這個表征使得 React 避免創建 DOM 節點和訪問必要之外的現存的節點，因為這個可能慢于操作 JavaScript 對象。有時它被引用作為一個 “虛擬DOM”，但是它和 React Native 以同樣方式運行。
當一個組件的 props 或者 state 改變，React 通過跟前一個渲染的元素對比最新的返回元素決定是否一個實際的 DOM 更新被需要。當它們不相等，React 則更新 DOM 。
在一些情況下，你的組件可以通過重寫生命周期函數 shouldComponentUpdate 進行加速，它在重新渲染過程開始之前被觸發。這個函數默認的實現返回 true ，使 React 來執行更新：
~~~
shouldComponentUpdate(nextProps, nextState) {
return true;
}
~~~
如果你知道在一些情況下你的組件不需要更新，你可以從 shouldComponentUpdate 返回 false 來替代，以跳過整個渲染過程，包括在這個組件上及其下調用 render() 。
## shouldComponentUpdate 運行
這是一個子樹的組件。對于每個，SCU 表示 shouldComponentUpdate 的返回值，vDOMEq 表示是否渲染的 React 元素是等效的。最終，圓圈的顏色代表是否組件需要被調節或者不需要。
由于在 C2 的子樹 shouldComponentUpdate 返回 false，React 不會試圖渲染 C2，因此甚至不用在 C4 和 C5 調用 shouldComponentUpdate 。
對于 C1 和 C3，shouldComponentUpdate 返回 true ，所以 React 必須向下檢查它們。對于 C6 shouldComponentUpdate 返回 true，而且由于渲染的元素不相同，React 必須更新 DOM 。
The last interesting case is C8. React had to render this component, but since the React elements it returned were equal to the previously rendered ones, it didn't have to update the DOM.
Note that React only had to do DOM mutations for C6, which was inevitable. For C8, it bailed out by comparing the rendered React elements, and for C2's subtree and C7, it didn't even have to compare the elements as we bailed out on shouldComponentUpdate, and render was not called.``
