常見的八種導致 APP 記憶體流失的問題（下）

標籤：記憶體回收   頻繁   系統   gets   測試品牌   分配   systems   強引用   分享   

百度搜尋：小強測試品牌

QQ群：138269539

 

Handlers

同 樣的，定義一個匿名的 Runnable 對象並將其提交到 Handler 上也可能導致 activity 泄漏。Runnable 對象間接地引用了定義它的activity 對象，而它會被提交到 Handler 的 MessageQueue 中，如果它在 activity 銷毀時還沒有被處理，那就會導致 activity 泄漏了。

Threads

同樣的，使用 Thread 和 TimerTask 也可能導致 activity 泄漏

Timer Tasks

只要它們是通過匿名類建立的，儘管它們在單獨的線程被執行，它們也會持有對 activity 的強引用，進而導致記憶體流失

Sensor Manager

最 後，系統服務可以通過 context.getSystemService 擷取，它們負責執行某些背景工作，或者為硬體訪問提供介面。如果 context 對象想要在服務內部的事件發生時被通知，那就需要把自己註冊到服務的監聽器中。然而，這會讓服務持有 activity 的引用，如果程式員忘記在 activity 銷毀時取消註冊，那就會導致 activity 泄漏了。

現 在，我們展示了八種很容易不經意間就泄漏大量記憶體的情景。請記住，最壞的情況下，你的 APP 可能會由於大量的記憶體流失而記憶體耗盡，進而閃退，但它並不總是這樣。相反，記憶體流失會消耗大量的記憶體，但卻不至於記憶體耗盡，這時，APP 會由於記憶體不夠分配而頻繁進行記憶體回收。記憶體回收是非常耗時的操作，會導致嚴重的卡頓。在 activity 內部建立對象時，一定要格外小心，並且要經常測試是否存在記憶體流失。

常見的八種導致 APP 記憶體流失的問題（下）