2、单个应用可用的最大内存

Android设备出厂以后，java虚拟机对单个应用的最大内存分配就确定下来了，超出这个值就会OOM。这个属性值是定义在/system/build.prop文件中的

dalvik.vm.heapstartsize=8m

它表示堆分配的初始大小，它会影响到整个系统对RAM的使用程度，和第一次使用应用时的流畅程度。

它值越小，系统ram消耗越慢，但一些较大应用一开始不够用，需要调用gc和堆调整策略，导致应用反应较慢。它值越大，这个值越大系统ram消耗越快，但是应用更流畅。

dalvik.vm.heapgrowthlimit=64m // 单个应用可用最大内存

主要对应的是这个值,它表示单个进程内存被限定在64m,即程序运行过程中实际只能使用64m内存，超出就会报OOM。(仅仅针对dalvik堆，不包括native堆)

dalvik.vm.heapsize=384m//heapsize参数表示单个进程可用的最大内存，但如果存在heapgrowthlimit参数，则以heapgrowthlimit为准.

heapsize表示不受控情况下的极限堆，表示单个虚拟机或单个进程可用的最大内存。而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机(这样设计就会在单个程序崩溃的情况下不会导致整个系统的崩溃)。

注意：在设置了heapgrowthlimit的情况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，如果要使用大堆，需要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。

不同设备，这些个值可以不一样。一般地，厂家针对设备的配置情况都会适当的修改/system/build.prop文件来调高这个值。随着设备硬件性能的不断提升，从最早的16M限制(G1手机)到后来的24m,32m，64m等，都遵循Android框架对每个应用的最小内存大小限制，参考http://source.android.com/compatibility/downloads.html 3.7节。

通过代码查看每个进程可用的最大内存，即heapgrowthlimit值：

ActivityManager activityManager = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);

int memClass = activityManager.getMemoryClass();//64，以m为单位

上面的几个参数是与虚拟机的内存分配相关的，虚拟机的内存分配过程是下面这样的：

1  首先判断一下需要申请的size是不是过大，如果申请的size超过了堆的最大限制，则转入步骤6

2  尝试分配，如果成功则返回，失败则转入步骤3

3  判断是否gc正在进行垃圾回收，如果正在进行则等待回收完成之后，尝试分配。如果成功则返回，失败则转入步骤4

4  自己启动gc进行垃圾回收，这里gcForMalloc的参数是false。所以不会回收软引用，回收完成后尝试分配，如果成功则返回，失败则转入步骤5

5  调用dvmHeapSourceAllocAndGrow尝试分配，这个函数会扩张堆。所以heap startup的时候可以给一个比较小的初始堆，实在不够用再调用它进行扩张

6  进入回收软引用阶段，这里gcForMalloc的参数是ture，所以需要回收软引用。然后调用dvmHeapSourceAllocAndGrow尝试分配，如果失败则抛出OOM。

3、为什么会内存泄露(Memory Leak)?

android通过android虚拟机来管理内存，程序员只管申请内存创建对象，创建完不再需要关心怎么释放对象内存，一切由虚拟机帮你搞定，然而虚拟机回收对象是有条件的。这里简单叙述下java内存管理机制，java虚拟机维护着一张当前对象关系的object tree，当GC发生时，虚拟机会从GC Roots 开始去扫描当前的对象树，发现通过任何reference chain(引用链)无法访问某个对象的时候，该对象即被回收。名词GC Roots正是分析这一过程的起点，例如JVM自己确保了对象的可到达性(那么JVM就是GC Roots)，所以GC Roots就是这样在内存中保持对象可到达性的，一旦不可到达，即被回收。通常GC Roots是一个在current thread(当前线程)的call stack(调用栈)上的对象(例如方法参数和局部变量)，或者是线程自身或者是system class loader(系统类加载器)加载的类以及native code(本地代码)保留的活动对象。所以GC Roots是分析对象为何还存活于内存中的利器。知道了什么样的对象GC才会回收后，再来学习下对象引用都包含哪些吧。

