想都不用想，removeAll是時(shí)間復(fù)雜度是O(n2)的丹皱，恐怖呀妒穴。 我也是看我們產(chǎn)品一個(gè)過(guò)濾消息的代碼為什么執(zhí)行時(shí)間這么長(zhǎng)，我才想起的摊崭。究竟有多恐怖讼油，給大家點(diǎn)直觀感受，舉個(gè)例子：
如果我要?jiǎng)h掉arraylist里面的呢簸，屬性b填的是“bb”的矮台。要怎么做。
方法1:
方法2:
結(jié)果：
測(cè)試5次根时，第一次可能是剛啟動(dòng)android app瘦赫，申請(qǐng)內(nèi)存等緣故，時(shí)間特別長(zhǎng)蛤迎。哪怕把最大的兩個(gè)值去掉确虱，相差的倍數(shù)也不用我描述了吧。
方法1：1202ms? 751ms ? 333ms ? 337ms ?306ms
方法2: ? 3ms ?6ms ?1ms ?2ms ?2ms
想一想：
我之后去搜索了一下替裆，確實(shí)有類(lèi)似的文章說(shuō)這個(gè)事情校辩，文章內(nèi)容也是很??的。不過(guò)這一切沒(méi)有超越我的常識(shí)扎唾，我一直也認(rèn)為召川，java嘛，確實(shí)它的庫(kù)本身的實(shí)現(xiàn)胸遇，在效率方面真的有待考量。例如上次被坑的string.split, 居然里面又是arraylist汉形，又是正則的纸镊，頻繁使用，也是大量gc概疆；還有effective java推薦的stringbuilder逗威，創(chuàng)建的時(shí)候不去填個(gè)長(zhǎng)度的話(huà)，各種擴(kuò)容岔冀，tostring之后各種gc,盡量不要new凯旭，把原來(lái)的delete來(lái)用吧，會(huì)好很多； 條數(shù)n多的用arraylist＋范型和用數(shù)組的內(nèi)存消耗也是天差地別罐呼。大家多留個(gè)心鞠柄，特別是優(yōu)化后期，或者性能瓶頸就在這些不起眼的地方了嫉柴，也許你就是被字符串害死的厌杜。
