内存泄漏
概念：
指程序在申请内存后，当该内存不需再使用 但 却无法被释放 & 归还给 程序的现象。即 程序申请的一块内存，且没有任何一个指针指向它，那么这块内存就泄露了。
表现：
它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个系统崩溃。
原因：
造成内存泄漏的本质原因是 持有引用者的生命周期 大于 被引用者的生命周期
影响：
内存泄漏一般不会导致程序异常，但它会导致程序的内存占用过大，这将提高内存溢出的几率。所以，内存泄露是内存溢出的一种原因之一，但不是唯一因素。
导致内存泄漏的原因及解决方案：
1、集合类导致的内存泄漏
原因：
集合类 添加元素后，仍引用着 集合元素对象，导致该集合元素对象不可被回收，从而 导致内存泄漏
代码演示：
private void memoryLeakOfCollection() {
// 通过 循环申请Object 对象 & 将申请的对象逐个放入到集合List
List<Object> objectList = new ArrayList<>();
for (int i = 0; i < 10; i++) {
Object o = new Object();
objectList.add(o);
o = null;
}
// 虽释放了集合元素引用的本身：o=null）
// 但集合List 仍然引用该对象，故垃圾回收器GC 依然不可回收该对象
}
解决方案：
集合类 添加集合元素对象 后，在使用后必须从集合中删除
objectList.clear();
objectList=null;
2、静态变量导致的内存泄漏
原因：
静态变量是在类被load的时候分配内存的，并且存在于方法区。当类被卸载的时候，静态变量被销毁。只要静态变量没有被销毁也没有置null，其对象一直被保持引用，也即引用计数不可能是0，因此不会被垃圾回收。
所以 Static 关键字修饰的成员变量的生命周期 = 应用程序的生命周期。
代码演示：
public class YouhuaTestActivity extends AppCompatActivity {
private static Context mContext;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_youhua_test);
// Activity无法正常销毁，因为静态变量mContext引用了它。
mContext = this;
}
}
解决方案：
A、尽量避免 Static 成员变量引用资源耗费过多的实例（如 Context），若需引用 Context，则尽量使用Applicaiton的Context
B、使用 弱引用（WeakReference） 代替 强引用 持有实例
静态变量引起内存泄漏的一个特殊例子--单例模式：
原因：
当单列中传入一个Activity的Context后，该单列就持有Activity的引用，我们知道单例的生命周期和Application的一样长，所以当Activity退出时它的内存并不会被回收。
代码演示：
private AppManager(Context context) {
// 创建单例时，需传入一个Context
// 若传入的是Activity的Context，此时单例 则持有该Activity的引用
// 由于单例一直持有该Activity的引用（直到整个应用生命周期结束），即使该Activity退出，该Activity的内存也不会被回收
// 特别是一些庞大的Activity，此处非常容易导致OOM
this.context = context;
}
解决方案：
论传入什么类型的Context，最终单例使用的都是Application的Context
private AppManager(Context context) {
this.context = context.getApplicationContext();
}
3、非静态内部/匿名类
非静态内部类默认持有外部类的引用；而静态内部类则不会。
3.1、非静态内部类的实例是静态时 引起当内存泄漏
原因：
当非静态内部类当实例是静态时，那么这个实例当生命周期就和程序当生命周期一样长，而非静态内部类持有外部类都引用，导致外部类无法被释放，最终造成内存泄漏。
代码演示：
public class TestActivity extends AppCompatActivity {
// 非静态内部类的实例的引用是静态当
public static InnerClass innerClass = null;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// 保证非静态内部类的实例只有1个
if (innerClass == null)
innerClass = new InnerClass();
}
// 定义非静态内部类
private class InnerClass {
}
}
解决方案：
1、尽量避免非静态内部类所创建的实例 = 静态；将非静态内部类设置为静态内部类（因为静态内部类默认不持有外部累当引用）。
2、将内部类抽取出来封装成一个单例
3.2、多线程：AsyncTask、实现Runnable接口、继承Thread类 引起的内存泄漏
泄漏原因：
当工作线程正在处理任务且外部类需销毁时，由于工作线程实例持有外部类引用，将使得外部类无法被垃圾回收器（GC）回收，从而造成 内存泄露。
代码：
public class TestActivity extends Activity {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// 异步任务和Runnable都是一个匿名内部类，因此它们对当前Activity都有一个隐式引用。
// 如果Activity在销毁之前，任务还未完成，那么将导致Activity的内存资源无法回收，造成内存泄漏
new AsyncTask<Void, Void, Void>() {
@Override
protected Void doInBackground(Void... params) {
SystemClock.sleep(10000);
return null;
}
}.execute();
new Thread(new Runnable() {
@Override
public void run() {
SystemClock.sleep(10000);
}
}).start();
// 通过创建的内部类 实现多线程
new MyThread().start();
}
// 自定义的Thread子类
private class MyThread extends Thread{
@Override
public void run() {
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
优化方案一：使用静态内部类
public class TestActivity extends Activity {
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
new Thread(new MyRunnable()).start();
new MyAsyncTask(this).execute();
}
private static class MyAsyncTask extends AsyncTask<Void, Void, Void> {
private WeakReference<Context> 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) {
//...
}
}
}
private static class MyRunnable implements Runnable{
@Override
public void run() {
SystemClock.sleep(10000);
}
}
}
优化方案二：强制结束线程
当 外部类（此处以Activity为例） 结束生命周期时（此时系统会调用onDestroy（）），强制结束线程（调用stop（）），使得工作线程实例的生命周期与外部类的生命周期 同步
@Override
protected void onDestroy() {
super.onDestroy();
Thread.stop();
// 外部类Activity生命周期结束时，强制结束线程
}
3.3、Handler造成的内存泄漏
原因：
大家平时开发中喜欢在Activity中直接new一个Handler的匿名内部类，在Java中，非静态的内部类或者匿名类会隐式的持有其外部类的引用，而静态的内部类则不会。这样造成匿名内部类持有一个外部类(通常是Activity)的引用(不然怎么更新ui)，但是Handler常常伴随着一个执行耗时操作的异步线程(如下载多张图片)，如果在完成耗时操作之前，Activity退出，异步线程持有handler的引用，handler持有Activity的引用，从而导致内存泄漏。
代码：
public class MainActivity extends AppCompatActivity {
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
// do something
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
loadData();
}
private void loadData(){
//...do request
Message message = Message.obtain();
mHandler.sendMessage(message);
}
}
优化方案：
public class MainActivity extends AppCompatActivity {
/**
* 创建一个静态Handler内部类，然后对Handler持有的对象使用弱引用，这样在回收时也可以回收Handler持有的对象，
* 这样虽然避免了Activity泄漏，不过Looper线程的消息队列中还是可能会有待处理的消息，
* 所以我们在Activity的Destroy时或者Stop时应该移除消息队列中的消息，
*/
private MyHandler mHandler = new MyHandler(this);
private TextView mTextView ;
private static class MyHandler extends Handler {
private WeakReference<Context> 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();
// 移除消息队列中所有消息和所有的Runnable,
mHandler.removeCallbacksAndMessages(null);
// 当然，也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();来移除指定的Runnable和Message。
}
}
4、资源对象未关闭造成当内存泄漏
原因：
对于资源的使用（如 广播BraodcastReceiver、文件流File、数据库游标Cursor、图片资源Bitmap等），
若在Activity销毁时无及时关闭 / 注销这些资源，这些资源将不会被回收，从而造成内存泄漏。
优化方案：
在Activity销毁时 及时关闭 / 注销资源
如下：
4.1、BraodcastReceiver 及时注销：unregisterReceiver()
4.2、文件流File：及时关闭流：InputStream / OutputStream.close()
4.3、数据库游标cursor使用后关闭游标：cursor.close（）
4.4、图片资源Bitmap：Android分配给图片的内存只有8M，若1个Bitmap对象占内存较多，当它不再被使用时，应调用recycle()回收此对象的像素所占用的内存；最后再赋为null
4.5、自定义View时TypedArray使用完后忘记调用recycle()方法释放内存
Bitmap.recycle()；
Bitmap = null;
4.5、属性动画中有一类无限循环的动画，如果在Activity中播放此动画且没有在onDestory中停止动画，即使已经无法在界面上看到动画效果，动画也会一直播放下去，并且这个时候Activity的View会被动画持有，而View有持有了Activity，最终导致Activity无法释放。这种泄漏的解决办法是在onDestory中调用animator.cancal()来停止动画。
5、上下文对象导致的内存泄漏
5.1、使用application的context来替代activity相关的context。
尽量避免activity的context在自己的范围外被使用，这样会导致activity无法释放。不要让生命周期长于Activity的对象持有到Activity的引用
5.2、在Android中，Application Context的生命周期和应用的生命周期一样长，而不是取决于某个Activity的生命周期。
如果想保持一个长期生命的对象，并且这个对象需要一个 Context，就可以使用Application对象。可以通过调用Context.getApplicationContext()方法或者 Activity.getApplication()方法来获得Application对象。
5.3、Drawable的对象的内部Callback持有activity的引用，当Activity finish()之后，静态成员drawable始终持有这个Activity的引用，导致内存释放不了。
5.4、Activity内部如果有一个Context的成员变量，将导致Context引用指向的Activity对象释放不了,见上文：静态变量导致的内存泄漏
6、webview导致当内存泄漏
http://lipeng1667.github.io/2016/08/06/memory-optimisation-for-webview-in-android/
7、其他
未采用软引用等
- 软引用：
如果一个对象只具有软引用，那么如果内存空间足够，垃圾回收器就不会回收它；如果内存 空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。软引用可以和一个引用队 列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。 - 弱引用：
如果一个对象只具有弱引用，那么在垃圾回收器线程扫描的过程中，一旦发现了只具有弱引 用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。弱 引用也可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联 的引用队列中。 - 弱引用与软引用的根本区别在于：
只具有弱引用的对象拥有更短暂的生命周期，可能随时被回收。而只具有软引用的对象只有当内存不够的时候才被回收，在内存足够的时候，通常不被回收。
