标签：
借鉴：大苞米的博客（http://blog.csdn.net/a396901990）
一.内存溢出（OOM--out of memory）
（1）内存溢出引发的问题展现：
1.程序卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC）
2.莫名消失（当你的程序所占内存越大，它在后台的时候就越可能被干掉。反之内存占用越小，在后台存在的时间就越长）
3.直接崩溃（OutOfMemoryError）
（2）内存溢出的原因
因为app的每个进程或者每个虚拟机有个最大内存限制，如果申请的内存资源超过这个限制，系统就会抛出OOM错误。OOM跟整个设备的剩余内存没太大关系，跟系统运行内存有一定关系。比如比较早的android系统的一个虚拟机最多16M内存，当一个app启动后，虚拟机不停的申请内存资源来装载图片，当超过内存上限时就出现OOM。
android的内存组成：
APP内存由 dalvik内存 和 native内存 2部分组成，dalvik也就是java堆，创建的对象就是就是在这里分配的，而native是通过c/c++方式申请的内存，Bitmap就是以这种方式分配的。（android3.0以后，系统都默认通过dalvik分配的，native作为堆来管理）。这2部分加起来不能超过android对单个进程，虚拟机的内存限制。
（3）android系统为什么要设定app的内存限定
1.迫使开发者更合理的分配内存。限制每个应用的可用内存上限，可以放置某些应用程序恶意或者无意的使用过多的内存。而导致其它应用无法正常运行。Android是有多进程的，如果一个进程（就是一个应用）耗费过多的内存，其他应用就无法运行了。因为有了限制，使得开发者必须好好利用有限资源，优化资源的使用。
2.屏幕显示内容有限。即使有万千图片千万数据需要使用到，但在特定时刻需要展示给用户看的总是有限的，因为屏幕显示就那么大，上面可以放的信息就是很有限的。大部分信息都是处于准备显示状态，所以没必要给予太多heap内存。也就是说出现 OOM现象，绝大部分原因是我们的程序设计上有问题，需要优化 。优化方法很多，比如通过时间换空间，不停的加载要用的的图片，不停的回收不用的图片，把大图片解析成适合手机屏幕大小的图片等。
3.davlik虚拟机的设计。android上的app使用独立虚拟机运行，每开一个应用就会打开至少一个独立的虚拟机。这样可以避免虚拟机崩溃导致整个系统崩溃，同时代价就是需要浪费更多的内存。这样设计保证了android的稳定性。
二.GC自动回收内存
Android的gc会按照特定的算法回收程序不用的内存资源，避免app的内存申请约积越多，但是gc一般回收的资源是那些无主的对象内存或者软引用的资源，或者更软引用的引用资源。
（1）优点：
1.减轻编程负担，提高效率
c、c++中的内存回收都是程序员手动操作，否则其中的资源将消耗，造成资源的浪费甚至崩溃。但手工回收内存往往是一项复杂而艰巨的工作。而java语言采用一种动态存储管理技术，它自动地释放不再被程序引用的对象，按照特定的垃圾收集算法来实现资源自动回收的功能。当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用。
2.消除堆内存控件碎片
由于创建对象和垃圾收集器释放丢弃对象所占的内存空间，内存会出现碎片。碎片是分配给对象的内存块之间的空闲内存洞。碎片整理将所占用的堆内存移到堆的一端，JVM将整理出的内存分配给新的对象。
（2）缺点
占用资源，不可预知，不可确定，不可操作。大学老师说了一句很生动形象的话，“只拉不收拾”。这是一个很不好的习惯，在编程过程中，还是应该有一定的编程素养。用了什么，在不需要的时候就及时销毁。
三.查看app内存分配情况
1.通过DDMS中的heap选项卡监视内存情况：
Heap视图中部有一个叫做data object， 即数据对象，也就是我们的程序中大量存在的类类型的对象。
在data object一行中有一列是"Total Size", 其值就是当前进程中所有Java数据对象的内存总量。如果代码中存在没有释放对象引用的情况，则data object的"Total Size"值在每次gc后不会有美线的回落。随着操作次数的增加"Total Size"的值会越来越大。直到到达一个上限 后导致进程被kill掉。
2.在App里面我们可以通过totalMemory与freeMemory
3.adb shell dumpsys meminfo com.android.demo
未完，待续。。。
标签：
原文地址：http://www.cnblogs.com/mbp-study/p/5849280.html
