内存溢出和内存泄漏

内存泄漏(Leak)比较轻，内存溢出OOM很严重。频繁内存泄漏，会最终导致内存溢出，APP崩溃。

一、内存泄露

• 垃圾回收器无法回收原本应该被回收的对象，这个对象就引发了内存泄露。
• 内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间。
• 内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。
  
• 内存泄露的危害： 
  
  • （1）过多的内存泄露最终会导致内存溢出（OOM）

  • 一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存，迟早会被占光。 

    memory leak会最终会导致out of memory！

  • （2）内存泄露导致可用内存不足，会触发频繁GC，不管是Android2.2以前的单线程GC还是现在的CMS和G1，都有一部分的操作会导致用户线程停止（就是所谓的Stop the world），从而导致UI卡顿。

---

二、内存溢出（OOM）

• Android为每个进程设置Dalvik Heap Size阈值，这个阈值在不同的设备上会因为RAM大小不同而各有差异。如果APP想要分配的内存超过这个阈值，就会发生OOM。

• 内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。 比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。
  

• 内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory。比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
  

• ActivityManager.getMemoryClass()可以查询当前APP的Heap Size阈值，单位是MB。

• 在3.x以前，Bitmap分配在Native heap中，而在4.x之后，Bitmap分配在Dalvik或ART的Java heap中。

• Android 2.x系统，当dalvik allocated + native allocated + 新分配的大小 >= dalvik heap 最大值时候就会发生OOM，也就是说在2.x系统中，考虑native heap对每个进程的内存限制。

• Android 4.x系统，废除了native的计数器，类似bitmap的分配改到dalvik的java heap中申请，只要allocated + 新分配的内存 >= dalvik heap 最大值的时候就会发生OOM（art运行环境的统计规则还是和dalvik保持一致），也就是说在4.x系统中，不考虑native heap对每个进程的内存限制，native heap只会收到本机总内存（包括RAM以及SWAP区或分页文件）的限制。
• 内存溢出OOM，可以被try catch捕获，但是如果没有从根本上解决，后续仍然可能出现OOM.

---

三、如何避免内存泄漏

参考在MDCC 2015中国移动开发者大会上胡凯前辈的讲述，整理总结。

1、使用轻量的数据结构

• 使用ArrayMap/SparseArray来代替HashMap。ArrayMap/SparseArray是专门为移动设备设计的高效的数据结构。

• HashMap实现原理

  • HashMap内部使用一个默认容量为16的数组来存储数据，采用拉链法解决hash冲突（数组+链表），如下图： 
    

  • Entry存储的内容有key、value、hash值、next指针，通过计算hash(key)%len找到Entry在数组中的位置。

  • 缺点：（1）就算没有数据，也需要分配默认16个元素的数组（2）一旦数据量达到Hashmap限定容量的75%，就将按两倍扩容

• SparseArray

  • 支持int类型，避免自动装箱，但是也只支持int类型的key
  • 内部通过两个数组来进行数据存储的，一个存储key，另外一个存储value
  • 因为key是int，在查找时，采用二分查找，效率高，SparseArray存储的元素都是按元素的key值从小到大排列好的。 （Hashmap通过遍历Entry数组来获取对象）
  • 默认初始size为0，每次增加元素，size++
  • 
    

• ArrayMap

  • 跟SparseArray一样，内部两个数组，但是第一个存key的hash值，一个存value，对象按照key的hash值排序，二分查找也是按照hash
  • 查找index时，传入key，计算出hash，通过二分查找hash数组，确定index

2、不要使用Enum

• 这点在Google的Android官方培训课程提到过，具体可以参考胡凯前辈的《 Android性能优化典范（三）》。

3、大胖子Bitmap的处理

• Bitmap压缩
• Lru机制处理Bitmap（下一节博客会详细讲解），也可以使用那些有名的图片缓存框架。

4、不要使用String进行字符串拼接

• 严格的讲，String拼接只能归结到内存抖动中，因为产生的String副本能够被GC，不会造成内存泄露。

• 频繁的字符串拼接，使用StringBuffer或者StringBuilder代替String，可以在一定程度上避免OOM和内存抖动。

5、非静态内部类内存泄露

