Android内存泄漏和内存溢出（oom）的区别及解决方案

本文主要是整理！

内存泄漏（memory leak）

什么是内存泄漏

内存泄漏是指你申请了一块内存，但没有及时释放，而这块内存会一直占用无法在进行分配，
这样就会出现内存泄漏。

java的GC内存回收机制

某对象不再有任何的引用的时候才会进行回收。

内存分配的策略

• 静态的

静态的存储区：内存在程序编译的时候就已经分配好，这块的内存在程序整个运行期间都一直存在。
它主要存放静态数据、全局的static数据和一些常量。

• 栈式的

在执行函数(方法)时，函数一些内部变量的存储都可以放在栈上面创建，
函数执行结束的时候这些存储单元就会自动被释放掉。
注：
    栈内存包括分配的运算速度很快，因为内置在处理器的里面的。当然容量有限。

• 堆式的

也可以成为动态内存分配。常用的方式就是new来申请一块内存。
java里面是直接依赖的java的gc回收机制。

• 栈式的 和 堆式的的区别

1.堆是不连续的内存区域，堆空间比较灵活也特别大。
2.栈是一块连续的内存区域，大小是有操作系统觉决定的。
3.堆管理很麻烦，频繁地new/remove会造成大量的内存碎片，这样就会慢慢导致效率低下。
4.对于栈的话，它先进后出，进出完全不会产生碎片，运行效率高且稳定。

看下面代码示例：

public class OOMMain {
    // 堆
    int a=0;
    Book book1=new Book();

    private void main(){
    //栈
        int b=9;
        Book2 book2=new Book2();
    }
}

A.成员变量全部存储在堆中(包括基本数据类型，引用及引用的对象实体)—因为他们属于类，类对象,最终还是要被new出来的。
B.局部变量的基本数据类型和引用存储于栈当中，引用的对象实体存储在堆中。-----因为他们属于方法当中的变量，生命周期会随着方法一起结束。

从以上内容我们可以知道：内存泄露，主要讨论堆内存，它存放的就是引用指向的对象实体。

---

内存泄漏4种状态

• 常发性内存泄漏。

  发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。

• 偶发性内存泄漏。

  发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。

• 一次性内存泄漏。

  发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。

• 隐式内存泄漏。

  程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。

---

危害

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

---

产生的常见原因

• 资源未关闭造成的内存泄漏

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

• 记得注销监听器

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

• 单例造成的内存泄漏

单例的静态特性使得单例的生命周期和应用的生命周期一样长，这就说明了如果一个对象已经不需要使用了，而单例对象还持有该对象的引用，那么这个对象将不能被正常回收，这就导致了内存泄漏。

看一个经典案例：

//单例需要传入一个Context，所以这个Context的生命周期的长短至关重要：
public class AppManager {
    private static AppManager instance;
    private Context context;
     private AppManager(Context context) {
     
        this.context = context.getApplicationContext();
//1.这里传入一个Application的Context：这将没有任何问题，因为单例的生命周期和Application的一样长

	//this.context = context;
//2、传入的是Activity的Context：当这个Context所对应的Activity退出时，由于该Context和Activity的生命周期一样长（Activity间接继承于Context），所以当前Activity退出时它的内存并不会被回收，因为单例对象持有该Activity的引用。
        
    }

    public static AppManager getInstance(Context context) {
        if (instance != null) {
            instance = new AppManager(context);
        }
        return instance;
    }
}

• 线程造成的内存泄漏

//-------------------第一种
        new AsyncTask() {
            @Override
            protected Void doInBackground(Void... params) {
                SystemClock.sleep(100000);
                return null;
            }
        }.execute();
//-------------------第二种
        new Thread(new Runnable() {
            @Override
            public void run() {
                SystemClock.sleep(100000);
            }
        }).start();

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

