本文講的是徹底理解引用在 Android 和 Java 中的工作原理。

對(duì)于一個(gè) Android 開發(fā)者，如果你不使用 WeakReferences，這是有問題的。

舉個(gè)恰當(dāng)?shù)睦?，幾個(gè)月前，我發(fā)布了我的最后一本書 “Android High Performance”, 聯(lián)席作者是?Diego Grancini。最熱門的章節(jié)之一就是討論 Android 的內(nèi)存管理。在本章中，我們介紹了移動(dòng)設(shè)備中內(nèi)存的工作原理，內(nèi)存泄漏是如何發(fā)生的，為什么這個(gè)是重要的，以及我們可以應(yīng)用哪些技術(shù)來避開它們。因?yàn)槲覐拈_發(fā) Android 起，就常?？吹竭@么種傾向：輕視甚至無視一切與內(nèi)存泄漏和內(nèi)存管理相關(guān)的問題。已經(jīng)滿足開發(fā)需求了，為何要庸人自擾呢？我們總是急于開發(fā)新的功能，我們寧愿在下一個(gè) Sprint 演示中呈現(xiàn)一些可見的東西，也不會(huì)關(guān)心那些沒有人一眼就能看到的東西。

這無疑是導(dǎo)致技術(shù)債務(wù)一個(gè)活生生的例子。 我甚至可以補(bǔ)充地說，技術(shù)債務(wù)在現(xiàn)實(shí)世界中也有一些影響，那是我們不能用單元測試衡量的：失望，開發(fā)者間的摩擦，低質(zhì)量的軟件和積極性的喪失。這種影響難以衡量的原因是在于它們常常發(fā)生在長遠(yuǎn)的將來的某個(gè)時(shí)間點(diǎn)。這有點(diǎn)像政客：如果我只當(dāng)政 8 年，為何我要煩心 12 年后將要發(fā)生的事呢？除了在軟件開發(fā)，一切都以更快的方式。

編寫軟件開發(fā)中應(yīng)該采納的設(shè)計(jì)思想可能需要一些大篇文章，而且已經(jīng)有很多書和文章可供您參考。然而，簡要地解釋不同類型的內(nèi)存引用，它們具體是什么，以及如何在 Android 中使用，這是個(gè)相對(duì)簡短的任務(wù)，這也是我想在本文中做的。

首先：Java 中的引用是什么？

引用指向了一個(gè)對(duì)象，你能通過引用訪問對(duì)象。

Java 默認(rèn)有 4 種類型的引用：強(qiáng)引用（StrongReference）、軟引用（SoftReference）、弱引用（WeakReference）?和虛引用（PhantomReference）。部分人認(rèn)為只有強(qiáng)引用和弱引用兩種類型的引用，而弱引用有兩個(gè)層次的弱化。我們習(xí)慣于將生活中的一切事物歸類，那種毅力堪比植物學(xué)家對(duì)植物的分類的。不論你覺得哪種分類更好，首先你需要去理解這些引用。然后你可以找出自己的分類。

各種引用都是什么意思？

StrongReference：?強(qiáng)引用是 Java 中最為常見的引用類型。任何時(shí)候，當(dāng)我們創(chuàng)建了一個(gè)對(duì)象，強(qiáng)引用也同時(shí)被創(chuàng)建了。比如，當(dāng)我們這么做：

MyObject object = new MyObject();

一個(gè)新的?MyObject?對(duì)象被創(chuàng)建，指向它的強(qiáng)引用保存在?object?中。你還在看吧？ 嗯，更有意思的事情來了，這個(gè)?object?是可以強(qiáng)行到達(dá)的——意思就是，它可以通過一系列強(qiáng)引用找到，這將會(huì)阻止垃圾回收機(jī)制回收它，然而，這正是是我們最想要的?，F(xiàn)在，我們來看個(gè)例子。

?

花幾分鐘，嘗試去找可能出現(xiàn)問題的點(diǎn)。

現(xiàn)在呢？

AsyncTask?對(duì)象會(huì)在?Activity?onCreate()?方法中創(chuàng)建并運(yùn)行。但這里有個(gè)問題：內(nèi)部類在它的整個(gè)生命周期中是會(huì)訪問外部類。

如果?Activity?被 destroy 掉時(shí)，會(huì)發(fā)生什么？?AsyncTask?仍然持有?Activity?的引用，所以?Activity?是不能被 GC 回收的。這就是我們所說的內(nèi)存泄漏。

旁注?：以前，我曾經(jīng)對(duì)合適的人進(jìn)行訪談，我問他們?nèi)绾蝿?chuàng)建內(nèi)存泄漏，而不是詢問內(nèi)存泄漏的理論方面。這總是更有趣！

