本文主要是整理！
内存泄漏（memory leak）
定义
内存泄漏是指你申请了一块内存，但没有及时释放，而这块内存会一直占用无法在进行分配，这样就会出现内存泄漏。（我们申请的内存都是申请的是堆中的内存）
内存泄漏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()方法中需要适当的释放资源的情况。