正确的写法：使用静态内部类的写法

 static class MyAsyncTask extends AsyncTask {
        private WeakReference weakReference;

        public MyAsyncTask(Context context) {
            weakReference = new WeakReference<>(context);
        }

        @Override
        protected Void doInBackground(Void... params) {
            SystemClock.sleep(10000);
            return null;
        }

        @Override
        protected void onPostExecute(Void aVoid) {
            super.onPostExecute(aVoid);
            MainActivity activity = (MainActivity) weakReference.get();
            if (activity != null) {
                //...
            }
        }
    }
    static class MyRunnable implements Runnable{
        @Override
        public void run() {
            SystemClock.sleep(10000);
        }
    }
//——————
    new Thread(new MyRunnable()).start();
    new MyAsyncTask(this).execute();

这样就避免了Activity的内存资源泄漏，当然在Activity销毁时候也应该取消相应的任务AsyncTask::cancel()，避免任务在后台执行浪费资源。

• Handler造成的内存泄漏
  Handler的使用代码编写不规范即有可能造成内存泄漏，如下示例：

public class MainActivity extends AppCompatActivity {
    private Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            //...
        }
    };
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        loadData();
    }
    private void loadData(){
        //...request
        Message message = Message.obtain();
        mHandler.sendMessage(message);
    }
}

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

正确写法：

public class MainActivity extends AppCompatActivity {
    private MyHandler mHandler = new MyHandler(this);
    private TextView mTextView ;
    private static class MyHandler extends Handler {
        private WeakReference reference;
        public MyHandler(Context context) {
            reference = new WeakReference<>(context);
        }
        @Override
        public void handleMessage(Message msg) {
            MainActivity activity = (MainActivity) reference.get();
            if(activity != null){
                activity.mTextView.setText("");
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mTextView = (TextView)findViewById(R.id.textview);
        loadData();
    }

    private void loadData() {
        //...request
        Message message = Message.obtain();
        mHandler.sendMessage(message);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }
}

使用mHandler.removeCallbacksAndMessages(null);是移除消息队列中所有消息和所有的Runnable。当然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();来移除指定的Runnable和Message。

---

如何避免内存泄漏

• 使用轻量的数据结构

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

1.SparseArray

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

• ArrayMap

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

• 不要使用Enum

• Bitmap的处理

    1.Bitmap压缩（质量压缩/尺寸压缩）
    2. Lru机制处理Bitmap，也可以使用那些有名的图片缓存框架。
  

关于这个Lru大致提一下：Picasso和glide（大部分都是基于LruCache的）。
LruCache近期最少使用算法的缓存机制，LruCache内部拥有一个LinkedHashMap，其key 为索引，value为Bitmap。LinkedHashMap的内部实现保存了添加的顺序，所以，当LruCache里面的缓存比设定的 最大值大时，就会把最先添加的那些缓存清除掉。

linkedHashMap：

---

---

内存溢出（oom）

定义

我们需要一定内存的大小，但是系统无法分配给我们，满足不了我们的需求，所以导致oom

---

产生原因及如何避免

• 图片过大导致 OOM

可以对图片进行：质量压缩或尺寸压缩

• Bitmap 对象不再使用时调用 recycle()释放内存

• 查询数据库没有关闭游标

• 界面切换导致 OOM
  有时候我们会发现这样的问题，横竖屏切换 N 次后 OOM 了。
  这种问题没有固定的解决方法，但是我们可以从以下几个方面下手分析。

  1.看看页面布局当中有没有大的图片，比如背景图之类的。

/**去除 xml 中相关设置，改在程序中设置背景图（放在 onCreate()方法中）：
*/
Drawable drawable = getResources().getDrawable(R.drawable.id);
ImageView imageView = new ImageView(this);
imageView.setBackgroundDrawable(drawable);

在 Activity destory 时注意，drawable.setCallback(null);防止 Activity 得不到及时的释放。

• 内存泄漏造成的内存溢出

• 其他

Android 应用程序中最典型的需要注意释放资源的情况是在 Activity 的生命周期中，在 onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。