1、单例模式引起的内存泄露
由于单例模式的静态特性，使得它的生命周期和我们的应用一样长，如果让单例无限制的持有Activity的强引用就会导致内存泄漏
如错误代码示例：
public class UserInfoBean { private static UserInfoBean userInfoBean; private Context mContext; private UserInfoBean(Context context) { this.mContext = context; } public static UserInfoBean getUserInfoBean(Context context) { if (userInfoBean == null) { synchronized (UserInfoBean.class) { if (userInfoBean == null) { userInfoBean = new UserInfoBean(context); } } } return userInfoBean; } }
正确代码：
将 this.mContext = context改成：this.mContext = context.getApplicationContext();或者代码中用到的Context可以使用自己定义的MyApplication中的MyApplication.getInstance获取；
2、Handler引起的内存泄露
Handler引起的内存泄漏在开发中最为常见的。Handler、Message、MessageQueue都是相互关联在一起的，如果Handler发送的Message尚未被处理，那么该Message以及发送它的Handler对象都会被线程MessageQueue一直持有。
由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的，因此这种实现方式很难保证跟Activity的生命周期一直，所以很容易无法释放内存
如错误代码：
private final Handler mHandler = new Handler() { @Override public void handleMessage(Message msg) { // ... } }; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mHandler.sendMessageDelayed(Message.obtain(), 60000*5); }
在上面的例子中生命了一个延时5分钟执行的Message，当该Activity退出的时候，延时任务（Message）还在主线成的MessageQueue中等待，此时的Message持有Handler的强引用，并且由于Handler是我们的Activity类的非静态内部类，所以Handler会持有该Activity的强引用，此时该Activity退出时无法进行内存回收，造成内存泄漏。
解决办法：将Handler声明为静态内部类，这样它就不会持有外部类的引用了，Handler的的生命周期就与Activity无关了。不过倘若用到Context等外部类的非static对象，还是应该通过使用Application中与应用同生命周期的Context比较合适
正确代码：
private static final class MyHandler extends Handler { private WeakReference<HomeMainActivity> mActivity; public MyHandler(HomeMainActivity mainActivity) { mActivity = new WeakReference<>(mainActivity);
//or
//mActivity=mainActivity.getApplicationContext; } @Override public void handleMessage(Message msg) { super.handleMessage(msg); HomeMainActivity mainActivity = mActivity.get(); if (null != mActivity) { //相关处理 } } }
private final MyHandler mHandler = new MyHandler(this);
mHandler.sendMessageDelayed(Message.obtain(), 60000*5);
虽然我们结束了Activity的内存泄漏问题，但是经过Handler发送的延时消息还在MessageQueue中，Looper也在等待处理消息，所以我们要在Activity销毁的时候处理掉队列中的消息。
@Override protected void onDestroy() { super.onDestroy(); //传入null，就表示移除所有Message和Runnable mHandler.removeCallbacksAndMessages(null); }
3、匿名内部类在异步线程中的使用引起的内存泄漏
Android开发经常会继承实现 Activity 或者 Fragment 或者 View。如果使用了匿名类，而又被异步线程所引用，如果没有任何措施同样会导致内存泄漏的：
public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_inner_bad); Runnable runnable1 = new MyRunnable(); Runnable runnable2 = new Runnable() { @Override public void run() { } }; } private static class MyRunnable implements Runnable{ @Override public void run() { } } }
runnable1 和 runnable2的区别就是，runnable2使用了匿名内部类，我们看看引用时的引用内存
可以看到，runnable1是没有什么特别的。但runnable2多出了一个MainActivity的引用，若是这个引用再传入到一个异步线程，此线程在和Activity生命周期不一致的时候，也就造成了Activity的泄露。
4、集合引发的内存泄漏
我们通常会把一些对象的引用加入到集合容器（比如ArrayList）中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，当集合中的内容过于大的时候，并且是static的时候就造成了内存泄漏，所有最好在onDestory清空；
private List<String> nameList; private List<Fragment> list; @Override public void onDestroy() { super.onDestroy(); if (nameList != null){ nameList.clear(); nameList = null; } if (list != null){ list.clear(); list = null; } }
5、Android WebView Memory Leak WebView内存泄漏（查看作者原文）
WebView解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。
要使用WebView不造成内存泄漏，首先应该做的就是不能在xml中定义webview节点，而是在需要的时候动态生成。即：可以在使用WebView的地方放置一个LinearLayout类似ViewGroup的节点，然后在要使用WebView的时候，动态生成即：
WebView mWebView = new WebView(getApplicationgContext()); LinearLayout mll = findViewById(R.id.xxx); mll.addView(mWebView);
然后一定要在onDestroy()方法中显式的调用
protected void onDestroy() { super.onDestroy(); mWebView.removeAllViews(); mWebView.destroy() }
注意： new WebView(getApplicationgContext()) ;必须传入ApplicationContext如果传入Activity的Context的话，对内存的引用会一直被保持着。有人用这个方法解决了当Activity被消除后依然保持引用的问题。但是你会发现，如果你需要在WebView中打开链接或者你打开的页面带有flash，获得你的WebView想弹出一个dialog，都会导致从ApplicationContext到ActivityContext的强制类型转换错误，从而导致你应用崩溃。这是因为在加载flash的时候，系统会首先把你的WebView作为父控件，然后在该控件上绘制flash，他想找一个Activity的Context来绘制他，但是你传入的是ApplicationContext。后果，你可以晓得了哈。
其他常见的引起内存泄漏原因
- 构造Adapter时，没有使用缓存的 convertView
- Bitmap在不使用的时候没有使用recycle()释放内存
- 非静态内部类的静态实例容易造成内存泄漏：即一个类中如果你不能够控制它其中内部类的生命周期（譬如Activity中的一些特殊Handler等），则尽量使用静态类和弱引用来处理（譬如ViewRoot的实现）。
- 警惕线程未终止造成的内存泄露；譬如在Activity中关联了一个生命周期超过Activity的Thread，在退出Activity时切记结束线程。一个典型的例子就是HandlerThread的run方法是一个死循环，它不会自己结束，线程的生命周期超过了Activity生命周期，我们必须手动在Activity的销毁方法中调用thread.getLooper().quit();才不会泄露。
- 对象的注册与反注册没有成对出现造成的内存泄露；譬如注册广播接收器、注册观察者（典型的譬如数据库的监听）等。
- 创建与关闭没有成对出现造成的泄露；譬如Cursor资源必须手动关闭，WebView必须手动销毁，流等对象必须手动关闭等。
- 不要在执行频率很高的方法或者循环中创建对象（比如onMeasure），可以使用HashTable等创建一组对象容器从容器中取那些对象，而不用每次new与释放。
- 避免代码设计模式的错误造成内存泄露；譬如循环引用，A持有B，B持有C，C持有A，这样的设计谁都得不到释放
参考文章：