android性能之一：内存泄露、内存溢出的区别及原理分析

android内存泄露、内存溢出

android项目开发中，内存泄露是衡量代码质量的很重要的一个维度。本文结合项目开发中实践经验，从以下方面对内存泄露进行分析。
- android（java）内存管理
- 内存泄露和内存溢出的区别
- 内存泄露的原因
- 常见内存泄露问题汇总
- *内存泄露的分析方法和常用工具
- 小结

---

一、android（java）内存管理

要了解内存泄露和内存溢出的问题，首先需要了解java的内存管理机制。

1 JVM—>DVM—>ART

谷歌刚开发的安卓系统用的就是JVM,JVM版权属于sun公司也就是Oracle公司，后来用的是DVM,由于版权问题。DVM是基于openjdk做的2次开发，DVM解决了JVM的效率问题，jvm的运行效率会低。
jvm里面class代码必须要在jvm里面进行解释后在底层操作系统里面执行,真正执行是底层操作系统执行，由于必须在jvm里面解释所以效率要低。dvm会先把class文件转换为dex文件之后再去解释执行，这样转换之后效率就会高。
jvm里面如果有1000个class文件，把他加载进jvm进行解释执行，就要遍历这1000个class文件进行加载操作，那么效率就会低。如果先把这1000个class文件先转换为dex文件，然后加载解释执行这一个dex文件效率就会高。

Dalvik 和标准 Java 虚拟机(JVM)的差别

   Dalvik 基于寄存器，而 JVM 基于栈。基于寄存器的虚拟机对于更大的程序来说，在它们编译的时候，花费的时间更短。 JVM字节码中，局部变量会被放入局部变量表中，继而被压入堆栈供操作码进行运算，当然JVM也可以只使用堆栈而不显式地将局部变量存入变量表中。Dalvik字节码中，局部变量会被赋给65536个可用的寄存器中的任何一个，Dalvik指令直接操作这些寄存器，而不是访问堆栈中的元素。
   VM字节码由.class文件组成，每个文件一个class。JVM在运行的时候为每一个类装载字节码。相反的，Dalvik程序只包含一个.dex文件，这个文件包含了程序中所有的类。Java编译器创建了JVM字节码之后，Dalvik的dx编译器删除.class文件，重新把它们编译成Dalvik字节码，然后把它们写进一个.dex文件中。这个过程包括翻译、重构、解释程序的基本元素（常量池、类定义、数据段）。常量池描述了所有的常量，包括引用、方法名、数值常量等。类定义包括了访问标志、类名等基本信息。数据段中包含各种被VM执行的函数代码以及类和函数的相关信息（例如DVM所需要的寄存器数量、局部变量表、操作数堆栈大小），还有实例变量。

DVM和ART的差别

    ART(Android Runtime)是Android 4.4发布的，用来替换Dalvik虚拟，Android 4.4默认采用的还是DVM，系统会提供一个选项来开启ART。在Android 5.0时，默认采用ART，DVM从此退出历史舞台。
    DVM中的应用每次运行时，字节码都需要通过即时编译器（JIT，just in time）转换为机器码，这会使得应用的运行效率降低。而在ART中，系统在安装应用时会进行一次预编译（AOT，ahead of time）,将字节码预先编译成机器码并存储在本地，这样应用每次运行时就不需要执行编译了，运行效率也大大提升。

2 java运行时数据区

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁，Java虚拟机所管理的内存将会包括以下几个运行时数据区域，如下图所示：

程序计数器　　　　　

　　程序计数器（Program Counter Register）是一块较小的内存空间，它的作用可以看做是当前线程所执行的字节码的行号指示器。

Java虚拟机栈

　　与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。

本地方法栈

　　本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

Java堆

　　对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例。
　　如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

方法区

　　方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

3 android运行时堆内存

ART的运行时堆的空间根据不同的GC类型也有着不同的划分，如果采用的是Mark-Sweep GC，运行时堆主要是由四个Space和多个辅助数据结构组成（两个Mod Union Table，一个Card Table，两个Heap Bitmap，两个Object Map，以及三个Object Stack），四个Space分别是Zygote Space、Allocation Space、Image Space和Large Object Space。Zygote Space、Allocation Space和DVM中的作用是一样的。Image Space用来存放一些预加载类，Large Object Space用来分配一些大对象（默认大小为12k）。其中Zygote Space和Image Space是进程间共享的。（详细可参考http://blog.csdn.net/luoshengyang/article/details/42072975）
采用Mark-Sweep GC的运行时堆空间划分如下图所示。

