想都不用想，removeAll是時間復(fù)雜度是O(n2)的，恐怖呀。 我也是看我們產(chǎn)品一個過濾消息的代碼為什么執(zhí)行時間這么長，我才想起的。究竟有多恐怖，給大家點直觀感受，舉個例子：

創(chuàng)建一個這樣的類

灌到一個listview里面

如果我要刪掉arraylist里面的，屬性b填的是“bb”的。要怎么做。

方法1:

傳說中的removeall

方法2:

遍歷一次完成

結(jié)果：

測試5次，第一次可能是剛啟動android app，申請內(nèi)存等緣故，時間特別長。哪怕把最大的兩個值去掉，相差的倍數(shù)也不用我描述了吧。

方法1：1202ms? 751ms ? 333ms ? 337ms ?306ms

方法2: ? 3ms ?6ms ?1ms ?2ms ?2ms

想一想：

我之后去搜索了一下，確實有類似的文章說這個事情，文章內(nèi)容也是很??的。不過這一切沒有超越我的常識，我一直也認為，java嘛，確實它的庫本身的實現(xiàn)，在效率方面真的有待考量。例如上次被坑的string.split, 居然里面又是arraylist，又是正則的，頻繁使用，也是大量gc；還有effective java推薦的stringbuilder，創(chuàng)建的時候不去填個長度的話，各種擴容，tostring之后各種gc,盡量不要new，把原來的delete來用吧，會好很多； 條數(shù)n多的用arraylist＋范型和用數(shù)組的內(nèi)存消耗也是天差地別。大家多留個心，特別是優(yōu)化后期，或者性能瓶頸就在這些不起眼的地方了，也許你就是被字符串害死的。