一般Java虚拟机要求支持verbosegc选项，输出详细的垃圾收集调试信息。dalvik虚拟机很安静的接受verbosegc选项，然后什么都不做。dalvik虚拟机使用自己的一套LOG机制来输出调试信息。
如果在Linux下运行adb logcat命令，可以看到如下的输出：
D/dalvikvm(745): GC_CONCURRENT
freed 199K, 53% free 3023K/6343K,external 0K/0K, paused 2ms+2ms
其中D/dalvikvm表示由dalvikvm输出的调试信息，括号后的数字代表dalvikvm所在进程的pid。
GC_CONCURRENT表示触发垃圾收集的原因，有以下几种：
GC_MALLOC, 内存分配失败时触发
GC_CONCURRENT，当分配的对象大小超过384K时触发
GC_EXPLICIT，对垃圾收集的显式调用(System.gc)
GC_EXTERNAL_ALLOC，外部内存分配失败时触发
freed 199K表示本次垃圾收集释放了199K的内存，
53% free 3023K/6343K，其中6343K表示当前内存总量，3023K表示可用内存。
external 0K/0K，表示可用外部内存/外部内存总量
paused
2ms+2ms，第一个时间值表示markrootset的时间，第二个时间值表示第二次mark的时间。如果触发原因不是GC_CONCURRENT，这一行为单个时间值，表示垃圾收集的耗时时间。
在dalvik中，GC的类型有三种：
1、GC_EXPLICIT：
应用主动调用System.gc()产生的GC事件。
2、GC_FOR_ALLOC：
内存分配时，发现可用内存不够时触发的GC事件。
3、GC_CONCURRENT：
给java层的class分配内存后，计算已分配的大小达到阈值(当前DVM heap size小一点)时会触发的GC事件。
因为第2和第3中GC是由系统触发的，所以应用是无法减少这两种类型的GC事件。但需要减少这两种GC事件是，可以通过配置dalvik的系统属性或者修改dalvik的GC算法来实现，本文只对修改dalvik的系统属性的方式进行介绍。
dalvik与GC相关的属性有：
dalvik.vm.heapstartsize：初始化dalvik分配的内存大小。
dalvik.vm.heapgrowthlimit：没有在mainfest中设置android:largeheap="true"时，应用的最大内存，超过这个值会有 OOM产生。
dalvik.vm.heapsize：在mainfest中设置android:largeheap="true"时，应用的最大内存，超过这个值会有 OOM产生。
dalvik.vm.heaputilization、dalvik.vm.heapminfree 、dalvik.vm.heapmaxfree：dalvik GC时使用的参数。
dalvim GC策略是：
1.在一次GC后，根据当前Heap中已分配的内存大小除以dalvik.vm.heaputilization(0.75),得到一个目标值。
2.如果目标值不在（已分配的值+dalvik.vm.heapminfree）到（已分配的值+dalvik.vm.heapmaxfree）这个区间，即取区间边界值做为目标值(运行一段时间后第1步得到的目标值肯定会超过这个范围)。
3.虚拟机记录这个目标值，当做当前允许总的可以分配到的内存。同时根据目标值减去固定值（200~500K),当做触发GC_CONCURRENT事件的阈值。
4.当下一次分配内存，分配成功时。重新计算已分配的内存大小；若有达到GC_CONCURRENT的阈值，则产生GC。
5.当下一次分配内存，开始分配失败时。则会产生GC_FOR_ALLOC事件，释放内存；然后再尝试分配。
可以通过调整dalvik.vm.heapminfree 和dalvik.vm.heapmaxfree属性的值，减少GC_FOR_ALLOC和GC_CONCURRENT的次数，如果这两个值设置的过大，则会导致一次GC的时间过长，从而会看到明显的卡顿现象，设置的值既要使GC的次数减少，也不能是一次GC的时间过长。
在有的平台上，可以通过代码对单个应用的dalvik的属性进行设置，以减少对全局设置对系统的影响，可以再App里面通过如下的方式对当前的App的dalvik属性设置：
import dalvik.system.VMRuntime;
import android.os.SystemProperties;
...
VMRuntime.getRuntime().setTargetHeapUtilization(0.75f);
VMRuntime.getRuntime().setTargetHeapMinFree(2*1024*1024);
VMRuntime.getRuntime().setTargetHeapConcurrentStart(8*1024*1024);
...
如果想通过系统进行控制，也可以在framework里面的ActivityThread的handleBindApplication函数里面进行设置：
import dalvik.system.VMRuntime;
import android.os.SystemProperties;
import java.lang.*;
...
if( data.processName.equals("com.android.launcher")) {
VMRuntime.getRuntime().setTargetHeapUtilization(0.75f);
VMRuntime.getRuntime().setTargetHeapMinFree(2*1024*1024);
VMRuntime.getRuntime().setTargetHeapConcurrentStart(8*1024*1024);
}
...
|
GC_FOR_MALLOC means that the GC was triggered because there wasn't enough memory left on the heap to perform an allocation. Might be triggered when new objects are being created. GC_EXPLICIT means that the garbage collector has been explicitly asked to collect, instead of being triggered by high water marks in the heap. Happens all over the place, but most likely when a thread is being killed or when a binder communication is taken down. There are a few others as well: GC_CONCURRENT Triggered when the heap has reached a certain amount of objects to collect. GC_EXTERNAL_ALLOC means that the the VM is trying to reduce the amount of memory used for collectable objects, to make room for more non-collectable. typedefenum{
|
GC_EXTERNAL_ALLOC freed 297K, 49% free 3411K/6663K, external 24870K/26260K, paused 83ms
这里边的每个数字都是什么意思阿？
free 3411K/6663K和external 24870K/26260K,分别都是表示什么的阿？
释放了297K，现在Free的内存是49%，已用的内存是3411,总得内存是6663
自问自答：
前面Free的内存是VM中java使用的内存，external是指VM中通过JNI中Native的类中的malloc分配出的内存，例如Bitmap和一些Cursor都是这么分配的。
在Davilk中，给一个程序分配的内存根据机型厂商的不同，而不同，现在的大部分的是32M了，而在VM内部会把这些内存分成java使用的内存和 Native使用的内存，它们之间是不能共享的，就是说当你的Native内存用完了，现在Java又有空闲的内存，这时Native会重新像VM申请，而不是直接使用java的。
例如上边的例子
free 3411K/6663K和external 24870K/26260K
如果这时需要创建一个2M的Bitmap，Native现有内存26260-24870=1390K<2048k,因此他就会向Vm申请内存，虽然java空闲的内存是
6663-3411=3252>2048,但这部分内存Native是不能使用。
但是你现在去申请2M的Native内存，VM会告诉你无法分配的，因为现在已使用的内存已经接近峰值了32M(26260+6663=32923 )，所以现在就会成force close 报OOM。
所以现在我们要检查我们的native内存的使用情况来避免OOM。
android的应用是基于JAVA的，
并且每个应用的JVM是独立，这样独立开可以避免应用崩溃影响整个系统
JVM的内存管理是基于预分配的（叫“堆”），重分配堆内存效率很低，所以就有了初始堆内存大小和最大堆内存大小相关的参数
在android上这些参数是厂家设置的，并且出于安全的考虑需要root才能修改
更多细节可以搜索 “JVM内存管理”
通过ActivityManager.getMemoryClass()可以获取到android分给每一个进程的最大可以用的内存，这些内存是native heap + java heap，现在想知道，native heap最大可以使用的内存大小，怎么获取?
试：Debug.getNativeHeapSize()
我们知道，android程序内存一般限制在16M，当然也有24M的，而android程序内存被分为2部分：native和dalvik，dalvik就是我们平常说的java堆，我们创建的对象是在这里面分配的，而bitmap是直接在native上分配的，对于内存的限制是 native+dalvik 不能超过最大限制。
1.单个app 内存限制大小
- ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
- activityManager.getMemoryClass();
2."/proc/meminfo" 系统内存信息文件【整个系统的内存情况】
3.ActivityManager.MemoryInfo【整个系统】
availMem 剩余内存
threshold 临界值 【超过次值就开始杀死后台服务和没有关联的进程】
lowMemory 低内存状态
4.android.os.Debug
getNativeHeapFreeSize()
getNativeHeapAllocatedSize()
getNativeHeapSize()
5.android.os.Debug.MemoryInfo【当前进程的内存情况】
6.Runtime
getExternalBytesAllocated() 应该是外部分配的内存Native内存
8.GC_EXTERNAL_ALLOC freed 与 GC_EXPLICIT freed 是什么?
系统GC释放的内存提示
09-28 17:16:40.513: DEBUG/dalvikvm(3267): GC_EXPLICIT freed 4501 objects / 251624 bytes in 67ms
EXPLICIT：Free的内存是VM中java使用的内存 即 heap mem
在Davilk中，给一个程序分配的内存根据机型厂商的不同，而不同，现在的大部分的是32M了，而在VM内部会把这些内存分成java使用的内存和 Native使用的内存，它们之间是不能共享的，就是说当你的Native内存用完了，现在Java又有空闲的内存，这时Native会重新像VM申请，而不是直接使用java的。
例如上边的例子
explicit 3411K/6663K
external 24870K/26260K
如果这时需要创建一个2M的
所以现在我们要检查我们的native内存的使用情况来避免OOM。
ps: http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android#2299813三、通过Android系统提供的Runtime类，执行adb 命令(top,procrank,ps...等命令)查询
内存耗用：VSS/RSS/PSS/USS
Terms
• VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
• RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
• PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
• USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
Android4.0 输出分辨率改为1280*720后,出现Out of Memory
| [日期：2013-04-09] | 来源：Linux社区 作者：heqiangflytosky | [字体：大 中 小] |
4、另外还有一种情况是：明明还有很多内存，但是发生OOM了。
这种情况经常出现在生成Bitmap的时候。有兴趣的可以试一下，在一个函数里生成一个13m 的int数组。
再该函数结束后，按理说这个int数组应该已经被释放了，或者说可以释放，这个13M的空间应该可以空出来，
这个时候如果你继续生成一个10M的int数组是没有问题的，反而生成一个4M的Bitmap就会跳出OOM。这个就奇怪了，为什么10M的int够空间，反而4M的Bitmap不够呢？
这个问题困扰很久，在网上，国外各大论坛搜索了很久，一般关于OOM的解释和解决方法都是，如何让GC尽快回收的代码风格之类，并没有实际的支出上述情况的根源。
直到昨天在一个老外的blog上终于看到了这方面的解释，我理解后归纳如下：
在Android中：
1)、一个进程的内存可以由2个部分组成：java 使用内存 ，C 使用内存 ，这两个内存的和必须小于16M，不然就会出现大家熟悉的OOM，这个就是第一种OOM的情况。
2)、更加奇怪的是这个：一旦内存分配给Java后，以后这块内存即使释放后，也只能给Java的使用，这个估计跟java虚拟机里把内存分成好几块进行缓存的原因有关，反正C就别想用到这块的内存了，所以如果Java突然占用了一个大块内存，即使很快释放了：
C能使用的内存 = 16M - Java某一瞬间占用的最大内存。
而Bitmap的生成是通过malloc进行内存分配的，占用的是C的内存，这个也就说明了，上述的4MBitmap无法生成的原因，因为在13M被Java用过后，剩下C能用的只有3M了。
5、在Android平台下实现OpenGL ES程序的贴图加载操作一般是通过BitmapFactory.decodeResource这个api，然后用系统封装好的 GLUtils.texImage2D函数直接转换为gl贴图即可，方便快捷。但在较新版的Android系统中res中的图片文件夹根据dpi设备分辨率的不同，细分了很多文件夹处理以支持不同设备的分辨率加载对应的图片，如drawable-hdpi，drawable-ldpi，drawable- mdpi等，如果没有注意这个问题而将贴图图片随意安置的话，在decode的时候系统会默认根据设备dpi的不同对目标图片格式解码的同时进行大小调整，也就是说有可能破坏原本已经是2^n大小的贴图图片，导致原本在模拟器上正确的绘图在真机上变成大白板!解决这个问题的方法可以将图片放到不受dpi影响的drawable-nodpi中，或者设置BitmapFactory的选项，不处理dpi相关问题。
6、查询内存限制大小：
ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
activityManager.getMemoryClass();
以上方法会返回以 M 为单位的数字，可能在不同的平台或者设备上值都不太一样，比如：HTC G7 默认 24M，Galaxy 36M，emulator-2.3 24M，等等。