native进程：采用C/C++实现，不包含dalvik实例的linux进程，/system/bin/目录下面的程序文件运行后都是以native进程形式存在的。
java进程：实例化了 dalvik 虚拟机实例的 linux 进程，进程的入口 main 函数为 java 函数。dalvik 虚拟机实例的宿主进程是fork()调用创建的 linux 进程，所以每一个 android 上的 java 进程实际上就是一个 linux 进程，只是进程中多了一个 dalvik 虚拟机实例。因此，java 进程的内存分配比 native 进程复杂。Android 系统中的应用程序基本都是 java 进程，如桌面、电话、联系人、状态栏等等。

4 android内存管理机制

4.1内存回收

在Android的高级系统版本里面针对Heap空间有一个Generational Heap Memory的模型，最近分配的对象会存放在Young Generation区域，当这个对象在这个区域停留的时间达到一定程度，它会被移动到Old Generation，最后累积一定时间再移动到Permanent Generation区域。系统会根据内存中不同的内存数据类型分别执行不同的gc操作。例如，刚分配到Young Generation区域的对象通常更容易被销毁回收，同时在Young Generation区域的gc操作速度会比Old Generation区域的gc操作速度更快。

4.2共享内存

    Android应用的进程都是从一个叫做Zygote的进程fork出来的。Zygote进程在系统启动并且载入通用的framework的代码与资源之后开始启动。为了启动一个新的程序进程，系统会fork Zygote进程生成一个新的进程，然后在新的进程中加载并运行应用程序的代码。这使得大多数的RAM pages被用来分配给framework的代码，同时使得RAM资源能够在应用的所有进程之间进行共享。
    大多数static的数据被mmapped到一个进程中。这不仅仅使得同样的数据能够在进程间进行共享，而且使得它能够在需要的时候被paged out。常见的static数据包括Dalvik Code，app resources，so文件等。
    大多数情况下，Android通过显式的分配共享内存区域(例如ashmem或者gralloc)来实现动态RAM区域能够在不同进程之间进行共享的机制。例如，Window Surface在App与Screen Compositor之间使用共享的内存，Cursor Buffers在Content Provider与Clients之间共享内存。

4.3分配与回收内存

    每一个进程的Dalvik heap都反映了使用内存的占用范围。这就是通常逻辑意义上提到的Dalvik Heap Size，它可以随着需要进行增长，但是增长行为会有一个系统为它设定的上限。
    逻辑上讲的Heap Size和实际物理意义上使用的内存大小是不对等的，Proportional Set Size(PSS)记录了应用程序自身占用以及和其他进程进行共享的内存。

4.4限制应用的内存

    为了整个Android系统的内存控制需要，Android系统为每一个应用程序都设置了一个硬性的Dalvik Heap Size最大限制阈值，这个阈值在不同的设备上会因为RAM大小不同而各有差异。如果你的应用占用内存空间已经接近这个阈值，此时再尝试分配内存的话，很容易引起OutOfMemoryError的错误。
    ActivityManager.getMemoryClass()可以用来查询当前应用的Heap Size阈值，这个方法会返回一个整数，表明你的应用的Heap Size阈值是多少Mb(megabates)。

4.5应用切换

    Android系统并不会在用户切换应用的时候做交换内存的操作。Android会把那些不包含Foreground组件的应用进程放到LRU Cache中。例如，当用户开始启动了一个应用，系统会为它创建了一个进程，但是当用户离开这个应用，此进程并不会立即被销毁，而是会被放到系统的Cache当中，如果用户后来再切换回到这个应用，此进程就能够被马上完整的恢复，从而实现应用的快速切换。
    如果你的应用中有一个被缓存的进程，这个进程会占用一定的内存空间，它会对系统的整体性能有影响。因此当系统开始进入Low Memory的状态时，它会由系统根据LRU的规则与应用的优先级，内存占用情况以及其他因素的影响综合评估之后决定是否被杀掉。

需要特别注意的：

在Dalvik下，大部分Davik采取的都是标记-清理回收算法，而且具体使用什么算法是在编译期决定的，无法在运行的时候动态更换。标记-清理回收算法无法对Heap中空闲内存区域做碎片整理。系统仅仅会在新的内存分配之前判断Heap的尾端剩余空间是否足够，如果空间不够会触发gc操作，从而腾出更多空闲的内存空间；这样内存空洞就产生了。

内存碎片的产生

