比較JS合併陣列的各種方法及其優劣

發表於2015-06-08

本文屬於JavaScript的基礎技能. 我們將學習結合/合併兩個JS陣列的各種常用方法,並比較各種方法的優缺點.

我們先來看看具體的場景:

很明顯,陣列 q 和 b 簡單拼接的結果是:

concat(..)方法

最常見的用法如下:

如您所見, c 是一個全新的陣列, 表示 q 和 b 這兩個陣列的組合, 但是 q 和 b 現在沒用了是吧?

如果 q 陣列有10000個元素, b 陣列也有有10000個元素? 那麼陣列c現在就有20000個元素, 這種方式佔用了2倍的記憶體.
“這沒問題!”,你可能會覺得. 只要將 q 和 b 置空就行, 然後就會被垃圾回收,對嗎?問題解決了!

額? 如果陣列都很小,那自然沒問題. 但對大型的陣列,或需要多次重複處理時, 記憶體就被限制了, 它還需要進行優化.

迴圈插入

OK, 讓我們把一個陣列的內容加入到另一箇中試試,使用 Array#push() 方法:

現在, q中存放了兩個原始陣列的內容(q + b).

看樣子對記憶體優化做的不錯.

但如果 q 陣列很小而 b 又很大呢? 出於記憶體和速度的考慮,這時想把較小的 q 插入到 b 前面. 沒問題,只要用unshift() 方法代替 push() 即可, 對應的也要從大到小進行迴圈遍歷:

實用技巧

悲催的是,for迴圈很土並且難以維護. 我們能做得更好嗎?

我們先試試 Array#reduce :

Array#reduce() 和 Array#reduceRight() 很高大上,但有點笨重,而且一般人也記不住.  JS規範6 中的 => 箭頭函式(arrow-functions) 能讓程式碼量大大減少, 但需要對每個陣列元素執行函式呼叫, 也是很渣的手段.

那麼下面的程式碼怎麼樣呢?

BIG更高了,是吧!? 特別是 unshift() 方法不需要像前面那樣考慮相反的順序. ES6 的展開運算子(spread operator, 加  字首)就更高階了: a.push( …b ) 或者 b.unshift( …a )

但是,事實上這種方法還是太樂觀了. 在這兩種情況下,不管是將 a 或 b 傳遞給 apply() 作為第二個引數(apply方式呼叫Function時第一個引數在內部變成this,即context,上下文,作用域), 還是使用  展開運算子的方式, 實際上陣列都會被打散成為函式的 arguments .

第一個主要的問題是,佔用了雙倍的記憶體(當然,是臨時的!),因為需要將陣列複製到函式棧之中. 此外,不同的JS引擎有不同的實現演算法,可能會限制了函式可以傳遞的引數數量.

如果陣列新增了一百萬個元素, 那一定會超過函式棧所允許的大小, 不管是push() 或 unshift()呼叫. 這種方式只在幾千個元素時可用,所以必須限制其不能超過一定範圍.

注意: 你也可以試試 splice(), 肯定會發現他和 push(..)/unshift(..) 都是一樣的限制.

一種選擇是繼續使用這種方法,但是採用分批次處理:

等等,我們損害了程式碼的可讀性(甚至是效能!). 在我們放棄之前結束這個旅程吧.

總結

Array#concat() 是久經考驗的方法, 用於組合兩個(或多個)陣列. 但他建立了一個新的陣列,而不是修改現有的一個.有很多變通的手法,但他們都有不同的優缺點,需要根據實際情況來選擇.

上面列出了各種 優點/缺點,也許最好的(包括沒有列出的)方法是 reduce(..) 和 reduceRight(..) 無論你選擇什麼,都應該批判性地思考你的陣列合並策略,而不是把它當作理所當然的事情.

相關文章