Android內存泄漏的原因及解決技巧

Posted on by

正確的生命周期管理如何防止Android內存泄漏

OutOfMemoryException是一個常見的令人沮喪的錯誤，也是導致應用程序意外關閉的主要原因之一。

“如果應用程序昨天運行良好，為什麼現在會發生這種情況？這個問題讓Android的開發者和新手都感到困惑。

導致OutOfMemory異常的潛在原因有很多種，但其中最常見的是內存泄漏—應用程序中的內存分配從未釋放。本文將解釋如何通過有效的生命周期管理（開發過程中一個重要但經常被忽視的部分）來最小化這種風險。

為什麼安卓系統會發生內存泄漏？

問題很簡單。某些對象應該隻有一個固定的壽命，當它們的使用壽命結束時，它們需要被刪除。

理論上，當進程使用onStop或onDestroy終止時，應該處理該內存。但是，濫用對象引用可能會阻止垃圾收集器釋放未使用的對象。例如：如果未使用的對象A引用瞭未使用的對象B，那麼您將得到兩個不必要的對象，垃圾回收器將永遠不會釋放它們，因為它們正在相互引用。

阻止內存泄漏這種情況發生的常見技巧

開發人員可以采取許多步驟來阻止死的活動被困在內存中。

  1. 在onResume（）/onPause（）或onStart（）/onStop（）中註冊/註銷廣播接收器
  2. 不要對視圖/活動/上下文使用靜態變量
  3. 需要保存對上下文的引用的singleton應該使用applicationContext（）或將其包裝到WeakReference中
  4. 註意匿名和非靜態內部類，因為它們包含對其封閉類的隱式引用。
  5. 如果要比父類（如處理程序）更長壽，請使用靜態內部類而不是匿名類。
  6. 如果內部或匿名類是可取消的（如AsyncTask、Thread、RxSubscriptions），則在銷毀活動時取消它。

Android生命周期感知組件

一旦你完成瞭上面的基本步驟，現在是時候做一些更重要的事情瞭：應用程序活動的生命周期。如果我們不能正確地管理生命周期，我們最終會在不再需要內存的時候掛掉它。

這涉及到許多不同的任務。對於每個活動，我們需要中斷線程，去掉RxJava中的訂閱，取消AsyncTask引用，並確保正確刪除該活動的引用（以及與之相關的任何其他活動）。所有這些任務都會消耗開發人員的大量時間。

模型視圖呈現器（MVP）使事情變得更加復雜，MVP是Android中構建用戶界面的常用架構模式。然而，MVP對於從視圖中分離業務邏輯非常有用。

在MVP模式中，View和Presenter都是它們之間行為契約的抽象實現。實現MVP最常見的方法是使用活動/片段作為視圖的實現，並為習慣於引用視圖的演示者使用簡單的實現。

所以我們最終得到瞭一個帶有Presenter引用的視圖和一個帶有視圖引用的Presenter（提示：這裡有一個潛在的漏洞）。

考慮到這些潛在的困難，我們有必要建立一個適當的管理結構來移除在生命周期中創建的多餘內存。有幾種行之有效的方法可以做到這一點：

1. 在Android Studio上使用Android Arch Lifecycle創建支持生命周期的組件

生命周期感知組件是智能的。例如，它們可以通過除去內存來對另一個組件（如活動或片段）的生命周期狀態的更改作出反應。這意味著代碼更輕，內存效率更高。

archlifecycle是Android的一個新庫，它提供瞭一組工具來構建支持生命周期的組件。庫以抽象的方式工作，這意味著生命周期所有者不再需要擔心管理特定任務和活動的生命周期。

Arch生命周期的關鍵工具和定義如下：

  • 生命周期：一個排序系統，它定義瞭哪些對象具有Android生命周期，並允許對它們進行監視。
  • LifecycleObserver：一個常規接口，它監視每個被標識為具有Android生命周期的對象，使用一個簡單的公式來處理每個密鑰生命周期事件。
  • @OnLifecycleEvent：可以在實現LifecycleObserver接口的類中使用的註釋。它允許我們設置關鍵生命周期事件，這些事件將在每次啟動時觸發帶註釋的方法。以下是可設置的所有事件的列表：ON_ANY、ON_CREATE、ON_DESTROY、ON_PAUSE、ON_RESUME、ON_START、ON_STOP
  • LifecycleOwner默認為每個可以管理其生命周期的Android組件實現，並讓開發人員控制每個事件。

使用這些工具，我們可以將所有幹凈的任務發送給它們的所有者（在我們的例子中是演示者），這樣我們就有瞭一個幹凈的、無泄漏的解耦代碼（至少在演示者層是這樣）。

下面是一個超級基本的實現，向您展示我們所說的：

interface View: MVPView, LifecycleOwner

class RandomPresenter : Presenter<View>, LifecycleObserver {
 private lateinit var view: View
 override fun attachView(view: View) {
  this.view = view
  view.lifecycle.addObserver(this)
 }

 @OnLifecycleEvent(Lifecycle.Event.On_DESTROY)
 fun onClear() {
	//TODO: clean 
}

2. 使用Android架構視圖模型作為演示者和LiveData

另一種方法是通過使用新的生命周期組件來避免視圖模型的內存泄漏。

ViewModel是一個抽象類，它實現一個稱為onClear的函數，當必須刪除某個特定對象時，該函數會自動調用。ViewModel是由框架生成的，它附加到創建者的生命周期中（作為一個額外的好處，使用Dagger註入非常容易）

除瞭使用ViewModel，LiveData還提供瞭一個重要的通信渠道。這意味著創造瞭一個容易觀察到的反應性產物。

這裡最重要的一點是，生命周期所有者可以觀察到LiveData，因此數據傳輸總是由生命周期管理的，而且我們可以確保在使用它們時保留任何引用。

3. 使用LeakCanary和Bugfender

除瞭上述步驟之外，我們還想推薦兩個重要的工具包：LeakCanary，一個用於監視泄漏的流行工具，以及我們自己的Bugfender。

LeakCanary是一個用於Android和Java的內存檢測庫。它是開源的，所以有一個龐大的社區支持它，它不僅僅告訴你一個漏洞，它還告訴你可能的原因。

我們的遠程日志工具Bugfender允許您調試單個泄漏跟蹤，並擴展一個名為DisplayLeakService的類，它讓我們知道何時發生泄漏。然後我們就可以用Bugfender輕松登錄瞭。

public class LeakUploadService extends DisplayLeakService {
 override fun afterDefaultHandling(heapDump: HeapDump, result: AnalysisResult, leakInfo: String) {
  if (result.leakFound) {
   Bugfender.d(“LeakCanary”, result.toString())
  }
 }
}

此外，用戶還可以獲得Bugfender的所有其他好處，包括全天候記錄日志（即使設備離線）、內置故障報告和易於使用的web控制臺。

以上就是Android內存泄漏的原因及解決技巧的詳細內容，更多關於Android內存泄漏的資料請關註WalkonNet其它相關文章！

推薦閱讀：