内存泄漏的场景，Handler机制

内存泄露场景

单例造成的内存泄漏：
单例模式的生命周期和应用一样长。单例中包含了一个其他对象的引用(比如context)，那么即使这个对象不再使用，依然存在一个单例对象引用它，造成无法回收(如果传入一个Activity Context,Activity退出销毁但仍然被单例所引用)
非静态内部类创建其静态实例造成内存泄漏：
非静态内部类默认会持有外部类的引用，而又使用了该非静态内部类创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。
匿名内部类/异步线程造成内存泄漏：
匿名内部类对当前Activity都有一个隐式引用, 如果Activity在销毁之前，任务还未完成，那么将导致Activity的内存资源无法回收，造成内存泄漏。
正确的做法还是使用静态内部类。在Activity销毁时候也应该取消相应的任务AsyncTask::cancel()，避免任务在后台执行浪费资源。
资源未回收导致内存泄漏：
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏(这个可以根据IDE的警告改进一部分)。
Handler机制造成内存泄漏
非静态匿名内部类，持有一个外部Activity类的引用，如果在Activity退出后，消息队列中还存在未处理完的消息，导致该Activity一直被引用，其内存资源无法被回收，导致了内存泄漏。
正确的做法是使用静态内部类和弱引用的写法写Handler。
可使用新版Android Studio检测内存泄露和性能

Handler机制

Message：
传递的信息，
包含一个名为target的Handler 对象
包含一个名为callback的Runnable 对象
使用obtain 方法可以从消息池中获取Message的实例(推荐使用，而不是用构造方法直接生产)。
MessageQueue:
消息队列（由Message组成）
next()：消息队列的出队方法。
enqueueMessage:入队操作
MessageQueue并没有使用一个集合把所有的消息都保存起来，它只使用了一个mMessages对象表示当前待处理的消息。所谓的入队其实就是将所有的消息按时间来进行排序，这个时间当然就是uptimeMillis参数。具体的操作方法就根据时间的顺序调用msg.next，从而为每一个消息指定它的下一个消息是什么。当然如果你是通过sendMessageAtFrontOfQueue()方法来发送消息的，它也会调用enqueueMessage()来让消息入队，只不过时间为0，这时会把mMessages赋值为新入队的这条消息，然后将这条消息的next指定为刚才的mMessages，这样也就完成了添加消息到队列头部的操作。
Looper:
队列的创建者，同时传递消息（死循环）
prepare():
对于每一个线程只能有一个Looper,sThreadLocal.set(new Looper(quitAllowed)),将当前线程与Looper绑定。
Looper(quitAllowed)：
调用 mQueue = new MessageQueue(quitAllowed)，创建了一个MessageQueue。
loop()：
在一个死循环中，通过队列出栈的形式，不断从MessageQueue 中取出新的Message,如果消息池为空就行native阻塞，不然就取出message,然后执行msg.target.dispatchMessage(msg) 方法，还记的前面Message类的定义吗，这个target属性其实就是一个Handler 对象，因此在这里就会不断去执行Handler 的dispatchMessage 方法。
Handler:
初始化工作，调用Looper.myLooper()赋值给当前mLooper，关联MessageQueue；这里由于代码中调用的是不带任何参数的构造函数，因此会创建一个mCallback=null且非异步执行的Handler

普通Handler使用时流程：

初始化Handler之前需进行Looper.prepare(),而在ActivityThread中的main()方法,调用了Looper.prepareMainLooper()因此我们应用程序的主线程中会始终存在一个Looper对象，从而不需要再手动去调用Looper.prepare()方法了。
handler.sendMessage(message)发送消息中，调用sendMessageAtTime(Message msg, long uptimeMillis)，其中对消息进行入队queue.enqueueMessage(msg, uptimeMillis)。
消息出队是在Looper.loop()方法中，其中进行了一个死循环，然后不断地调用的MessageQueue的next()方法，每当有一个消息出队，就将它传递到msg.target的dispatchMessage()方法中
Handler中dispatchMessage()


public void dispatchMessage(Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

其中的mCallback是为空，所以调用Handler的handleMessage(msg)方法，所以也就是我们常写的处理消息的方法，这样Handler的流程就走完了。

Handler的post()方法：


public final boolean post(Runnable r)
{
   return  sendMessageDelayed(getPostMessage(r), 0);
}

还是用sendMessageDelayed()方法去发送一条消息，并且还使用了getPostMessage()方法将Runnable对象转换成了一条消息。
然后在Handler中dispatchMessage()中，callback的值就不会为空，就会调用handleCallback(msg)方法。


private final void handleCallback(Message message) {
    message.callback.run();
}

也就是这里的run()方法：

handler.post(new Runnable() {
                    @Override
                    public void run() {
                    }
                });

Activity中的runOnUiThread()方法:


public final void runOnUiThread(Runnable action) {
    if (Thread.currentThread() != mUiThread) {
        mHandler.post(action);
    } else {
        action.run();
    }
}

如果当前的线程不等于UI线程(主线程)，就去调用Handler的post()方法，否则就直接调用Runnable对象的run()方法。