android程序内存一般限制在16M，当然也有24M的，而android程序内存被分为2部分：native和dalvik，dalvik就是我们平常说的java堆，我们创建的对象是在这里面分配的，而bitmap是直接在native上分配的，对于内存的限制是 native+dalvik 不能超过最大限制。

1.单个app 内存限制大小

int memClass = ((ActivityManager) getSystemService(Context.ACTIVITY_SERVICE)).getMemoryClass();

米2 测试 是 96

N5 是 192

2."/proc/meminfo"  系统内存信息文件【整个系统的内存情况】

Android获取手机总内存和可用内存

“/proc/meminfo”解析

3.ActivityManager.MemoryInfo【整个系统】

availMem         剩余内存

threshold         临界值 【超过次值就开始杀死后台服务和没有关联的进程】

lowMemory     低内存状态

4.android.os.Debug

getNativeHeapFreeSize()

getNativeHeapAllocatedSize()

getNativeHeapSize()

5.android.os.Debug.MemoryInfo【当前进程的内存情况】

6.Runtime

 totalMemory()
 freeMemory()
 maxMemory()

7.VMRuntime

getTargetHeapUtilization()

getMinimumHeapSize()

getExternalBytesAllocated()   应该是外部分配的内存Native内存

8.GC_EXTERNAL_ALLOC freed 与 GC_EXPLICIT freed 是什么?
系统GC释放的内存提示

一般在LOG里面显示如下：
09-28 17:16:37.543: DEBUG/dalvikvm(21466): GC_EXTERNAL_ALLOC freed 390 objects / 45656 bytes in 50ms
09-28 17:16:40.513: DEBUG/dalvikvm(3267): GC_EXPLICIT freed 4501 objects / 251624 bytes in 67ms
EXPLICIT：Free的内存是VM中java使用的内存 即 heap mem
EXTERNA：Free的内存是VM中通过JNI的Native类中的malloc分配的内存 例如 Bitmap 和一些 Cursor
在Davilk中，给一个程序分配的内存根据机型厂商的不同，而不同，现在的大部分的是32M了，而在VM内部会把这些内存分成java使用的内存和 Native使用的内存，它们之间是不能共享的，就是说当你的Native内存用完了，现在Java又有空闲的内存，这时Native会重新像VM申请，而不是直接使用java的。

例如上边的例子
explicit 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系统提供的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

内存分配原则：刚开始系统会给你程序分配上限是已经使用的内存的一倍左右，当不够用时慢慢调整上限，当超过一定的使用量时，会大幅度调整上限，我在测试时， 在64以下调整很小，当使用量超过64M时，系统把内存上限调直接整到了100M以上。前提是在设置 Honeycomb adds “largeHeap” 选项后

3．0 以前GC操作需要很长时间，以常大于100ms，在执行GC时，程序就会出现卡的现象，3.0以后GC执行的时间通常在5ms以内，在以3.0以前的版本 中，加载图片时，系统把bitmaps加载到Native中，并不受GCt管理，需要手机释放，不然会遇到莫名奇妙的内存问题。3.0以后Bitmaps 直接放到内存中在执行GC时，会及时清理无用的Bitmaps所占的内存，在初始化图片时把图片放到内存中，当加载完后，系统会把图片从内存转移到显存 中，当你用内存测试工具时，会发现，在加载图片时，内存占用率很高，当加载完成后，内存使用量突然下来，当加载大量图片时会发现这种情况。

参考资料：

http://blog.csdn.net/xpwang168/article/details/6982453

关于内存的一些方法