由於Android GC性能改變了編碼風格，有多遠？

我一直聽說Android應用程序應該嘗試限制創建的對象的數量，以減少垃圾收集器的工作量。這是有道理的，你可能不想創建大量的對象來跟蹤有限的內存佔用，例如在傳統的服務器應用程序創建100,000個對象在幾秒鐘內不會聞所未聞。由於Android GC性能改變了編碼風格，有多遠？

問題是我應該採取多遠？我已經看到很多Android應用程序依賴靜態狀態的例子，據稱這些應用程序「加快速度」。將需要從幾十個垃圾收集到幾百個垃圾的實例數量增加是否真的有很大的不同？我可以想象改變我的編碼風格，現在創建了成千上萬的對象，就像你可能在成熟的Java-EE服務器上創建的那樣，但是依賴一堆靜態來（據說）減少了垃圾收集對象的數量奇。

有多少是真的有必要改變你的編碼風格，以創造業績Android應用？

來源

2010-04-07 benstpierre

「避免分配」建議通常是關於遊戲循環。虛擬機不得不暫停收集垃圾，而當你的遊戲以30fps動畫時，你不希望發生這種情況。如果你不分配任何對象，虛擬機將不需要收集垃圾來釋放內存。如果您的遊戲需要在沒有用戶可見的情況下運行，那麼您應該考慮更改相關部分中的代碼，以最大限度地減少或消除分配。

如果你正在做保存食譜或顯示照片的應用程序，我就不會擔心它 - GC打嗝是不是用戶會注意到。

到Dalvik的GC（例如代收集）未來的改進應該使這不是一個問題。

來源

2010-04-07 18:40:02 fadden

我也想補充一點，你會經常發現適用於臺式機或服務器這是原始書面的Java代碼，是非常低效的，並通過一噸的對象相比，它的工作量鞭打。例如，我看到網絡代碼在處理來自網絡的數據時不斷導致GC。如果你的代碼是這樣做的，你應該看看優化它，不是因爲Dalvik，而是因爲它不適合移動設備 - 所有額外的工作都直接來自電池。 – hackbod 2010-04-08 05:29:35

關於風格應該改變多少，我認爲最好的方法是編寫可以工作的代碼（並且儘可能重複使用已分配的對象，儘管如此，儘管如此），然後查看是否存在GC上的任何壓力。如果有，那麼開始記憶分析你的代碼並尋找你可以避免分配和刪除變量的地方。 – 2012-02-07 10:18:15

我想說，這取決於你在做什麼以及你現在的編碼風格。總是有必要牢記移動設備和相應程序的硬件限制，但再次強調，無論您的應用運行在何處，都應該認識到這一點。如果你正在做很多真正密集型的計算，需要實時更新或類似遊戲，那麼你可以考慮使用NDK，但如果你只是做正常的用戶驅動的東西，它不應該那麼糟糕。我的建議是儘量節儉，但不要過分擔心優化，直到你感受到它的運行方式。

來源

2010-04-07 18:35:00 CaseyB

由於Android GC性能改變了編碼風格，有多遠？

回答

相關問題