如上图所示，第一行，在开始阶段，内存分配较满；第二行，经过GC之后，大部分对象被释放。此时可能产生的问题是，因为没有内存整理功能，整个页面的4KB内存（内存分配的最小单位是页面，通常为4KB）可能只有一个小对象，但是统计PrivateDirty/Pss时还是按照4KB计算。所以对于Dalvik虚拟机的手机来说，我们首先要尽量避免掉频繁生成很多临时小变量（比如说：getView, onDraw等函数中new对象），另一个又要尽量去避免产生很多长生命周期的大对象。

ART在GC上不像Dalvik仅有一种回收算法，ART在不同的情况下会选择不同的回收算法。应用程序在前台运行时，响应性是最重要的，因此也要求执行的GC是高效的。相反，应用程序在后台运行时，响应性不是最重要的，这时候就适合用来解决堆的内存碎片问题。因此，Mark-Sweep GC适合作为Foreground GC，而Mark-Compact GC适合作为Background GC。由于有Compact的能力存在，内存碎片在ART上可以很好的被避免，这个也是ART一个很好的能力。

5、Android GC何时发生？

由上文我们知道，GC操作主要是由系统决定的，但是我们可以监听系统的GC过程，以此来分析我们应用程序当前的内存状态。
Dalvik虚拟机，每一次GC打印内容格式：

D/dalvikvm: , , ,

含义解析

GC Reason：GC触发原因
GC_CONCURRENT：当已分配内存达到某一值时，触发并发GC；
GC_FOR_MALLOC：当尝试在堆上分配内存不足时触发的GC；系统必须停止应用程序并回收内存；
GC_HPROF_DUMP_HEAP： 当需要创建HPROF文件来分析堆内存时触发的GC；
GC_EXPLICIT：当明确的调用GC时，例如调用System.gc()或者通过DDMS工具显式地告诉系统进行GC操作等；
GC_EXTERNAL_ALLOC： 仅在API级别为10或者更低时（新版本分配内存都在Dalvik堆上）
Amount freed GC：回收的内存大小
Heap stats：堆上的空闲内存百分比 （已用内存）/（堆上总内存）
External memory stats： API级别为10或者更低：（已分配的内存量）/ （即将发生垃圾的极限）
Pause time：这次GC操作导致应用程序暂停的时间。关于这个暂停的时间，在2.3之前GC操作是不能并发进行的，也就是系统正在进行GC，那么应用程序就只能阻塞住等待GC结束。而自2.3之后，GC操作改成了并发的方式进行，就是说GC的过程中不会影响到应用程序的正常运行，但是在GC操作的开始和结束的时候会短暂阻塞一段时间。

Art虚拟机，每一次GC打印内容格式：

I/art:,,,,

基本情况和Dalvik没有什么差别，GC的Reason更多了，还多了一个LOS_Space_Status.

LOS_Space_Status：Large Object Space，大对象占用的空间，这部分内存并不是分配在堆上的，但仍属于应用程序内存空间，主要用来管理 Bitmap 等占内存大的对象，避免因分配大内存导致堆频繁 GC。
（参考：https://www.jianshu.com/p/c4b283848970）

二、内存泄露和内存溢出的区别

内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间。对于Android（Java）平台，内存泄漏是指没有用的对象资源仍与GC-Root保持可达路径，导致系统无法进行回收。

所以内存泄露如果不断积累，最终会导致内存溢出，内存溢出大多由内存泄露导致。memory leak会最终会导致out of memory！

三、内存泄露的原因

内存泄露的原因是：持有对象的强引用，且没有及时释放，进而造成内存单元一直被占用，浪费空间，甚至可能造成内存溢出！总结起来大概分为两大类：
1、全局进程(process-global)的static变量。这个无视应用的状态，持有Activity的强引用的怪物。
2、活在Activity生命周期之外的线程。没有清空对Activity的强引用。

四、常见内存泄露问题汇总

例举并分析常见的内存泄漏问题（结合文章http://blog.nimbledroid.com/2016/05/23/memory-leaks.html中的实例）
（1）单例造成的内存泄漏

当调用getInstance时，如果传入的context是Activity的context。

只要这个单例没有被释放，那么这个Activity也不会被释放一直到进程退出才会释放。

解决方案

能使用Application的Context就不要使用Activity的Content，Application的生命周期伴随着整个进程的周期

（2）非静态内部类创建静态实例造成的内存泄漏

错误示例

解决方案

将非静态内部类修改为静态内部类。（静态内部类不会隐式持有外部类）

（3）Handler造成的内存泄漏

错误示例
void createHandler() {
new Handler() {
@Override public void handleMessage(Message message) {
super.handleMessage(message);
}
}.postDelayed(new Runnable() {
@Override public void run() {
while(true);
}
}, Long.MAX_VALUE >> 1);
}