• 在Activity中创建非静态内部类，非静态内部类会持有Activity的隐式引用，若内部类生命周期长于Activity，会导致Activity实例无法被回收。（屏幕旋转后会重新创建Activity实例，如果内部类持有引用，将会导致旋转前的实例无法被回收）。

• 解决方案：如果一定要使用内部类，就改用static内部类，在内部类中通过WeakReference的方式引用外界资源。

• 正确的代码示例：

static class ImageDownloadTask extends AsyncTask<String, Void, Bitmap> {        private String url;        private WeakReference<PhotoAdapter> photoAdapter;        public ImageDownloadTask(PhotoAdapter photoAdapter) {            this.photoAdapter = new WeakReference<PhotoAdapter>(photoAdapter);        }        @Override        protected Bitmap doInBackground(String... params) {            //在后台开始下载图片            url = params[0];            Bitmap bitmap = photoAdapter.get().loadBitmap(url);            if (bitmap != null) {                //把下载好的图片放入LruCache中                String key = MD5Tools.decodeString(url);                photoAdapter.get().put(key, bitmap);            }            return bitmap;        }        @Override        protected void onPostExecute(Bitmap bitmap) {            super.onPostExecute(bitmap);            //把下载好的图片显示出来            ImageView mImageView = (ImageView) photoAdapter.get().mGridView.get().findViewWithTag(MD5Tools.decodeString(url));            if (mImageView != null && bitmap != null) {                mImageView.setImageBitmap(bitmap);                photoAdapter.get().mDownloadTaskList.remove(this);//把下载好的任务移除            }        }    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

6、匿名内部类内存泄漏

• 跟非静态内部类一样，匿名内部类也会持有外部类的隐式引用，比较常见的情况有，耗时Handler，耗时Thread，都会造成内存泄漏，解决方式也是static+WeakReference，下面给出正确写法。

• Handler的正确写法：

private static class MyHandler extends Handler {    private final WeakReference<Context> context;    private MyHandler(Context context) {        this.context = new WeakReference<Context>(context);    }    @Override    public void handleMessage(Message msg) {        switch (msg.what) {        }    }}private final MyHandler mHandler = new MyHandler(this);private static final Runnable sRunnable = new Runnable() {    @Override    public void run() {    }};@Overrideprotected void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);    setContentView(R.layout.activity_home);    //  发送一个10分钟后执行的一个消息    mHandler.postDelayed(sRunnable, 600000);}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

• Thread的正确写法：

private static class MyThread extends Thread {    @Override    public void run() {        while (true) {            // TODO 耗时任务        }    }}new MyThread().start();
1
2
3
4
5
6
7
8
9
10
11

7、Context持有导致内存泄漏

• Activity Context被传递到其他实例中，这可能导致自身被引用而发生泄漏。
• 解决：对于大部分非必须使用Activity Context的情况（创建Dialog的Context必须是Activity Context），应该使用Application Context。

8、记得注销监听器

• 注册监听器的时候会add Listener，不要忘记在不需要的时候remove掉Listener。

9、资源文件需要选择合适的文件夹进行存放

• hdpi/xhdpi/xxhdpi等等不同dpi的文件夹下的图片在不同的设备上会经过scale的处理。例如我们只在hdpi的目录下放置了一张100100的图片，那么根据换算关系，xxhdpi的手机去引用那张图片就会被拉伸到200200。需要注意到在这种情况下，内存占用是会显著提高的。对于不希望被拉伸的图片，需要放到assets或者nodpi的目录下。

10、谨慎使用static对象

• static对象的生命周期过长，应该谨慎使用

11、谨慎使用单例中不合理的持有

• 单例中的对象生命周期与应用一致，注意不要在单例中进行不必要的外界引用持有。如果一定要引用外部变量，需要在外部变量生命周期结束的时候接触引用（赋为null）。

12、一定要记得关闭无用连接

• 在onDestory中关闭Cursor，I/O，数据库，网络的连接用完记得关闭。

注意：谨慎使用lager heap

• 不同的设备有不容的RAM，他们为应用程序设置了不同大小的Heap的阈值。虽然可以通过largeHeap=true的属性来为应用获得一个更大的heap空间，然后通过getLargeMemoryClass()来获取到这个更大的heap阈值。但是你要注意，largeHeap只是为了一些本来就需要大量内存的APP存在，比如图墙和图片编辑软件。所以，不要随意的使用large heap，否则会影响系统整体的用户体验，会使每次gc时间更长。

---

四、内存泄露检测

• 这里介绍LeakCanary，一款非常好用的内存泄露检测工具，安装在手机上，能够通过Log的方式告诉你是哪块代码发生了内存泄露。

• 使用方法，在Application中install LeakCanary（默认只能检测Activity内容的内存泄露）：

public class MyApplication extends Application {  @Override public void onCreate() {    super.onCreate();    LeakCanary.install(this);  }}
1
2
3
4
5
6
7

• 想要检测更多，首先注册一个RefWatcher：

public class MyApplication extends Application {    private static RefWatcher sRefWatcher;    @Override    public void onCreate() {        super.onCreate();        sRefWatcher = LeakCanary.install(this);    }    public static RefWatcher getRefWatcher() {        return sRefWatcher;    }}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

• 然后对某个可能发生泄露的占用大内存的对象进行监测：

MyApplication.getRefWatcher().watch(sLeaky);
1

• 对Fragment、BroadcastReceiver、Service进行监测：

public class MyFragment extends Fragment {    @Override    public void onDestroy() {        super.onDestroy();        MyApplication.getRefWatcher().watch(this);    }}
1
2
3
4
5
6
7

• 具体就不多说，大家去LeakCanary的Github上看就行了，地址是：https://github.com/square/leakcanary

---

参考文献

• Andorid内存优化之OOM
• Android性能优化典范（一）
• Android性能优化典范（二）
• Android性能优化典范（三）
• Android性能优化之内存篇
• Android官方学习教程

---------------------------------------------------------------------------------------------------------------------------

android内存管理

android应用层是由java开发的，android的davlik虚拟机与jvm也类似，只不过它是基于寄存器的。

在java中，通过new为对象分配内存，所有对象在java堆内分配空间；而内存的释放是由垃圾收集器（GC）来回收的。 Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点(GC roots)开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。 

内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

内存溢出（out of memory）

内存溢出是指当对象的内存占用已经超出分配内存的空间大小，这时未经处理的异常就会抛出。比如常见的内存溢出情况有：bitmap过大；引用没释放；资源对象没关闭 

如图，这是常见的bitma对象的溢出，显示像素过高或图片尺寸远远大于显示空间的尺寸时，通常都要将其缩放，减小占用内存。

内存溢出的原因

1、内存泄露导致

由于我们程序的失误，长期保持某些资源（如Context）的引用，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成内存泄露。

Android 中常见就是Activity被引用在调用finish之后却没有释放，第二次打开activity又重新创建.内存泄露不断的发生,则会导致内存的溢出。

Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程. 
2、占用内存较多的对象

保存了多个耗用内存过大的对象（如Bitmap）或加载单个超大的图片，造成内存超出限制。

内存泄漏（memory leak）

有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。 

比如，在Activity.onDestroy()被调用之后，view树以及相关的bitmap都应该被垃圾回收。如果一个正在运行的后台线程继续持有这个Activity的引用，那么相关的内存将不会被回收。
memory leak会最终会导致out of memory！

 
如图，这是使用MAT工具查找内存泄漏的结果，例子是 handle 延时发送 message 而在关闭 activity 后 context 被销毁所引发的泄漏，这是作为目的性的测试所以问题比较容易找到。在实际开发中内存泄漏不易察觉并难以找到，当泄漏累积到一定程度是会引发 OOM 的。

内存泄漏的原因

比如当你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。 
1.资源对象没关闭

如Cursor，File等资源。他们会在finalize中关闭，但这样效率太低。容易造成内存泄漏 
SQLiteCurost,当数据量大的时候容易泄漏

2.使用Adapter时，没有使用系统缓存的converView 
3.没有即时调用recycle()释放不再使用的bitmap 
4.应该使用application的context来替代activity相关的context

不要让生命周期长于Activity的对象持有到Activity的引用

5.广播注册没取消造成内存泄露 
6.Handler应该申明为静态对象， 并在其内部类中保存一个对外部类的弱引用。