Android 中怎么做好內(nèi)存優(yōu)化

Android 中怎么做好內(nèi)存優(yōu)化，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

一、引用沒釋放造成的內(nèi)存泄露

1.1注冊(cè)沒取消造成的內(nèi)存泄露

這種Android的內(nèi)存泄露比純java的內(nèi)存泄露還要嚴(yán)重，因?yàn)槠渌恍〢ndroid程序可能引用我們的Anroid程序的對(duì)象（比如注冊(cè)機(jī) 制）。即使我們的Android程序已經(jīng)結(jié)束了，但是別的引用程序仍然還有對(duì)我們的Android程序的某個(gè)對(duì)象的引用，泄露的內(nèi)存依然不能被垃圾回收。

比如示例1:

假設(shè)我們希望在鎖屏界面(LockScreen)中，監(jiān)聽系統(tǒng)中的電話服務(wù)以獲取一些信息(如信號(hào)強(qiáng)度等)，則可以在LockScreen中定義一個(gè) PhoneStateListener的對(duì)象，同時(shí)將它注冊(cè)到TelephonyManager服務(wù)中。對(duì)于LockScreen對(duì)象，當(dāng)需要顯示鎖屏界 面的時(shí)候就會(huì)創(chuàng)建一個(gè)LockScreen對(duì)象，而當(dāng)鎖屏界面消失的時(shí)候LockScreen對(duì)象就會(huì)被釋放掉。

但是如果在釋放LockScreen對(duì)象的時(shí)候忘記取消我們之前注冊(cè)的PhoneStateListener對(duì)象，則會(huì)導(dǎo)致LockScreen無(wú)法被 垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會(huì)由于大量的LockScreen對(duì)象沒有辦法被回收而引起OutOfMemory,使得 system_process進(jìn)程掛掉。

雖然有些系統(tǒng)程序，它本身好像是可以自動(dòng)取消注冊(cè)的（當(dāng)然不及時(shí)），但是我們還是應(yīng)該在我們的程序中明確的取消注冊(cè)，程序結(jié)束時(shí)應(yīng)該把所有的注冊(cè)都取消掉。

1.2集合中對(duì)象沒清理造成的內(nèi)存泄露

我們通常把一些對(duì)象的引用加入到了集合中，當(dāng)我們不需要該對(duì)象時(shí)，并沒有把它的引用從集合中清理掉，這樣這個(gè)集合就會(huì)越來越大。如果這個(gè)集合是static的話，那情況就更嚴(yán)重了。

二、資源對(duì)象沒關(guān)閉造成的內(nèi)存泄露

資源性對(duì)象比如（Cursor，F(xiàn)ile文件等）往往都用了一些緩沖，我們?cè)诓皇褂玫臅r(shí)候，應(yīng)該及時(shí)關(guān)閉它們，以便它們的緩沖及時(shí)回收內(nèi)存。它們的緩沖 不僅存在于java虛擬機(jī)內(nèi)，還存在于java虛擬機(jī)外。如果我們僅僅是把它的引用設(shè)置為null,而不關(guān)閉它們，往往會(huì)造成內(nèi)存泄露。因?yàn)橛行┵Y源性對(duì) 象，比如SQLiteCursor（在析構(gòu)函數(shù)finalize（）,如果我們沒有關(guān)閉它，它自己會(huì)調(diào)close()關(guān)閉），如果我們沒有關(guān)閉它，系統(tǒng)在 回收它時(shí)也會(huì)關(guān)閉它，但是這樣的效率太低了。因此對(duì)于資源性對(duì)象在不使用的時(shí)候，應(yīng)該調(diào)用它的close()函數(shù)，將其關(guān)閉掉，然后才置為null.在我 們的程序退出時(shí)一定要確保我們的資源性對(duì)象已經(jīng)關(guān)閉。

程序中經(jīng)常會(huì)進(jìn)行查詢數(shù)據(jù)庫(kù)的操作，但是經(jīng)常會(huì)有使用完畢Cursor后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小，對(duì)內(nèi)存的消耗不容易被發(fā)現(xiàn)，只有在常時(shí)間大量操作的情況下才會(huì)復(fù)現(xiàn)內(nèi)存問題，這樣就會(huì)給以后的測(cè)試和問題排查帶來困難和風(fēng)險(xiǎn)。

三、一些不良代碼成內(nèi)存壓力

有些代碼并不造成內(nèi)存泄露，但是它們，或是對(duì)沒使用的內(nèi)存沒進(jìn)行有效及時(shí)的釋放，或是沒有有效的利用已有的對(duì)象而是頻繁的申請(qǐng)新內(nèi)存，對(duì)內(nèi)存的回收和分配造成很大影響的，容易迫使虛擬機(jī)不得不給該應(yīng)用進(jìn)程分配更多的內(nèi)存，造成不必要的內(nèi)存開支。

3.1，Bitmap沒調(diào)用recycle()

