正確的生命周期管理如何防止Android內(nèi)存泄漏

OutOfMemoryException是一個常見的令人沮喪的錯誤，也是導(dǎo)致應(yīng)用程序意外關(guān)閉的主要原因之一。

“如果應(yīng)用程序昨天運(yùn)行良好，為什么現(xiàn)在會發(fā)生這種情況？這個問題讓Android的開發(fā)者和新手都感到困惑。

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

為什么安卓系統(tǒng)會發(fā)生內(nèi)存泄漏？

問題很簡單。某些對象應(yīng)該只有一個固定的壽命，當(dāng)它們的使用壽命結(jié)束時，它們需要被刪除。

理論上，當(dāng)進(jìn)程使用onStop或onDestroy終止時，應(yīng)該處理該內(nèi)存。但是，濫用對象引用可能會阻止垃圾收集器釋放未使用的對象。例如：如果未使用的對象A引用了未使用的對象B，那么您將得到兩個不必要的對象，垃圾回收器將永遠(yuǎn)不會釋放它們，因?yàn)樗鼈冋谙嗷ヒ谩?/p>阻止內(nèi)存泄漏這種情況發(fā)生的常見技巧

開發(fā)人員可以采取許多步驟來阻止死的活動被困在內(nèi)存中。

在onResume（）/onPause（）或onStart（）/onStop（）中注冊/注銷廣播接收器 不要對視圖/活動/上下文使用靜態(tài)變量 需要保存對上下文的引用的singleton應(yīng)該使用applicationContext（）或?qū)⑵浒b到WeakReference中 注意匿名和非靜態(tài)內(nèi)部類，因?yàn)樗鼈儼瑢ζ浞忾]類的隱式引用。 如果要比父類（如處理程序）更長壽，請使用靜態(tài)內(nèi)部類而不是匿名類。 如果內(nèi)部或匿名類是可取消的（如AsyncTask、Thread、RxSubscriptions），則在銷毀活動時取消它。 Android生命周期感知組件

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

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

模型視圖呈現(xiàn)器（MVP）使事情變得更加復(fù)雜，MVP是Android中構(gòu)建用戶界面的常用架構(gòu)模式。然而，MVP對于從視圖中分離業(yè)務(wù)邏輯非常有用。

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

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

考慮到這些潛在的困難，我們有必要建立一個適當(dāng)?shù)墓芾斫Y(jié)構(gòu)來移除在生命周期中創(chuàng)建的多余內(nèi)存。有幾種行之有效的方法可以做到這一點(diǎn)：

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

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

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

Arch生命周期的關(guān)鍵工具和定義如下：

生命周期：一個排序系統(tǒng)，它定義了哪些對象具有Android生命周期，并允許對它們進(jìn)行監(jiān)視。 LifecycleObserver：一個常規(guī)接口，它監(jiān)視每個被標(biāo)識為具有Android生命周期的對象，使用一個簡單的公式來處理每個密鑰生命周期事件。 @OnLifecycleEvent：可以在實(shí)現(xiàn)LifecycleObserver接口的類中使用的注釋。它允許我們設(shè)置關(guān)鍵生命周期事件，這些事件將在每次啟動時觸發(fā)帶注釋的方法。以下是可設(shè)置的所有事件的列表：ON_ANY、ON_CREATE、ON_DESTROY、ON_PAUSE、ON_RESUME、ON_START、ON_STOP LifecycleOwner默認(rèn)為每個可以管理其生命周期的Android組件實(shí)現(xiàn)，并讓開發(fā)人員控制每個事件。

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

下面是一個超級基本的實(shí)現(xiàn)，向您展示我們所說的：

interface View: MVPView, LifecycleOwnerclass 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架構(gòu)視圖模型作為演示者和LiveData

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

ViewModel是一個抽象類，它實(shí)現(xiàn)一個稱為onClear的函數(shù)，當(dāng)必須刪除某個特定對象時，該函數(shù)會自動調(diào)用。ViewModel是由框架生成的，它附加到創(chuàng)建者的生命周期中（作為一個額外的好處，使用Dagger注入非常容易）

除了使用ViewModel，LiveData還提供了一個重要的通信渠道。這意味著創(chuàng)造了一個容易觀察到的反應(yīng)性產(chǎn)物。

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

3. 使用LeakCanary和Bugfender

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

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

我們的遠(yuǎn)程日志工具Bugfender允許您調(diào)試單個泄漏跟蹤，并擴(kuò)展一個名為DisplayLeakService的類，它讓我們知道何時發(fā)生泄漏。然后我們就可以用Bugfender輕松登錄了。

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

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

以上就是Android內(nèi)存泄漏的原因及解決技巧的詳細(xì)內(nèi)容，更多關(guān)于Android內(nèi)存泄漏的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！