androidheap詳解

㈠ android Studio的JVM內存不足問題怎麼解決

找到Eclipse安裝文件下的eclipse.ini配置文件
通常裡面都是寫的-vmargs-Xms40m-Xmx256m
-vmargs：說明後面是VM的參數
-Xms40m：虛擬機佔用系統的最小內存
Xmx256m：虛擬機佔用系統的最大內存
-XX:PermSize：最小堆大小.一般報內存不足時,都是說這個太小,堆空間剩餘小於5%就會警告,建議把這個稍微設大一點,不過要視自己機器內存大小來設置-XX:PermSize：最大堆大小.這個也適當大些，另外把裡面的參數改為：
-vmargs
-Xms128M
-Xmx512M
-XX:PermSize=128M
-XX:MaxPermSize=256M
1、設置Eclipse內存使用情況
修改eclipse根目錄下的eclipse.ini文件
-vmargs //虛擬機設置
-Xms40m
-Xmx256m
-XX:PermSize=128M //非堆內存設置
-XX:MaxPermSize=256M
2、JVM內存設置
打開eclipse window－preferences－java －Installed JREs －Edit －Default VM Arguments 在VM自變數中輸入：-Xmx128m -Xms64m -Xmn32m -Xss16m3, Tomcat內存設置
打開Tomcat根目錄下的bin文件夾，編輯catalina.bat 修改為：set JAVA_OPTS= -Xms256m -Xmx512m下面是這幾個設置的一些背景知識：
1 堆(Heap)和非堆(Non- heap)內存
按照官方的說法：「Java 虛擬機具有一個堆，堆是運行時數據區域，所有類實例和數組的內存均從此處分配。堆是在 Java 虛擬機啟動時創建的。」「在JVM中堆之外的內存稱為非堆內存(Non-heap memory)」。可以看出JVM主要管理兩種類型的內存：堆和非堆。簡單來說堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給 自己用的，所以方法區、JVM內部處理或優化所需的內存(如JIT編譯後的代碼緩存)、每個類結構(如運行時常數池、欄位和方法數據)以及方法和構造方法 的代碼都在非堆內存中。 2 堆內存分配
JVM初始分配的內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。默認空餘堆內存 小於 40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆內存大於70%時，JVM會減少堆直到-Xms的最小限制。因此伺服器一般設置-Xms、 -Xmx相等以避免在每次GC 後調整堆的大小。
3、非堆內存分配
JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。
4、JVM內存限制(最大值)
首先JVM內存首先受限於實際的最大物理內存，假設物理內存無限大的話，JVM內存的最大值跟操作系統有很大的關系。簡單的說就32位處理器雖然 可控內存空間有4GB,但是具體的操作系統會給一個限制，這個限制一般是2GB-3GB（一般來說Windows系統下為1.5G-2G，linux系統 下為 2G-3G），而64bit以上的處理器就不會有限制了

㈡ android heap size overflow怎麼處理

這是內存溢出，內存溢出的處理方法如下：

第一：不要為Context長期保存引用（要引用Context就要使得引用對象和它本身的生命周期保持一致）。
第二：如果要使用到Context，盡量使用Application Context去代替Context，因為Application Context的生命周期較長，引用情況下不會造成內存泄露問題
第三：在你不控制對象的生命周期的情況下避免在你的Activity中使用static變數。盡量使用WeakReference去代替一個static。
第四：垃圾回收器並不保證能准確回收內存，這樣在使用自己需要的內容時，主要生命周期和及時釋放掉不需要的對象。盡量在Activity的生命周期結束時，在onDestroy中把我們做引用的其他對象做釋放，比如：cursor.close()。

㈢ Android 內存溢出怎麼解決

