資訊專欄INFORMATION COLUMN
摘要：但是強迫癥犯了，為了使得性能達到極致，再次進行了深度的優化。把移動中心設置在物體的重力中心，最為舒適。你可以狠狠的點擊預覽地址到此，組件，無論從性能，還是手感上來說，都已經相當的符合我們的需求了。
倉庫地址：Dragact手感絲滑的拖拽布局組件
預覽地址：支持手機端噢～
上回我們說到，Dragact組件已經進行了一系列的性能優化，然而面對大量數據的時候，依舊比較吃力，讓我們來看看，優化之前的Dragact。
縱向堆疊著314個方塊，插入時明顯的卡頓，大約1秒的延遲
同樣縱向堆疊著314個方塊，插入時卡頓明顯減少很多，可以接受
在實際生產過程中，可能不會有那么多物塊，就拿我們項目的dashboard來說，整個屏幕最多只有10個方塊，就已經是了不起了。
但是強迫癥犯了，為了使得性能達到極致，再次進行了深度的優化。
React優化的策略有哪些呢？
策略一: shouldComponentUpdate()因為React 的diff只是簡單的深度優先+刷新策略去diff html tag，所以數據的改變，React是不會知道的。
因此，開發者必須得自己去diff數據，shouldComponentUpdate就是用來diff數據的一個特殊聲明周期函數。
具體的，請看我之前的回答和徐飛叔的回答：
方正：Vue為什么沒有shouldComponentUpdate的生命周期？
徐飛：Vue為什么沒有shouldComponentUpdate的生命周期？
策略二：用記憶功能函數去緩存大量計算結果有很多情況下，我們的遍歷是不可避免的。
React中最著名性能問題，就是selector問題，現在大家也都知道用reselect去做性能優化了，但是本質呢？
我們寫一點偽代碼來做演示：
//首先，我們有一個斐波那契生成函數 fib();
//用戶想用的時候，就會去掉這個函數
const number = fib();
//我們知道，fib()函數里面會經過大量的計算，才得出我們想要的結果
//但是，除了第一次計算之外，之后的所有計算都是不需要的，因為我們已經在一開始拿到結果了
//怎么做最好呢？閉包;
const Fib = function (){
var cache = void 666;
return function(){
if(!cache){
cache = fib();
return cache;
}
return cache;
}
}();
//當用戶調用Fib的時候，只會在第一次進行計算，之后的后只會從cache中拿出來。
不要小看這種優化，很多時候，我們大量重復的遍歷就會導致性能的低下。
策略三：減少dom的深度我們都知道，每次react 更新的時候，都會進行diff，深度越大，diff的層次越多。
減少diff的層次是非常重要的性能優化手段，尤其是數據量巨大的時候。
具體怎么去減少dom的深度，方法有很多，我用的方法是：render children的辦法。
簡單的舉個例子，拖拽組件：
這樣的一個設計，看似很簡單，很明了。用Dragger組件去包囊我們想要的組件，就可以讓其獲得拖拽的屬性。
這么做不是不行，但是很多時候我們在設計之初，沒考慮那么多，就會使用這樣一種方式去設計：
class Dragger extends Component{
moving(){}......
render(){
return (
{this.props.children}
)
}
}
是不是很常見？這么做的問題其實很明顯，就是無緣無故的，我們多了一層div，組件一多，那么就多會了幾層div，無疑造成了渲染壓力。
使用render children，我們可以這么設計
class Dragger extends Component{
moving(){}......
render(){
const provided = {
onMouseDown:this.onMouseDown
onTouchDown:this.onTouchDown
style:{....}
}
return this.props.children(provided);
}
}
在外部使用的時候，就變成了：
{(provided)=> 我是拖拽的組件}
看似稍微蛋疼了一些，但是好處就是：減少了dom的層級。
還有更多好處，可以看之前的一篇文章：React組件：拖拽布局Dragact v0.1.6 發布
手感的優化看似很標準，實際上用戶需要拖動很遠，才會物體進行交換
看似很標準，實際上用戶需要拖動很遠，才會物體進行交換，造成這樣讓人不適的感覺原因是因為計算時，我取的計算中心永遠是物體的頂邊。
所以，當物體向下滑動的時候，必須要物體的頂邊到達下一個物塊的中心才能發生交換。
上圖我們可以看到，長條的物塊，已經拖出了屏幕很遠，才會進行交換。
就這一點點差異，讓我頓時感到不爽！
為了使得手感更加優異，做了大量實驗以后，我發現，把移動中心設置在物體的重力中心，最為舒適。
把移動中心設置在物體的重力中心，最為舒適。
這一點點設計的改變，使得手感完全不同了。
你可以狠狠的點擊：預覽地址
到此，Dragact組件，無論從性能，還是手感上來說，都已經相當的符合我們的需求了。
yeah~
各位，我們下次見。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/93025.html
摘要：但是強迫癥犯了，為了使得性能達到極致，再次進行了深度的優化。把移動中心設置在物體的重力中心，最為舒適。你可以狠狠的點擊預覽地址到此，組件，無論從性能，還是手感上來說，都已經相當的符合我們的需求了。 倉庫地址：Dragact手感絲滑的拖拽布局組件 預覽地址：支持手機端噢～ 上回我們說到，Dragact組件已經進行了一系列的性能優化，然而面對大量數據的時候，依舊比較吃力，讓我們來看看，優化...
摘要：新特性性能提升通過對組件渲染的優化以及內部算法的優化，把大量的遍歷和渲染都省掉。新特性不一樣的掛件渲染依賴注入式的掛件可以從最簡單的例子看出，我們渲染子組件的方式和以往有些不同。通過獲取組件的實例，我提供了一個，用于獲取當前的布局信息。 showImg(https://segmentfault.com/img/remote/1460000013377768?w=600&h=375); ...
摘要：新特性性能提升通過對組件渲染的優化以及內部算法的優化，把大量的遍歷和渲染都省掉。新特性不一樣的掛件渲染依賴注入式的掛件可以從最簡單的例子看出，我們渲染子組件的方式和以往有些不同。通過獲取組件的實例，我提供了一個，用于獲取當前的布局信息。 showImg(https://segmentfault.com/img/remote/1460000013377768?w=600&h=375); ...
摘要：造輪子的一些思考首先，我們的需求是用戶能夠方便的調整后臺的各種表盤位置。內的所有組件必須不能重疊，還要能自動排序某些組件要可以設定靜態的，也就是固定在那里，不被布局的任何變動而影響。為了快速獲得這種心態的轉變，你要做的就是造輪子。 先來一張圖看看： showImg(https://segmentfault.com/img/remote/1460000013305417?w=600&h=...
閱讀 1290·2021-11-24 09:39
閱讀 2632·2021-09-30 09:47
閱讀 1325·2021-09-22 15:15
閱讀 2410·2021-09-10 10:51
閱讀 1954·2019-08-30 15:55
閱讀 2977·2019-08-30 11:06
閱讀 896·2019-08-30 10:53
閱讀 830·2019-08-29 17:26