Bitmap對(duì)象在不使用時(shí),我們應(yīng)該先調(diào)用recycle()釋放內(nèi)存，然后才它設(shè)置為null.雖然recycle()從源碼上看，調(diào)用它應(yīng)該能立 即釋放Bitmap的主要內(nèi)存，但是測(cè)試結(jié)果顯示它并沒能立即釋放內(nèi)存。但是我它應(yīng)該還是能大大的加速Bitmap的主要內(nèi)存的釋放。

3.2，構(gòu)造Adapter時(shí)，沒有使用緩存的 convertView

以構(gòu)造ListView的BaseAdapter為例，在BaseAdapter中提共了方法：

public  View getView(int position, View convertView, ViewGroup  parent)來向ListView提供每一個(gè)item所需要的view對(duì)象。初始時(shí)ListView會(huì)從BaseAdapter中根據(jù)當(dāng)前的屏幕布局實(shí) 例化一定數(shù)量的view對(duì)象，同時(shí)ListView會(huì)將這些view對(duì)象緩存起來。當(dāng)向上滾動(dòng)ListView時(shí)，原先位于最上面的list  item的view對(duì)象會(huì)被回收，然后被用來構(gòu)造新出現(xiàn)的最下面的list  item。這個(gè)構(gòu)造過程就是由getView()方法完成的，getView()的第二個(gè)形參 View  convertView就是被緩存起來的list item的view對(duì)象(初始化時(shí)緩存中沒有view對(duì)象則convertView是null)。

由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新實(shí)例化一個(gè)View對(duì)象的話，即浪費(fèi)時(shí)間，也造成內(nèi)存垃 圾，給垃圾回收增加壓力，如果垃圾回收來不及的話，虛擬機(jī)將不得不給該應(yīng)用進(jìn)程分配更多的內(nèi)存，造成不必要的內(nèi)存開支。ListView回收l(shuí)ist  item的view對(duì)象的過程可以查看:

view plaincopy to clipboardprint?

android.widget.AbsListView.java –> void addScrapView(View scrap) 方法。

在android的開發(fā)中，要時(shí)刻主要內(nèi)存的分配和垃圾回收，因?yàn)橄到y(tǒng)為每一個(gè)dalvik虛擬機(jī)分配的內(nèi)存是有限的，在google的G1中，分配的***堆大小只有 16M，后來的機(jī)器一般都為24M，實(shí)在是少的可憐。這樣就需要我們?cè)陂_發(fā)過程中要時(shí)刻注意。不要因?yàn)樽约旱拇a問題而造成OOM錯(cuò)誤。

JAVA的內(nèi)存管理：

大家都知道，android應(yīng)用層是由java開發(fā)的，android的davlik虛擬機(jī)與jvm也類似，只不過它是基于寄存器的。因此要了解android的內(nèi)存管理就必須得了解java的內(nèi)存分配和垃圾回收機(jī)制。

在java中，是通過new關(guān)鍵字來為對(duì)象分配內(nèi)存的，而內(nèi)存的釋放是由垃圾收集器（GC）來回收的，工程師在開發(fā)的過程中，不需要顯式的去管理內(nèi)存。 但是這樣有可能在不知不覺中就會(huì)浪費(fèi)了很多內(nèi)存，最終導(dǎo)致java虛擬機(jī)花費(fèi)很多時(shí)間去進(jìn)行垃圾回收，更嚴(yán)重的是造成JVM的OOM。因此，java工程 師還是有必要了解JAVA的內(nèi)存分配和垃圾回收機(jī)制。

下面列出了存在的問題，點(diǎn)擊detail進(jìn)去，會(huì)列出詳細(xì)的，可能會(huì)存在問題的代碼：

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-32625.png

file:///C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ksohtml/wps_clip_image-21158.png

關(guān)于MAT的使用可以參考：http://www.blogjava.net/rosen/ … .html

這位兄弟寫的比較詳細(xì)。

總結(jié)

不管是java還是android，都應(yīng)該了解內(nèi)存分配和垃圾回收機(jī)制，工程師要做到寫的代碼中沒有bad code很難，關(guān)鍵是在出現(xiàn)問題的時(shí)候該怎么去排查Android內(nèi)存優(yōu)化

一、 Android的內(nèi)存機(jī)制

Android的程序由Java語(yǔ)言編寫，所以Android的內(nèi)存管理與Java的內(nèi)存管理相似。程序員通過new為對(duì)象分配內(nèi)存，所有對(duì)象在java堆內(nèi)分配空間；然而對(duì)象的釋放是由垃圾回收器來完成的。C／C++中的內(nèi)存機(jī)制是“誰(shuí)污染，誰(shuí)治理”，java的就比較人性化了，給我們請(qǐng)了一個(gè)專門的清潔工（GC）。

那么GC怎么能夠確認(rèn)某一個(gè)對(duì)象是不是已經(jīng)被廢棄了呢？Java采用了有向圖的原理。Java將引用關(guān)系考慮為圖的有向邊，有向邊從引用者指向引用對(duì)象。 線程對(duì)象可以作為有向圖的起始頂點(diǎn)，該圖就是從起始頂點(diǎn)開始的一棵樹，根頂點(diǎn)可以到達(dá)的對(duì)象都是有效對(duì)象，GC不會(huì)回收這些對(duì)象。如果某個(gè)對(duì)象  (連通子圖)與這個(gè)根頂點(diǎn)不可達(dá)(注意，該圖為有向圖)，那么我們認(rèn)為這個(gè)(這些)對(duì)象不再被引用，可以被GC回收。