Android雖然會自動管理內存，JAVA也有garbage collection (GC )內存回收機制。 但是如果程序在一次操作中打開幾個M的文件，那麼通常會出現下面的錯誤信息。 02-04 21:46:08.703: ERROR/dalvikvm-heap(2429): 1920000-byte external allocation too large for this process. 或 02-04 21:52:28.463: ERROR/AndroidRuntime(2429): java.lang.OutOfMemoryError: bitmap size exceeds VM budget 移動終端因為內存有限，往往圖片處理經常出現上述的錯誤。 解決方法： 1.明確調用System.gc(); 這種內存回收會有一定的作用，但是請不要太期待。 2.圖片處理完成後回收內存。 請在調用BitMap進行圖片處理後進行內存回收。 bitmap.recycle(); 這樣會把剛剛用過的圖片佔用的內存釋放。 3.圖片處理時指定大小。 下面這個方法處理幾個M的圖片時是必須的 BitMap getBitpMap(){ ParcelFileDescriptor pfd; try{ pfd = mCon.getContentResolver().openFileDescriptor(uri, "r"); }catch (IOException ex){ return null; } java.io.FileDescriptor fd = pfd.getFileDescriptor(); BitmapFactory.Options options = new BitmapFactory.Options(); //先指定原始大小 options.inSampleSize = 1; //只進行大小判斷 options.inJustDecodeBounds = true; //調用此方法得到options得到圖片的大小 BitmapFactory.decodeFileDescriptor(fd, null, options); //我們的目標是在800pixel的畫面上顯示。 //所以需要調用computeSampleSize得到圖片縮放的比例 options.inSampleSize = computeSampleSize(options, 800); //OK,我們得到了縮放的比例，現在開始正式讀入BitMap數據 options.inJustDecodeBounds = false; options.inDither = false; options.inPreferredConfig = Bitmap.Config.ARGB_8888; //根據options參數，減少所需要的內存 Bitmap sourceBitmap = BitmapFactory.decodeFileDescriptor(fd, null, options); return sourceBitmap; } //這個函數會對圖片的大小進行判斷，並得到合適的縮放比例，比如2即1/2,3即1/3 static int computeSampleSize(BitmapFactory.Options options, int target) { int w = options.outWidth; int h = options.outHeight; int candidateW = w / target; int candidateH = h / target; int candidate = Math.max(candidateW, candidateH); if (candidate == 0) return 1; if (candidate > 1) { if ((w > target) && (w / candidate) < target) candidate -= 1; } if (candidate > 1) { if ((h > target) && (h / candidate) < target) candidate -= 1; } if (VERBOSE) Log.v(TAG, "for w/h " + w + "/" + h + " returning " + candidate + "(" + (w/candidate) + " / " + (h/candidate)); return candidate; }

麻煩採納，謝謝!

㈣ 如何使用DDMS Heap查看Android應用內存情況

可以使用Eclipse DDMS的Heap進行測試。

首先，我們在DDMS的界面的設備選項中找到手機設備，可以看到它裡面正在運行的進程：

點一下"Cause GC", 相當於向虛擬機執行一次GC請求，然後無需再按就可以動態的查看該應用程序的內存使用情況。

最值得關注的就是」data object「的"Total Size"，它決定了是否存在內存泄露的危險。一般情況下，它都是固定在一個穩定的數值范圍，如果回落非常大，或者該數值非常大，像是3.55後就會被kill掉，說明該應用程序的內存使用情況不佳，代碼結構需要優化。

㈤ android eclipse如何查看 heap內存分配到哪兒了

切換到DDMS 界面 ，點擊device下的具體的某一個進程，然後點擊小蟲子右邊的 Update Heap，再點擊右邊的GC ，就可以看到應用程序佔用的內存！！

㈥ 安卓內存的heap size和pss的區別

棧是一種線形集合，其添加和刪除元素的操作應在同一段完成。棧按照後進先出的方式進行處理。
堆是棧的一個組成元素

㈦ Android通過java如何獲取Vm heap

程序要讀取數據近10W行記錄時出現異常:java.lang.OutOfMemoryError:Javaheapspace在JVM中如果98%的時間是用於GC且可用的Heapsize不足2%的時候將拋出此異常信息。JVM堆的設置是指java程序運行過程中JVM可以調配使用的內存空間的設置.JVM在啟動的時候會自動設置Heapsize的值，其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。可以利用JVM提供的-Xmn-Xms-Xmx等選項可進行設置。例如：java-jar-Xmn16m-Xms64m-Xmx128mMyApp.jar如果HeapSize設置偏小，除了這些異常信息外，還會發現程序的響應速度變慢了。GC佔用了的時間，而應用分配到的執行時間較少。HeapSize最大不要超過可用物理內存的80%，一般的要將-Xms和-Xmx選項設置為相同，而-Xmn為1/4的-Xmx值。Heapsize的-Xms-Xmn設置不要超出物理內存的大小。否則會提示「heap」。這個問題的根源是jvm虛擬機的默認Heap大小是64M,可以通過設置其最大和最小值來實現.設置的方法主要是幾個.1.可以在windows更改系統環境變數加上JAVA_OPTS=-Xms64m-Xmx512m2,如果用的tomcat,在windows下,可以在C:\tomcat5.5.9\bin\catalina.bat中加上:setJAVA_OPTS=-Xms64m-Xmx256m位置在:remGuessCATALINA_HOMEifnotdefined這行的下面加合適.3.如果是linux系統Linux在{tomcat_home}/bin/catalina.sh的前面，加setJAVA_OPTS='-Xms64-Xmx512註：如果在測試的時候可能會用Eclispe這時候就需要在Eclipse->run-arguments中的VMarguments中輸入-Xms32m-Xmx800m這個參數就可以了。

㈧ Android 重學系列 ion驅動源碼淺析

上一篇文章，在解析初始化GraphicBuffer中，遇到一個ion驅動，對圖元進行管理。首先看看ion是怎麼使用的：

我們按照這個流程分析ion的源碼。

如果對ion使用感興趣，可以去這篇文章下面看 https://blog.csdn.net/hexiaolong2009/article/details/102596744

本文基於Android的Linux內核版本3.1.8

遇到什麼問題歡迎來本文討論 https://www.jianshu.com/p/5fe57566691f

什麼是ion？如果是音視頻，Camera的工程師會對這個驅動比較熟悉。最早的GPU和其他驅動協作申請一塊內存進行繪制是使用比較粗暴的共享內存。在Android系統中使用的是匿名內存。最早由三星實現了一個Display和Camera共享內存的問題，曾經在Linux社區掀起過一段時間。之後各路大牛不斷的改進之下，就成為了dma_buf驅動。並在 Linux-3.3 主線版本合入主線。現在已經廣泛的運用到各大多媒體開發中。

首先介紹dma_buf的2個角色，importer和exporter。importer是dma_buf驅動中的圖元消費者，exporter是dma_buf驅動中的圖元生產者。

這里借用大佬的圖片：

ion是基於dma_buf設計完成的。經過閱讀源碼，其實不少思路和Android的匿名內存有點相似。閱讀本文之前就算不知道dma_buf的設計思想也沒關系，我不會仔細到每一行，我會注重其在gralloc服務中的申請流程，看看ion是如何管理共享內存，為什麼要拋棄ashmem。

我們先來看看ion的file_operation:

只有一個open和ioctl函數。但是沒有mmap映射。因此mmap映射的時候一定其他對象在工作。

我們關注顯卡英偉達的初始化模塊。
文件：/ drivers / staging / android / ion / tegra / tegra_ion.c

mole_platform_driver實際上就是我之前經常提到過的mole_init的一個宏,多了一個register注冊到對應名字的平台中的步驟。在這裡面注冊了一個probe方法指針，probe指向的tegra_ion_probe是載入內核模塊注冊的時候調用。

先來看看對應的結構體：

再來看看對應ion內的堆結構體：

完成的事情如下幾個步驟：

我們不關注debug模式。其實整個就是我們分析了很多次的方法。把這個對象注冊miscdevice中。等到insmod就會把整個整個內核模塊從dev_t的map中關聯出來。

我們來看看這個驅動結構體：

文件：/ drivers / staging / android / ion / ion_heap.c

這里有四個不同堆會申請出來，我們主要來看看默認的ION_HEAP_TYPE_SYSTEM對應的heap流程。

其實真正象徵ion的內存堆是下面這個結構體

不管原來的那個heap，會新建3個ion_system_heap，分別order為8，4，0,大於4為大內存。意思就是這個heap中持有一個ion_page_pool 頁資源池子，裡面只有對應order的2的次冪，內存塊。其實就和夥伴系統有點相似。

還會設置flag為ION_HEAP_FLAG_DEFER_FREE，這個標志位後面會用到。

文件：/ drivers / staging / android / ion / ion_page_pool.c

在pool中分為2個鏈表一個是high_items，另一個是low_items。他們之間的區分在此時就是以2為底4的次冪為分界線。

文件：/ drivers / staging / android / ion / ion.c

因為打開了標志位ION_HEAP_FLAG_DEFER_FREE和heap存在shrink方法。因此會初始化兩個回收函數。

文件：/ drivers / staging / android / ion / ion_heap.c

此時會創建一個內核線程，調用ion_heap_deferred_free內核不斷的循環處理。不過由於這個線程設置的是SCHED_IDLE，這是最低等級的時間片輪轉搶占。和Handler那個adle一樣的處理規則，就是閑時處理。

在這個循環中，不斷的循環銷毀處理heap的free_list裡面已經沒有用的ion_buffer緩沖對象。

文件：/ drivers / staging / android / ion / ion_system_heap.c

注冊了heap的銷毀內存的方法。當系統需要銷毀頁的時候，就會調用通過register_shrinker注冊進來的函數。

文件：/ drivers / staging / android / ion / ion_page_pool.c

整個流程很簡單，其實就是遍歷循環需要銷毀的頁面數量，接著如果是8的次冪就是移除high_items中的page緩存。4和0則銷毀low_items中的page緩存。至於為什麼是2的次冪其實很簡單，為了銷毀和申請簡單。__free_pages能夠整頁的銷毀。

文件：/ drivers / staging / android / ion / ion.c

主要就是初始化ion_client各個參數，最後把ion_client插入到ion_device的clients。來看看ion_client結構體：

核心還是調用ion_alloc申請一個ion緩沖區的句柄。最後把數據拷貝會用戶空間。

這個實際上就是找到最小能承載的大小，去申請內存。如果8kb申請內存，就會拆分積分在0-4kb，4kb-16kb，16kb-128kb區間找。剛好dma也是在128kb之內才能申請。超過這個數字就禁止申請。8kb就會拆成2個4kb保存在第一個pool中。

最後所有的申請的page都添加到pages集合中。

文件：/ drivers / staging / android / ion / ion_page_pool.c

能看到此時會從 ion_page_pool沖取出對應大小區域的空閑頁返回上層，如果最早的時候沒有則會調用ion_page_pool_alloc_pages申請一個新的page。由於引用最終來自ion_page_pool中，因此之後申請之後還是在ion_page_pool中。

這里的處理就是為了避免DMA直接內存造成的緩存差異(一般的申請，默認會帶一個DMA標志位)。換句話說，是否打開cache其實就是，關閉了則使用pool的cache，打開了則不使用pool緩存，只依賴DMA的緩存。

我們可以看另一個dma的heap，它是怎麼做到dma內存的一致性.
文件： drivers / staging / android / ion / ion_cma_heap.c

能看到它為了能辦到dma緩存的一致性，使用了dma_alloc_coherent創建了一個所有強制同步的地址，也就是沒有DMA緩存的地址。

這里出現了幾個新的結構體，sg_table和scatterlist

文件：/ lib / scatterlist.c

這裡面實際上做的事情就是一件：初始化sg_table.
sg_table中有一個核心的對象scatterlist鏈表。如果pages申請的對象數量<PAGE_SIZE/sizeof(scatterlist),每一項sg_table只有一個scatterlist。但是超出這個數字就會增加一個scatterlist。

用公式來說：

換句話說，每一次生成scatterlist的鏈表就會直接盡可能占滿一頁，讓內存更好管理。

返回了sg_table。

初始化ion_handle，並且記錄對應的ion_client是當前打開文件的進程，並且設置ion_buffer到handle中。使得句柄能夠和buffer關聯起來。

每當ion_buffer需要銷毀，

㈨ 怎麼用android studio抓heap mp

一個heap mp就是一個程序heap的快照，可以獲知程序的哪些部分正在使用大部分的內存。
它保存為一種叫做HPROF的二
進制格式。對於Android執行android.os.Debug.mpHprofData(hprofPath)方法後所生成的文件，需要
把.hprof文件從Dalvik格式轉換成J2SE HPROF格式。使用AndroidSDK提供的hprof-conv工具可執行該轉換操作。

㈩ 在android studio中怎麼設置heap size

參考如下內容，設置內存的大小：
Android命令行提供setprop和getprop這兩個命令來設置Android系統的一些屬性，就比如說虛擬機堆內存大小等等。
但這兩個命令必須在root許可權下設置才能生效，並且必須在root許可權下重啟shell
操作命令如下：

[cpp] view plain
adb root
adb shell setprop dalvik.vm.heapgrowthlimit 64m
adb shell setprop dalvik.vm.heapsize 192m
adb shell stop
adb shell start
adb shell getprop dalvik.vm.heapsize