Java中包含4种对象引用：

强引用： 通常我们编写的代码都是Strong Ref，eg ：Person person = new Person("sunny");不管系统资源有多紧张，强引用的对象都绝对不会被回收，即使他以后不再用到。

软引用：只要有足够的内存，就一直保持对象。一般可用来实现缓存，通过java.lang.r.efSoftReference类实现。内存非常紧张的时候会被回收，其他时候不会被回收，所以在使用之前需要判空，从而判断当前时候已经被回收了。

弱引用：通过WeakReference类实现，eg : WeakReference p = new WeakReference(new Person("Rain"));不管内存是否足够，系统垃圾回收时必定会回收。

虚引用：不能单独使用，主要是用于追踪对象被垃圾回收的状态。通过PhantomReference类和引用队列ReferenceQueue类联合使用实现。

我们可能还需要了解shallow size、retained size概念，简单来说，Shallow size就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量(不是成员变量的值)的总和。在32位系统上，对象头占用8字节，int占用4字节，不管成员变量(对象或数组)是否引用了其他对象(实例)或者赋值为null它始终占用4字节。故此，对于String对象实例来说，它有三个int成员(34=12字节)、一个char[]成员(14=4字节)以及一个对象头(8字节)，总共34 +14+8=24字节。根据这一原则，对String a=”rosen jiang”来说，实例a的shallow size也是24字节。Retained size是该对象自己的shallow size，加上只能从该对象能直接或间接访问到对象的shallow size之和。换句话说，retained size是该对象被GC之后所能回收到内存的总和。为了更好的理解retained size，我们来看个例子。

图1

假设内存中对象之间的引用关系可以看成图1的方式，从图中可以看到 GC正是reference chain的起点。从obj1入手，上图中蓝色节点代表仅仅只有通过obj1才能直接或间接访问的对象。因为可以通过GC Roots访问，所以左图的obj3不是蓝色节点；而在右图却是蓝色，因为它已经被包含在retained集合内。所以对于左图，obj1的retained size是obj1、obj2、obj4的shallow size总和；右图的retained size是obj1、obj2、obj3、obj4的shallow size总和。

相信了有以上的这些基础概念，我们应该对java内存管理有了一个初步的了解。

为什么会内存泄露呢，根本原因就是一个永远不会被使用的对象，因为一些引用没有断开，没有满足GC条件，导致不会被回收，这就造成了内存泄露。比如在Activity中注册了一个广播接收器，但是在页面关闭的时候进行unRegister，就会出现内存溢出的现象。如果我们的java运行很久,而这种内存泄露不断的发生，最后就没内存可用了，最终就是我们看到的OOM错误。虽然android的内存泄露做到了应用程序级别的泄露(android中的每个应用程序都是独立运行在单独进程中的，每个应用进程都由虚拟机指定了一个内存上限值，一旦内存占用值超过这个上限值，就会发生oom错误，进程被强制kill掉，kill掉的进程内存会被系统回收)，但是对于一名开发工程师，绝对不能放过任何的内存泄露。

4、为什么会发生OOM(Out Of Memory)？

OOM：即OutOfMemoery，顾名思义就是指内存溢出了。之前我们知道Android的应用程序所能申请的最大内存都是有限的，OOM是指APP向系统申请内存的请求超过了应用所能有的最大阀值的内存，系统无法再分配多余的空间，就会造成OOM error。在Android平台下，除了之前所说的持续发生了内存泄漏(Memory Leak)，累积到一定程度导致OOM的情况以外，也有一次性申请很多内存，比如说一次创建大的数组或者是载入大的文件如图片的时候。实际中很多情况就是出现在图片不当处理加载的时候。

5、常见的MemoryLeak分析

后来看到了更多的MemoryLeak相关的知识，有了更多的实践经验，