二、Android的內(nèi)存溢出

Android的內(nèi)存溢出是如何發(fā)生的?

Android的虛擬機(jī)是基于寄存器的Dalvik，它的***堆大小一般是16M，有的機(jī)器為24M。因此我們所能利用的內(nèi)存空間是有限的。如果我們的內(nèi)存占用超過了一定的水平就會(huì)出現(xiàn)OutOfMemory的錯(cuò)誤。

為什么會(huì)出現(xiàn)內(nèi)存不夠用的情況呢？我想原因主要有兩個(gè)：

由于我們程序的失誤，長(zhǎng)期保持某些資源（如Context）的引用，造成內(nèi)存泄露，資源造成得不到釋放。

保存了多個(gè)耗用內(nèi)存過大的對(duì)象（如Bitmap），造成內(nèi)存超出限制。

三、萬(wàn)惡的static

static是Java中的一個(gè)關(guān)鍵字，當(dāng)用它來修飾成員變量時(shí)，那么該變量就屬于該類，而不是該類的實(shí)例。所以用static修飾的變量，它的生命周期是很長(zhǎng)的，如果用它來引用一些資源耗費(fèi)過多的實(shí)例（Context的情況最多），這時(shí)就要謹(jǐn)慎對(duì)待了。

sBackground是一個(gè)靜態(tài)的變量，但是我們發(fā)現(xiàn)，我們并沒有顯式的保存Contex的引用，但是，當(dāng)Drawable與View連接之 后，Drawable就將View設(shè)置為一個(gè)回調(diào)，由于View中是包含Context的引用的，所以，實(shí)際上我們依然保存了Context的引用。這個(gè) 引用鏈如下：

Drawable->TextView->Context

所以，最終該Context也沒有得到釋放，發(fā)生了內(nèi)存泄露。

如何才能有效的避免這種引用的發(fā)生呢？

應(yīng)該盡量避免static成員變量引用資源耗費(fèi)過多的實(shí)例，比如Context。

Context盡量使用Application Context，因?yàn)锳pplication的Context的生命周期比較長(zhǎng)，引用它不會(huì)出現(xiàn)內(nèi)存泄露的問題。

使用WeakReference代替強(qiáng)引用。比如可以使用WeakReference<Context> mContextRef;

該部分的詳細(xì)內(nèi)容也可以參考Android文檔中Article部分。

四、都是線程惹的禍

線程也是造成內(nèi)存泄露的一個(gè)重要的源頭。線程產(chǎn)生內(nèi)存泄露的主要原因在于線程生命周期的不可控。我們來考慮下面一段代碼。

有些人喜歡用Android提供的AsyncTask，但事實(shí)上 AsyncTask的問題更加嚴(yán)重，Thread只有在run函數(shù)不結(jié)束時(shí)才出現(xiàn)這種內(nèi)存泄露問題，然而AsyncTask內(nèi)部的實(shí)現(xiàn)機(jī)制是運(yùn)用了 ThreadPoolExcutor,該類產(chǎn)生的Thread對(duì)象的生命周期是不確定的，是應(yīng)用程序無(wú)法控制的，因此如果AsyncTask作為 Activity的內(nèi)部類，就更容易出現(xiàn)內(nèi)存泄露的問題。

事實(shí)上，線程的問題并不僅僅在于內(nèi)存泄露，還會(huì)帶來一些災(zāi)難性的問題 。

五、行蹤詭異的Cursor

Cursor是Android查詢數(shù)據(jù)后得到的一個(gè)管理數(shù)據(jù)集合的類，正常情況下，如果查詢得到的數(shù)據(jù)量較小時(shí)不會(huì)有內(nèi)存問題，而且虛擬機(jī)能夠保證Cusor最終會(huì)被釋放掉。

然而如果Cursor的數(shù)據(jù)量特表大，特別是如果里面有Blob信息時(shí)，應(yīng)該保證Cursor占用的內(nèi)存被及時(shí)的釋放掉，而不是等待GC來處理。并且 Android明顯是傾向于編程者手動(dòng)的將Cursor close掉，因?yàn)樵谠创a中我們發(fā)現(xiàn)，如果等到垃圾回收器來回收時(shí)，會(huì)給用戶以錯(cuò)誤提示。

有一種情況下，我們不能直接將Cursor關(guān)閉掉，這就是在CursorAdapter中應(yīng)用的情況，但是注意，CursorAdapter在Acivity結(jié)束時(shí)并沒有自動(dòng)的將Cursor關(guān)閉掉，因此，你需要在onDestroy函數(shù)中，手動(dòng)關(guān)閉。

關(guān)于Android 中怎么做好內(nèi)存優(yōu)化問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。