如何定位和解決Android的內(nèi)存溢出問題

一、定位內(nèi)存泄漏：

10年積累的網(wǎng)站設(shè)計制作、做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先做網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有圖木舒克免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

可以用LeakCanary:檢測所有的內(nèi)存泄漏

二、解決：

1.對各種流，文件資源這些比如：InputStream/OutputStream，SQLiteOpenHelper，SQLiteDatabase，Cursor，文件，I/O，Bitmap圖片等操作等都應(yīng)該記得顯示關(guān)閉。

2.盡量避免static成員變量引用資源耗費過多的實例,比如Context。因為Context的引用超過它本身的生命周期，會導(dǎo)致Context泄漏。所以盡量使用Application這種Context類型。

3.使用線程池，不要newthread

4.UI視圖檢查，減少視圖層級（hierarchyviewer）。

5.圖片優(yōu)化

6. 重用系統(tǒng)資源：系統(tǒng)定義id，系統(tǒng)圖片，系統(tǒng)布局，系統(tǒng)style，系統(tǒng)字符串，系統(tǒng)顏色定義

怎么解決android內(nèi)存溢出問題的

一、內(nèi)存溢出

現(xiàn)在的智能手機內(nèi)存已經(jīng)足夠大，但是對于一個應(yīng)用程序來說智能手機當(dāng)中稀缺的內(nèi)存，仍然是應(yīng)用程序的一大限制。在Android應(yīng)用程序開發(fā)當(dāng)中，最常見的內(nèi)存溢出問題（OOM）是在加載圖片時出現(xiàn)的，尤其是在不知道圖片大小的情況下。

潛在的內(nèi)存溢出操作主要包括以下幾點：

1、從網(wǎng)絡(luò)當(dāng)中加載用戶特定的圖片。因為直到我們在下載圖片的時候我們才知道圖片的大小。

2、向Gallery加載圖片。因為現(xiàn)在智能手機的攝像頭有很高的分辨率，在加載圖片的時候需要最圖片進行處理，然后才能正常的使用。

請注意一點，Android系統(tǒng)是從系統(tǒng)全局的觀念來分配內(nèi)存以加載圖片的，這就意味著，即使你的應(yīng)用有足夠大的內(nèi)存可用，內(nèi)存溢出問題（out of memroy，OOM）仍然可能出現(xiàn)，因為所有的應(yīng)用共享一個加載圖片的內(nèi)存池（我們使用BitmapFactory進行解析）。

二、解決內(nèi)存溢出問題

原文（Downsampling為了好理解，解釋為，程序A）。程序A通過調(diào)整像素，同時使其均衡化來降低圖片的分辨率。因為不管問題圖片是因為太大而不能再手機上正常顯現(xiàn)，這個圖片都會縮短其寬度以在ImageView當(dāng)中顯示，當(dāng)圖片在ImageView當(dāng)中顯示時，我們會因為加載一些沒有必要的原始圖片而浪費掉內(nèi)存。

因此，更加有效的加載圖片的時機是在其初始化處理的時候。

以下是處理代碼：

1: private static Bitmap getResizedImage(String path, byte[] data, int targetWidth){2:3: BitmapFactory.Options options = new BitmapFactory.Options();

14: options.inSampleSize = ssize;15:16: Bitmap bm = null;17: try{18: bm = decode(path, data, options);

19: }catch(OutOfMemoryError e){

39: result = result * 2;40:41: }42:43: return result;44: }三、AQuery當(dāng)在Android應(yīng)用程序開發(fā)當(dāng)中使用AQuery組件時，處理這個問題會變的更加的簡單。

android內(nèi)存溢出怎么解決方案

一、Android中內(nèi)存溢出泄露監(jiān)測

1、內(nèi)存監(jiān)測工具?DDMS -- Heap

2、使用方法比較簡單：

·????????選擇DDMS視圖，并打開Devices視圖和Heap視圖

·????????點擊選擇要監(jiān)控的進程，比如：上圖中我選擇的是system_process

·????????選中Devices視圖界面上的"update heap"?圖標(biāo)

·????????點擊Heap視圖中的"Cause GC"?按鈕（相當(dāng)于向虛擬機發(fā)送了一次GC請求的操作）

3、在Heap視圖中選擇想要監(jiān)控的Type，一般我們會觀察dataobject的?total size的變化，正常情況下total size的值會穩(wěn)定在一個有限的范圍內(nèi)，也就說程序中的代碼良好，沒有造成程序中的對象不被回收的情況。如果代碼中存在沒有釋放對象引用的情況，那么data object的total size在每次GC之后都不會有明顯的回落，隨著操作次數(shù)的增加而total size也在不斷的增加。（說明：選擇好data object后，不斷的操作應(yīng)用，這樣才可以看出total size的變化）。如果totalsize確實是在不斷增加而沒有回落，說明程序中有沒有被釋放的資源引用。

二、Android中內(nèi)存溢出解決：

通過DDMS工具可以判斷應(yīng)用程序中是否存在內(nèi)存泄漏的問題，那又如何定位到具體出現(xiàn)問題的代碼片段，最終找到問題所在呢？內(nèi)存分析工具MAT Memory Analyzer Tool解決了這一難題。MAT工具是一個Eclipse 插件，同時也有單獨的RCP 客戶端，MAT工具的解析文件是.hprof，這個文件存放了某進程的內(nèi)存快照。MAT工具定位內(nèi)存泄漏具體位置的方法如下：

① 生成.hprof文件。Eclipse中生成.hprof文件的方法有很多，不同Android版本中生成.hprof的方式也稍有差別，但它們整體思路是一樣的。我們在DDMS界面選中想要分析的應(yīng)用進程，在Devices視圖界面上方的一行圖標(biāo)按鈕中，同時選中“Update Heap”和“Dump HPROF file”兩個按鈕，這時DDMS將會自動生成當(dāng)前選中進程的.hprof文件。

② 將.hprof 文件導(dǎo)入到MAT工具中，MAT工具會自動解析并生成報告，點擊“Dominator Tree”按鈕，并按包分組，選擇已定義的包類點右鍵，在彈出的菜單中選擇List objects﹥With incoming references，這時會列出所有可疑的類。右鍵點擊某一項，并選擇Path to GC Roots﹥excludeweak/soft references，MAT工具會進一步篩選出跟程序相關(guān)的所有內(nèi)存泄漏的類。這樣就可以追蹤到某一個產(chǎn)生內(nèi)存溢出泄漏的類的具體代碼中。