内存泄露场景
- 单例造成的内存泄漏：
单例模式的生命周期和应用一样长。单例中包含了一个其他对象的引用(比如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()方法。
