性能優(yōu)化的問題
我的優(yōu)化代碼如下：
//????優(yōu)化balls數(shù)組
????????????var?count=0;
????????????for(var?i=0;i<balls.length;i++)?{
???????????????if?(balls[i].x?<?-R?||?balls[i].x?>?WINDOW_WIDTH?+?R)?{
????????????????????balls.splice(i,1);
????????????????}
????????????}這樣思維比較簡(jiǎn)單，就是把不符合要求的小球清除出去。
但是實(shí)際運(yùn)行效果是，balls的長(zhǎng)度大概維持在450-500之間。
我覺得這兩個(gè)效果大概是一樣的啊。這是不是說明這樣寫的性能不是很高？
為什么會(huì)有這個(gè)性能上的區(qū)別？
2015-06-02
我也出現(xiàn)下圖的情況。所以增加了一個(gè)大于1000個(gè)球的判斷。
? ? while(balls.length > cnt || balls.length > 1000){ //刪除cnt-1 后面的球 .刪除超過1000的球
? ? ? ? balls.pop();
? ? }
2015-09-18
算法的復(fù)雜度問題了~謝謝
2015-08-21
我想這樣做的效率應(yīng)該是比較低的，我不知道splice函數(shù)具體是怎樣實(shí)現(xiàn)的，但是如果是數(shù)組的刪除的話，你在數(shù)組中刪除了一個(gè)元素，其他元素需要進(jìn)行前移，才能保證數(shù)組中間不會(huì)有空，這樣你刪除n個(gè)元素就移動(dòng)了n*(n的位置后面的元素個(gè)數(shù))個(gè)元素，而老師的方法是賦值之后再pop，理論上講最多也就length那么長(zhǎng)咯，所以是O(n)，splice很容易就O(n方)了吧
2015-06-04
改寫成requextAnimationFrame 沒有這個(gè)問題
2015-01-24
還有一個(gè)問題就是，如果電腦不是一直在那個(gè)頁面。那么性能優(yōu)化代碼好像就不工作。會(huì)出現(xiàn)這種情況：
麻煩各位誰懂的，給解釋一下！