手動增強for-loop與處理對象

Question

在某些情況下，我們使用循環以方便，但也可以“手動”執行一些操作，例如從我的應用程序處理MenuItem ：

1. 我創建了一個MenuItem的小數組，然后使用增強的for循環遍歷它。

    MenuItem[] fileActionsToLock ={ mMenu.findItem(R.id.action_share), mMenu.findItem(R.id.action_rename), mMenu.findItem(R.id.action_copy), mMenu.findItem(R.id.action_move) }; for (MenuItem i : fileActionsToLock) { i.setEnabled(false); i.getIcon().setAlpha(100); } 

2. 我將值分別應用於每個MenuItem 。

    mMenu.findItem(R.id.action_share).setEnabled(false); mMenu.findItem(R.id.action_share).getIcon().setAlpha(100); mMenu.findItem(R.id.action_rename).setEnabled(false); mMenu.findItem(R.id.action_rename).getIcon().setAlpha(100); mMenu.findItem(R.id.action_copy).setEnabled(false); mMenu.findItem(R.id.action_copy).getIcon().setAlpha(100); mMenu.findItem(R.id.action_move).setEnabled(false); mMenu.findItem(R.id.action_move).getIcon().setAlpha(100); 

由於只有少數元素，因此性能在視覺上是相同的。

• 但哪個代碼工作得更快，為什么？
• 此外， fileActionsToLock數組和臨時MenuItem i將在哪個時間點進行垃圾回收？

Answer 1

（1）我認為任何一方都不會明顯快於另一方。 循環將有更多的開銷（例如，請參閱下面關於需要迭代器的注釋）但是應該花費大約相同的時間來完成，就好像您只是單獨寫出所有步驟一樣。 底線 - 你不會注意到差異。 我會使用循環，因為它可能使您的代碼更容易閱讀。

（2）當垃圾收集的東西很難說。 通常，當沒有更多引用指向它時，對象將有資格進行垃圾回收。 實際發生的方式和時間取決於您的單個設備的JVM正在運行的其余代碼和垃圾回收。 不同版本的android os有不同種類的垃圾收集器。 一些更多的垃圾收集器可以在這里，發現這里也

Answer 2

非循環方法肯定更快。 它更容易比較標准for循環，因為我們知道到底發生了什么，所以我會用它作為例子。 當循環開始時，我們聲明變量檢查條件是否滿足，然后運行第一個代碼塊。 在運行第一個代碼塊之后，我們在檢查條件然后重復之前運行一個語句。

所有這些額外內容（聲明一個額外的變量，檢查條件並運行最終語句）都不會出現在第二個示例中。 少發生，所以它總是會更快。 也就是說，這些額外的操作對於現代計算機來說花費的時間或精力很少，實在不值得擔心。 差異可以忽略不計。 如此之小，以至於它們不太可能對您的應用產生任何影響。 即使foreach循環比for循環更快，仍然會執行不在您的手動示例中的操作。

在決定何時使用一個或另一個時，您應該使用的標准是可讀性，功能性，可擴展性等。讀取循環更容易，並且代碼更少。 循環可用於動態檢查條件，使其更具功能性。 最后，循環更具可擴展性。 您可以在以后向循環數組中添加更多Object ，而無需更改代碼。

至於垃圾收集，應該沒有任何區別。 在任何可訪問和運行的代碼中都沒有對它們的引用時，它們都有資格進行收集。

Answer 3

您可以在本文中閱讀相關內容。 手動方式通常比循環增強更快，因為它不會調用迭代器上的任何方法。 它也比正常循環更快，因為它不包含跳轉和遞增指令 - 但這不是一個真正的問題，因為沒有人會對元素的幾何元素進行手動操作以從CPU獲得幾毫秒。