android的應(yīng)用被限制為最多占用16m的內(nèi)存,至少在t-mobile g1上是這樣的(當(dāng)然現(xiàn)在已經(jīng)有幾百兆的內(nèi)存可以用了——譯者注)。它包括電話本身占用的和開發(fā)者可以使用的兩部分。即使你沒有占用全部?jī)?nèi)存的打算,你也應(yīng)該盡量少的使用內(nèi)存,以免別的應(yīng)用在運(yùn)行的時(shí)候關(guān)閉你的應(yīng)用。android能在內(nèi)存中保持的應(yīng)用越多,用戶在切換應(yīng)用的時(shí)候就越快。作為我的一項(xiàng)工作,我仔細(xì)研究了android應(yīng)用的內(nèi)存泄露問題,大多數(shù)情況下它們是由同一個(gè)錯(cuò)誤引起的,那就是對(duì)一個(gè)上下文(context)保持了長(zhǎng)時(shí)間的引用。
在android中,上下文(context)被用作很多操作中,但是大部分是載入和訪問資源。這就是所有的widget都會(huì)在它們的構(gòu)造函數(shù)中接受一個(gè)上下文(context)參數(shù)。在一個(gè)合格的android應(yīng)用中,你通常能夠用到兩種上下文(context):活動(dòng)(activity)和應(yīng)用(application)。活動(dòng)(activity)通常被傳遞給需要上下文(context)參數(shù)的類或者方法:
@override
protected void oncreate(bundle state) {
super.oncreate(state);
textview label = new textview(this);
label.settext("leaks are bad");
setcontentview(label);
}
這就意味著那個(gè)view有一個(gè)對(duì)整個(gè)活動(dòng)(activity)的引用并且對(duì)這個(gè)活動(dòng)(activity)中保持的所有對(duì)象有保持了引用;通常它們包括整個(gè)view的層次和它的所有資源。因此,如果你“泄露”了上下文(context)(這里“泄露”的意思是你保持了一個(gè)引用并且組織gc收集它),你將造成大量的內(nèi)存泄露。如果你不夠小心的話,“泄露”一整個(gè)活動(dòng)(activity)是件非常簡(jiǎn)單的事情。
當(dāng)屏幕的方向改變時(shí)系統(tǒng)會(huì)默認(rèn)的銷毀當(dāng)前的活動(dòng)(activity)并且創(chuàng)建一個(gè)新的并且保持了它的狀態(tài)。這樣的結(jié)果就是android會(huì)從資源中重新載入應(yīng)用的ui。現(xiàn)在想象一下,你寫了一個(gè)應(yīng)用,有一個(gè)非常大的位圖,并且你并不想在每次旋轉(zhuǎn)時(shí)都重新載入。保留它并且每次旋轉(zhuǎn)不重新加載的最簡(jiǎn)單的辦法就是把它保存在一個(gè)靜態(tài)字段上:
private static drawable sbackground;
@override
protected void oncreate(bundle state) {
super.oncreate(state);
textview label = new textview(this);
label.settext("leaks are bad");
if (sbackground == null) {
sbackground = getdrawable(r.drawable.large_bitmap);
}
label.setbackgrounddrawable(sbackground);
setcontentview(label);
}
這段代碼非常快,同時(shí)也錯(cuò)的夠離譜。它泄露了當(dāng)?shù)谝淮纹聊唤嵌雀淖儠r(shí)創(chuàng)建的第一個(gè)活動(dòng)(activity)。當(dāng)一個(gè)drawable被附加到一個(gè)view,這個(gè)view被設(shè)置為drawable的一個(gè)回調(diào)。在上面的代碼片斷中,這意味著這個(gè)drawable對(duì)textview有一個(gè)引用,同時(shí)這個(gè)textview對(duì)activity(context對(duì)象)保持著引用,同時(shí)這個(gè)activity對(duì)很多對(duì)象又有引用(這個(gè)多少還要看你的代碼了)。
這個(gè)例子是造成context泄露的最簡(jiǎn)單的一個(gè)原因,你可以看一下我們?cè)?a rel="external nofollow" target="_blank">主屏幕源碼(查看unbinddrawables()方法)中是通過在activity銷毀時(shí)設(shè)置保存過的drawable的回調(diào)為空來解決這個(gè)問題的。更為有趣的是,你可以創(chuàng)建一個(gè)context泄露的鏈,當(dāng)然這非常的糟糕。它們可以讓你飛快的用光所有的內(nèi)存。
有兩種簡(jiǎn)單的方法可以避免與context相關(guān)的內(nèi)存泄露。最明顯的一個(gè)就是避免在context的自身的范圍外使用它。上面的例子展示了在類內(nèi)部的一個(gè)靜態(tài)的引用和它們對(duì)外部類的間接引用是非常危險(xiǎn)的。第二個(gè)解決方案就是使用application context。這個(gè)context會(huì)伴隨你的應(yīng)用而存在,并且不依賴activity的的生命周期。如果你計(jì)劃保持一個(gè)需要context的長(zhǎng)生命周期的對(duì)象,請(qǐng)記得考慮application對(duì)象。你可以非常方便的通過調(diào)用context.getapplicationcontext() 或者 activity.getapplication()獲取它。
總之,為了避免涉及到context的內(nèi)存泄露,請(qǐng)記住如下幾點(diǎn):
1.不要對(duì)一個(gè)activity context保持長(zhǎng)生命周期的引用(一個(gè)對(duì)activity的引用應(yīng)該與activity自身的生命周期相同)
2.嘗試使用應(yīng)用上下文(context-application)代替活動(dòng)上下文(context-activity)
3.如果你不能控制它們的生命周期,在活動(dòng)(activity)中避免使用不是靜態(tài)的內(nèi)部類,使用靜態(tài)類并且使用弱引用到活動(dòng)(activity)的內(nèi)部。對(duì)于這個(gè)問題的解決方法是使用靜態(tài)的內(nèi)部類與一個(gè)弱引用(weakreference)的外部類。就像viewroot和它的w內(nèi)部類那么實(shí)現(xiàn)的。
4.垃圾回收器對(duì)于內(nèi)存泄露來說并不是百分百保險(xiǎn)的。