內(nèi)存泄漏實(shí)際上不僅發(fā)生在?Activity?自身銷毀的時(shí)候，配置的改變（譯者注：比如橫屏切換成豎屏）或系統(tǒng)需要更多的內(nèi)存時(shí)，也可能系統(tǒng)強(qiáng)行銷毀。如果?AsyncTask?復(fù)雜點(diǎn)（比如，持有?Activity?上的?View?的引用），它甚至?xí)?dǎo)致崩潰，因?yàn)?view 的引用是 null。（譯者注：這個(gè)是直譯過來的，可能對(duì)部分同學(xué)來說，不太好理解。我舉個(gè)例子吧，比如 AsyncTask 中引用了 ProgressDialog，AsyncTask 運(yùn)行時(shí)會(huì)顯示 ProgressDialog，當(dāng)橫屏切成豎屏?xí)r，這時(shí)會(huì)出現(xiàn)崩潰。（╯＾╰〉）

那么，要如何防止這種問題再次發(fā)生呢？我們接下來介紹另一種類型的引用：

WeakReference：弱引用是引用強(qiáng)度不足以將對(duì)象保持在內(nèi)存中的引用。如果垃圾回收機(jī)制試圖確定對(duì)象的引用強(qiáng)度，如果恰好是通過 WeakReferences 引用，那么該對(duì)象將被垃圾回收。為了便于理解，最好是先拋開理論，用上個(gè)例子來說明如何使用?WeakReference?來避免內(nèi)存泄漏：

現(xiàn)在注意一個(gè)主要區(qū)別：Activity 是這樣被內(nèi)部類引用的：

private WeakReference mainActivity;

這樣做有什么差別呢？ 當(dāng) Activity 不存在時(shí)，由于它是被 WeakReference 持有的，可以被收集。 因此，不會(huì)發(fā)生內(nèi)存泄漏。

旁注:?如果你現(xiàn)在對(duì) WeakReferences 有預(yù)期的更好的了解，你會(huì)發(fā)現(xiàn)類 WeakHashMap 是很有用的。 它完全就是一個(gè) HashMap，除了使用 WeakReferences 引用鍵（鍵，而不是值）。 這使得它們對(duì)于實(shí)現(xiàn)諸如緩存之類的實(shí)體非常有用。

我們提到過更多的引用類型。 讓我們看看它們?cè)谑裁吹胤接杏?，以及我們?nèi)绾文軓闹惺芤妫?/p>

SoftReference:?軟引用可以作為一個(gè)引用強(qiáng)度更強(qiáng)的弱引用。在弱引用將被立即回收的情形下，軟引用會(huì)向 GC 請(qǐng)求留在內(nèi)存中，除非沒有其他選項(xiàng)（否則是不會(huì)回收軟引用持有的對(duì)象）。垃圾回收算法真的很有意思，你可以幾個(gè)小時(shí)內(nèi)沉醉于研究它，而不會(huì)感到疲憊。但大體上，垃圾回收會(huì)這么解說“我會(huì)永遠(yuǎn)收回弱引用。 如果對(duì)象是 軟引用，我將基于具體條件決定是否回收?！?這使得軟引用對(duì)于實(shí)現(xiàn)緩存非常有用：只要內(nèi)存足夠，我們就不必?fù)?dān)心手動(dòng)刪除對(duì)象。 如果你想看實(shí)際中的例子，你可以查看這個(gè)例子，用軟引用實(shí)現(xiàn)的緩存。

PhantomReference：額，虛引用! 在實(shí)際產(chǎn)品開發(fā)中，我見過的，使用的次數(shù)不會(huì)超過 5 次。 垃圾收集器能隨時(shí)回收虛引用 持有的對(duì)象，只要它樂意。沒有進(jìn)一步的解釋，沒有回調(diào)，這使得它難以描述。為什么我們要使用這樣的東西？ 其他幾個(gè)的問題還不夠嗎？ 為什么我會(huì)選擇成為程序員？ 虛引用可以精確地用于檢測對(duì)象是否已從內(nèi)存中刪除。 說實(shí)話，在我的整個(gè)職業(yè)生涯中不得不用虛引用的場景只有兩次。 所以，即便你現(xiàn)在不是很難理解，也不要感到有壓力。

希望這有稍微消除點(diǎn)之前你對(duì)引用的疑慮。作為學(xué)習(xí)的東西，或許你現(xiàn)在想要來點(diǎn)練習(xí)，玩你自己的代碼，看看能怎么改進(jìn)它。第一步應(yīng)該是看看有沒有內(nèi)存泄漏，然后看看能否通過這里所學(xué)的知識(shí)去改掉那些令人討厭的內(nèi)存泄漏。