Handler与Context的内存泄漏

Handler
当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity）的引用，导致activity无法被正常回收。
解决方案：
在子线程中使用Handler,(要先Looper.prepare()和Looper.loop() )
将Handler声明为静态内部类，静态内部类不持有外部类的引用。由于Handler不再持有外部类对象的引用，导致程序不允许你在Handler中操作Activity中的对象了。所以你需要在Handler中增加一个对Activity的弱引用

（WeakReference）。
    static class MyHandler extends Handler
        {
            WeakReference<Activity> mWeakReference;
            public MyHandler(Activity activity) 
            {
                mWeakReference=new WeakReference<Activity>(activity);
            }
            @Override
            public void handleMessage(Message msg)
            {
                final Activity activity=mWeakReference.get();
                if(activity!=null)
                {
                  //...
                }
            }
        }

2.Context
内存泄漏：
使用context创建单例模式时，单例一直存在导致原context无法被回收，导致内存泄漏。
解决方法：
使用与应用程序生命周期相同的 Applicaton 的Context 替代普通 Context。
2.1 Context的种类
根据Context依托的组件与用途的不同，可以将Context分为如下几种：

Application：Android中的应用程序单例类，在Activity和Service中可以使用getApplication()获得这个单例，通过context.getApplicatonContext()可以获取到应用全局的Context实例。
Activity/Service：这两个都时ContextWrapper的之类，可以在这两个类中使用getBaseContext()获取到他们的实例，不同的Activity和Service实例，获取到的Context是独立的。
BroadcastReceiver：BroadcastReceiver本身不是Context的子类，而是在回调函数onReceiver() 中由Android框架传入一个context的实例。系统传入的context经过功能裁剪，不能调用registerReceiver() 和bindService() 方法。
ContentProvider：与BroadcastReceiver类似，ContentProvider也不是Context的子类，也是在创建时由系统传入Context的实例，所有可以再ContentProvider中使用getContext()获取到Context。如果ContentProvider与调用者在相同的应用进程中，那么getContext()将返回应用全局唯一的Context实例。如果是在其他进程调用ContentProvider，那么ContentProvider将持有自身所在进程的Context实例。

不同Context的功能对比：
Handler与Context的内存泄漏
注意：

其中NO1标记表示对应的组件并非真的不能启动activity，而是建议不要这么做，因为这些组件会在新的Task中创建Activity，而不是在原来的Task中。
NO2标记的组件也表示不推荐这么做，在这些组件中调用inflation将会使用系统的默认主题，而不是应用中配置的主题。
-NO3标记表示在Andorid 4.2及以上的系统中，如果注册的BroadcastReceiver是null时是可以的，可以用来获取sticky广播的当前值。