Android内存泄漏问题（一）
前言
???不少人認(rèn)為JAVA程序，因?yàn)橛欣厥諜C(jī)制，應(yīng)該沒有內(nèi)存泄露。
其實(shí)如果我們一個(gè)程序中，已經(jīng)不再使用某個(gè)對象，但是因?yàn)槿匀挥幸弥赶蛩?#xff0c;垃圾回收器就無法回收它，當(dāng)然該對象占用的內(nèi)存就無法被使用，這就造成了內(nèi)存泄露。如果我們的java運(yùn)行很久,而這種內(nèi)存泄露不斷的發(fā)生，最后就沒內(nèi)存可用了。當(dāng)然java的，內(nèi)存泄漏和C/C++是不一樣的。如果java程序完全結(jié)束后，它所有的對象就都不可達(dá)了，系統(tǒng)就可以對他們進(jìn)行垃圾回收，它的內(nèi)存泄露僅僅限于它本身，而不會(huì)影響整個(gè)系統(tǒng)的。C/C++的內(nèi)存泄露就比較糟糕了，它的內(nèi)存泄露是系統(tǒng)級，即使該C/C++程序退出，它的泄露的內(nèi)存也無法被系統(tǒng)回收，永遠(yuǎn)不可用了，除非重啟機(jī)器。
Android的一個(gè)應(yīng)用程序的內(nèi)存泄露對別的應(yīng)用程序影響不大。為了能夠使得Android應(yīng)用程序安全且快速的運(yùn)行，Android的每個(gè)應(yīng)用程序都會(huì)使用一個(gè)專有的Dalvik虛擬機(jī)實(shí)例來運(yùn)行，它是由Zygote服務(wù)進(jìn)程孵化出來的，也就是說每個(gè)應(yīng)用程序都是在屬于自己的進(jìn)程中運(yùn)行的。Android為不同類型的進(jìn)程分配了不同的內(nèi)存使用上限，如果程序在運(yùn)行過程中出現(xiàn)了內(nèi)存泄漏的而造成應(yīng)用進(jìn)程使用的內(nèi)存超過了這個(gè)上限，則會(huì)被系統(tǒng)視為內(nèi)存泄漏，從而被kill掉，這使得僅僅自己的進(jìn)程被kill掉，而不會(huì)影響其他進(jìn)程（如果是system_process等系統(tǒng)進(jìn)程出問題的話，則會(huì)引起系統(tǒng)重啟）。
一、引用沒釋放造成的內(nèi)存泄露
1.1、注冊沒取消造成的內(nèi)存泄露
??這種Android的內(nèi)存泄露比純java的內(nèi)存泄露還要嚴(yán)重，因?yàn)槠渌恍〢ndroid程序可能引用我們的Anroid程序的對象（比如注冊機(jī)制）。即使我們的Android程序已經(jīng)結(jié)束了，但是別的引用程序仍然還有對我們的Android程序的某個(gè)對象的引用，泄露的內(nèi)存依然不能被垃圾回收。
比如
????假設(shè)我們希望在鎖屏界面(LockScreen)中，監(jiān)聽系統(tǒng)中的電話服務(wù)以獲取一些信息(如信號強(qiáng)度等)，則可以在LockScreen中定義一個(gè)PhoneStateListener的對象，同時(shí)將它注冊到TelephonyManager服務(wù)中。對于LockScreen對象，當(dāng)需要顯示鎖屏界面的時(shí)候就會(huì)創(chuàng)建一個(gè)LockScreen對象，而當(dāng)鎖屏界面消失的時(shí)候LockScreen對象就會(huì)被釋放掉。
????但是如果在釋放LockScreen對象的時(shí)候忘記取消我們之前注冊的PhoneStateListener對象，則會(huì)導(dǎo)致LockScreen無法被垃圾回收。如果不斷的使鎖屏界面顯示和消失，則最終會(huì)由于大量的LockScreen對象沒有辦法被回收而引起OutOfMemory,使得system_process進(jìn)程掛掉。
雖然有些系統(tǒng)程序，它本身好像是可以自動(dòng)取消注冊的（當(dāng)然不及時(shí)），但是我們還是應(yīng)該在我們的程序中明確的取消注冊，程序結(jié)束時(shí)應(yīng)該把所有的注冊都取消掉。
1.2、集合容器對象沒清理造成的內(nèi)存泄露
我們通常把一些對象的引用加入到了集合容器（比如ArrayList）中，當(dāng)我們不需要該對象時(shí)，并沒有把它的引用從集合中清理掉，這樣這個(gè)集合就會(huì)越來越大。如果這個(gè)集合是static的話，那情況就更嚴(yán)重了。
?
1.3、Context泄漏 所謂的Context泄漏，其實(shí)更多的是指Activity泄露，這是一個(gè)很隱晦的OutOfMemoryError的情況。 先看一個(gè)Android官網(wǎng)提供的例子：? 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ò)誤的； 在第一次屏幕方向切換時(shí)它泄露了一開始創(chuàng)建的Activity。當(dāng)一個(gè)Drawable附加到一個(gè) View上時(shí)， View會(huì)將其作為一個(gè)callback設(shè)定到Drawable上。上述的代碼片段，意味著這個(gè)靜態(tài)的Drawable擁有一個(gè)TextView的引用，? 而TextView又擁有Activity（Context類型）的引用，換句話說，Drawable擁有了更多的對象引用。即使Activity被 銷毀，內(nèi)存仍然不會(huì)被釋放。? 另外，對Context的引用超過它本身的生命周期，也會(huì)導(dǎo)致該Context無法回收，從而導(dǎo)致內(nèi)存泄漏。所以盡量使用Application這種Context類型。? 這種Context擁有和應(yīng)用程序一樣長的生命周期，并且不依賴Activity的生命周期。如果你打算保存一個(gè)長時(shí)間的對象，? 并且其需要一個(gè) Context，記得使用Application對象。你可以通過調(diào)用Context.getApplicationContext()或 Activity.getApplication()輕松得到Application對象。? 最近遇到一種情況引起了Context泄漏，就是在Activity銷毀時(shí)，里面有其他線程沒有停。? 總結(jié)一下避免Context泄漏應(yīng)該注意的問題：? 1.盡量使用Application這種Context類型。? 2.注意對Context的引用不要超過它本身的生命周期。? 3.慎重的對Context使用“static”關(guān)鍵字。? 4.Context里如果有線程，一定要在onDestroy()里及時(shí)停掉。? 1.4、static關(guān)鍵字的濫用 當(dāng)類的成員變量聲明成static后，它是屬于類的而不是屬于對象的，如果我們將很大的資源對象（Bitmap，context等）聲明成static，那么這些資源不會(huì)隨著對象的回收而回收， 會(huì)一直存在，所以在使用static關(guān)鍵字定義成員變量的時(shí)候要慎重。 1.5、WebView對象沒有銷毀 當(dāng)我們不要使用WebView對象時(shí)，應(yīng)該調(diào)用它的destory()函數(shù)來銷毀它，并釋放其占用的內(nèi)存，否則其占用的內(nèi)存長期也不能被回收，從而造成內(nèi)存泄露 1.6、GridView的濫用 GridView和ListView的實(shí)現(xiàn)方式不太一樣。GridView的View不是即時(shí)創(chuàng)建的，而是全部保存在內(nèi)存中的。比如一個(gè)GridView有100項(xiàng)，雖然我們只能看到10項(xiàng)，但是其實(shí)整個(gè)100項(xiàng)都是在內(nèi)存中的。二、資源對象沒關(guān)閉造成的內(nèi)存泄露
資源性對象比如（Cursor，File文件等）往往都用了一些緩沖，我們在不使用的時(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源性對象，比如SQLiteCursor（在析構(gòu)函數(shù)finalize（）,如果我們沒有關(guān)閉它，它自己會(huì)調(diào)close()關(guān)閉），如果我們沒有關(guān)閉它，系統(tǒng)在回收它時(shí)也會(huì)關(guān)閉它，但是這樣的效率太低了。因此對于資源性對象在不使用的時(shí)候，應(yīng)該調(diào)用它的close()函數(shù)，將其關(guān)閉掉，然后才置為null.在我們的程序退出時(shí)一定要確保我們的資源性對象已經(jīng)關(guān)閉。
程序中經(jīng)常會(huì)進(jìn)行查詢數(shù)據(jù)庫的操作，但是經(jīng)常會(huì)有使用完畢Cursor后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小，對內(nèi)存的消耗不容易被發(fā)現(xiàn)，只有在常時(shí)間大量操作的情況下才會(huì)復(fù)現(xiàn)內(nèi)存問題，這樣就會(huì)給以后的測試和問題排查帶來困難和風(fēng)險(xiǎn)。
三、一些不良代碼成內(nèi)存壓力
有些代碼并不造成內(nèi)存泄露，但是它們，或是對沒使用的內(nèi)存沒進(jìn)行有效及時(shí)的釋放，或是沒有有效的利用已有的對象而是頻繁的申請新內(nèi)存，對內(nèi)存的回收和分配造成很大影響的，容易迫使虛擬機(jī)不得不給該應(yīng)用進(jìn)程分配更多的內(nèi)存，造成不必要的內(nèi)存開支。
3.1、Bitmap沒調(diào)用recycle()
Bitmap對象在不使用時(shí),我們應(yīng)該先調(diào)用recycle()，然后才它設(shè)置為null.
雖然Bitmap在被回收時(shí)可以通過BitmapFinalizer來回收內(nèi)存。但是調(diào)用recycle()是一個(gè)良好的習(xí)慣
在Android4.0之前，Bitmap的內(nèi)存是分配在Native堆中，調(diào)用recycle()可以立即釋放Native內(nèi)存。
從Android4.0開始，Bitmap的內(nèi)存就是分配在dalvik堆中，即JAVA堆中的，調(diào)用recycle()并不能立即釋放Native內(nèi)存。但是調(diào)用recycle()也是一個(gè)良好的習(xí)慣。
可以通過dumpsys meminfo命令查看一個(gè)進(jìn)程的內(nèi)存情況。
示例：adb shell "dumpsys meminfo com.lenovo.robin"
?
運(yùn)行結(jié)果。
Applications Memory Usage (kB):
Uptime: 18696550 Realtime: 18696541
?
** MEMINFO in pid 7985 [com.lenovo.robin] **
????????????????????native ??dalvik ???other ???total
????????????size: ????4828 ????5379 ?????N/A ???10207
???????allocated: ????4073 ????2852 ?????N/A ????6925
????????????free: ??????10 ????2527 ?????N/A ????2537
???????????(Pss): ?????608 ?????317 ????1603 ????2528
??(shared dirty): ????2240 ????1896 ????6056 ???10192
????(priv dirty): ?????548 ??????36 ????1276 ????1860
?
?Objects
???????????Views: ???????0 ???????ViewRoots: ???????0
?????AppContexts: ???????0 ??????Activities: ???????0
??????????Assets: ???????2 ???AssetManagers: ???????2
???Local Binders: ???????5 ???Proxy Binders: ??????11
Death Recipients: ???????1
?OpenSSL Sockets: ???????0
?
?SQL
???????????????heap: ???????0 ????????MEMORY_USED: ???????0
?PAGECACHE_OVERFLOW: ???????0 ????????MALLOC_SIZE: ???????0
關(guān)于內(nèi)存統(tǒng)計(jì)的更多內(nèi)容請參考《Android內(nèi)存泄露利器（內(nèi)存統(tǒng)計(jì)篇）》
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對象。初始時(shí)ListView會(huì)從BaseAdapter中根據(jù)當(dāng)前的屏幕布局實(shí)例化一定數(shù)量的view對象，同時(shí)ListView會(huì)將這些view對象緩存起來。當(dāng)向上滾動(dòng)ListView時(shí)，原先位于最上面的list?item的view對象會(huì)被回收，然后被用來構(gòu)造新出現(xiàn)的最下面的list?item。這個(gè)構(gòu)造過程就是由getView()方法完成的，getView()的第二個(gè)形參?View?convertView就是被緩存起來的list?item的view對象(初始化時(shí)緩存中沒有view對象則convertView是null)。
????由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新實(shí)例化一個(gè)View對象的話，即浪費(fèi)時(shí)間，也造成內(nèi)存垃圾，給垃圾回收增加壓力，如果垃圾回收來不及的話，虛擬機(jī)將不得不給該應(yīng)用進(jìn)程分配更多的內(nèi)存，造成不必要的內(nèi)存開支。ListView回收list?item的view對象的過程可以查看:
android.widget.AbsListView.java?-->?void?addScrapView(View?scrap)?方法。
示例代碼：
public?View?getView(int?position,?View?convertView,?ViewGroup?parent)?{
????View?view?=?new?Xxx(...);
????...?...
????return?view;
}
修正示例代碼：
public?View?getView(int?position,?View?convertView,?ViewGroup?parent)?{
????View?view?=?null;
????if?(convertView?!=?null)?{
????????view?=?convertView;
????????populate(view,?getItem(position));
????????...
????}?else?{
????????view?=?new?Xxx(...);
????????...
????}
????return?view;
}?
3.3、ThreadLocal使用不當(dāng)
如果我們粗暴的把ThreadLocal設(shè)置null,而不調(diào)用remove()方法或set(null),那么就可能造成ThreadLocal綁定的對象長期也不能被回收，因而產(chǎn)出內(nèi)存泄露。 關(guān)于此的更多內(nèi)容請參考《ThreadLocal的內(nèi)存泄露》 四、JNI代碼的內(nèi)存泄露 關(guān)于此的詳細(xì)內(nèi)容請參考《JNI引用與垃圾回收》轉(zhuǎn)載于:https://www.cnblogs.com/sage-blog/p/4085880.html
總結(jié)
以上是生活随笔為你收集整理的Android内存泄漏问题（一）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HTML 的超链接 a 标签中如何设置其
- 下一篇： 检測磁盘驱动的健康程度SMART