View hButton = findViewById(R.id.h_button);
hButton.setOnClickListener(new View.OnClickListener() {
@Override public void onClick(View v) {
createHandler();
nextActivity();
}
});

mHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity的引用，我们知道消息队列是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有mHandler实例的引用，mHandler又持有Activity的引用，所以导致该Activity的内存资源无法及时回收，引发内存泄漏。

解决方案

创建一个静态Handler内部类，然后对Handler持有的对象使用弱引用，这样在回收时也可以回收Handler持有的对象，这样虽然避免了Activity泄漏，不过Looper线程的消息队列中还是可能会有待处理的消息，所以我们在Activity的Destroy时或者Stop时应该移除消息队列中的消息

（4）线程造成的内存泄漏

错误示例
void spawnThread() {
new Thread() {
@Override public void run() {
while(true);
}
}.start();
}

View tButton = findViewById(R.id.t_button);
tButton.setOnClickListener(new View.OnClickListener() {
@Override public void onClick(View v) {
spawnThread();
nextActivity();
}
});

异步任务和Runnable都是一个匿名内部类，因此它们对当前Activity都有一个隐式引用。如果Activity在销毁之前，任务还未完成， 那么将导致Activity的内存资源无法回收，造成内存泄漏

解决方案

使用 静态内部类，避免了Activity的内存资源泄漏，当然在Activity销毁时候也应该取消相应的任务AsyncTask::cancel()，避免任务在后台执行浪费资源

（5）资源未关闭造成的内存泄漏

对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏

解决方案

在Activity销毁时及时关闭或者注销
其中，关于bitmap的内存优化比较复杂，不是简单的在ondestroy中销毁就可以，可以参考https://juejin.im/post/58c3b29761ff4b005d906730。

（6）使用了静态的Activity和View

解决方案

应该及时将静态的应用 置为null，而且一般不建议将View及Activity设置为静态

（7）注册了系统的服务，但onDestory未注销

错误示例

void registerListener() {
SensorManager sensorManager = (SensorManager) getSystemService(SENSOR_SERVICE);
Sensor sensor = sensorManager.getDefaultSensor(Sensor.TYPE_ALL);
sensorManager.registerListener(this, sensor, SensorManager.SENSOR_DELAY_FASTEST);
}

View smButton = findViewById(R.id.sm_button);
smButton.setOnClickListener(new View.OnClickListener() {
@Override public void onClick(View v) {
registerListener();
nextActivity();
}
});

解决方案

//不需要用的时候记得移除监听
sensorManager.unregisterListener(listener);

（8）不需要用的监听未移除会发生内存泄露

解决方案

Tip：tv.setOnClickListener();//监听执行完回收对象，不用考虑内存泄漏

tv.getViewTreeObserver().addOnWindowFocusChangeListene,add监听，放到集合里面，需要考虑内存泄漏

（9）属性动画导致内存泄漏

属性动画中有一类无线循环的动画，如果在当前 Activity 中播放此类动画，并且没有在结束的时候(onDestory)去停止该动画，那么动画会一直播放下去，尽管在界面上无法看见动画的运转，但是在此时 Activity 的 View 会被动画所持有，而 View 又持有当前 Activity，最终导致 Activity 无法被释放。动画的特征代码如下：

animator.setRepeatCount(ValueAnimator.INFINITE);

解决办法自然很简单，在 OnDestory() 中去取消动画即可。

（10）Dialog 导致的内存泄漏

在当前 Dialog 所依附的 Activity 销毁之前,我们没有去将当前的 Dialgo 销毁(dismiss) 话也是很容易导致内存泄漏的。
（11）集合导致内存泄露
1、静态集合类引起内存泄漏
像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

示例：

Static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}

在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
2、集合中元素属性修改，再调用remove()方法时不起作用，导致泄露。
示例：
public static void main(String[] args)
{
Set set = new HashSet();
Person p1 = new Person(“唐僧”,”pwd1”,25);
Person p2 = new Person(“孙悟空”,”pwd2”,26);
Person p3 = new Person(“猪八戒”,”pwd3”,27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println(“总共有:”+set.size()+” 个元素!”); //结果：总共有:3 个元素!
p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变

set.remove(p3); //此时remove不掉，造成内存泄漏

set.add(p3); //重新添加，居然添加成功
System.out.println(“总共有:”+set.size()+” 个元素!”); //结果：总共有:4 个元素!
for (Person person : set)
{
System.out.println(person);
}
}
更多示例参考https://juejin.im/entry/58805842b123db0061cdb82b