2012-03-13 65 views
1

哪一個是更有效? :循環效率對比

ArrayList<Integer> list = new ArrayList<Integer>(); 
for(int a : list){ 
    log.i(tag, a + ""); 
} 

SparseIntArray list2 = new SparseIntArray(); 
int count = list2.size(); 
for(int j = 0; j < count; j++) { 
    log.i(tag, list2.get(j) + ""); 
} 

或者,有沒有閱讀列表的內容更快的方法?

+1

檢查:http://developer.android.com/guide/practices/design/performance.html#foreach – idiottiger 2012-03-13 03:20:35

+2

請問是否有指標之間的差距,第二個甚至工作?文檔說'list2.size()'返回鍵/值對的數量,而不是最高的索引。意思是,如果你的地圖有兩個條目({100 => 100,200 => 200}),你不會看到它們嗎? – cHao 2012-03-13 03:21:51

+0

@cHao正確,也不一定會遍歷所有的值(除非前面的代碼寫這樣一來,這不是強制執行的),另外,在範圍內的任何丟失的鑰匙將只返回0,這意味着log.i(標籤,「 0「)可能會被稱爲很多。 – Chet 2012-03-13 03:34:11

回答

15

效率,在這種情況下,是無關緊要的,因爲這兩個做完全不同的事情。

我想你知道,通過數組列表中的所有元素的ArrayList示例循環。

你不知道什麼是你SparseIntArray例如不迭代通過稀疏整數數組的所有元素,因爲稀疏整數數組的鍵做範圍從零到陣列尺寸減一。相反,它的鍵是任意整數。稀疏整數數組有很多共同點,接口方面,HashMap<Integer, Integer>ArrayList<Integer>一樣。

(這,順便說一下,涉及到軟件設計的一般規則:它是更好地爲你的代碼正確高效你總是可以採取正確的,乾淨的代碼,並設法提高其性能;但很難採取快速,錯誤的代碼並找到使其正確的方法。)

+0

+1上迭代,以便首先回答並提及與HashMap的相似性。 – Chet 2012-03-13 03:26:54

+1

+1關於正確的>高效代碼的美麗報價。 – josephus 2012-03-13 03:42:31

+0

@ruakh,我想是的,感謝您的評論,我認爲在我的情況下使用arraylist是正常的更好。 – rex 2012-03-13 04:40:53

2

對於像您的第一個示例那樣的每個循環,如果您因爲其他原因不需要索引變量,則幾乎總是可取的。

編輯:會的ArrayList迭代更有效(在你的榜樣,一邊喊「得到」),比SparseIntArray因爲查找是相對於對數時間常數時間。這將取決於你的用例 - 如果你的密鑰稀疏,那麼SparseIntArray會爲你節省大量的內存空間。

我想指出SparseIntArray可以在指示符中有間隙,這意味着循環遍歷0和Size之間的每個值不僅效率低,而且它也會爲每個缺失的索引返回0,這可能不是您的意圖行爲。

+1

實際上,'SparseIntArray'中的查找需要*對數*時間,因爲它使用二分搜索。對於'[0,size]'範圍內的每個「缺失索引」,該範圍外有一個* extra *索引*,該循環永遠不會到達,因爲'size'是元素的數量,而不是與陣列中最大的索引有關。 (請參閱http://developer.android.com/reference/android/util/SparseIntArray.html,http://www.java2s.com/Open-Source/Android/android-core/platform-frameworks-base/android/ util/SparseIntArray.java.htm。) – ruakh 2012-03-13 03:45:12

+0

@ruakh哦,謝謝,我只是錯過了這一點,非常感謝XD。 – rex 2012-03-13 04:41:53

+0

@ruakh很有意思。我只是猜測在實施。考慮到SparseIntArray應該比HashMap更有效,但它實際上具有更高的算法時間。 – Chet 2012-03-13 11:56:58

2

SparseIntArrays地圖整數到整數。與普通的整數數組不同,索引中可能存在空白。它的目的是比使用HashMap將整數映射到整數更有效。

Read More