Android多分辨率适配框架（1）— 核心基础
Android多分辨率适配框架（2）— 原理剖析
Android多分辨率适配框架（3）— 使用指南
自定义View系列教程00–推翻自己和过往，重学自定义View
自定义View系列教程01–常用工具介绍
自定义View系列教程02–onMeasure源码详尽分析
自定义View系列教程03–onLayout源码详尽分析
自定义View系列教程04–Draw源码分析及其实践
自定义View系列教程05–示例分析
自定义View系列教程06–详解View的Touch事件处理
自定义View系列教程07–详解ViewGroup分发Touch事件
自定义View系列教程08–滑动冲突的产生及其处理
前言
众所周知，Android的UI是在其主线程中进行刷新的，所以Google建议开发人员切勿在主线程中进行耗时的操作否则很容易导致应用程序无响应(ANR)。鉴于此几乎接近硬性的要求，我们常把耗时的操作(比如网络请求)置于子线程中进行；但是子线程不能直接访问UI。
至此，这个矛盾就凸显出来了：
- 主线程可以刷新UI，但不能执行耗时操作
- 子线程可以执行耗时操作 ，但是不能直接刷新UI
嗯哼，那有没有一个东西可以调和并化解这个矛盾呢？当然是有的，Google采用Handler把主线程和子线程精巧地联系起来——子线程中进行耗时的业务逻辑，然后利用Handler通知主线程刷新UI。除此以外，还有别的方式可以实现类似的操作么？答案是肯定的，我们也可以利用AsyncTask或者IntentService进行异步的操作。这两者又是怎么做到的呢？其实，在AsyncTask和IntentService的内部亦使用了Handler实现其主要功能。抛开这两者不谈，当我们打开Android源码的时候也随处可见Handler的身影。所以，Handler是Android异步操作的核心和精髓，它在众多领域发挥着极其重要甚至是不可替代的作用。
在此，对Handler的工作原理和实现机制进行系统的梳理。
ThreadLocal简介及其使用
对于线程Thread大家都挺熟悉的了，但是对于ThreadLocal可能就要陌生许多了。虽然我们对于它不太了解，但是它早在JDK1.2版本中就已问世并且被广泛的使用，比如Hibernate，EventBus，Handler都运用了ThreadLocal进行线程相关的操作。如果单纯地从ThreadLocal这个名字来看，它带着浓浓的“本地线程”的味道； 然而，喝一口之后才发现根本就不是这个味儿。其实，ThreadLocal并不是用来操作什么本地线程而是用于实现不同线程的数据副本。当使用ThreadLocal维护变量时，它会为每个使用该变量的线程提供独立的变量副本；每一个线程都可以独立地改变自己的副本并且不会影响其它线程所持有的对应的副本。所以，ThreadLocal的实际作用并不与它的名字所暗含的意义相吻合，或许改称为ThreadLocalVariable(线程本地变量)会更合适一些。
接下来，我们通过一个实例来瞅瞅ThreadLocal的使用方式
/**
* 原创作者:
* 谷哥的小弟
*
* 博客地址:
* http://blog.csdn.net/lfdfhl
*/
private void testThreadLocal(){
mThreadLocal.set("东京热");
new HotThread1().start();
new HotThread2().start();
hot3=mThreadLocal.get();
try{
Thread.sleep(1000*4);
Log.i(TAG,"HotThread1获取到的变量值: "+hot1);
Log.i(TAG,"HotThread2获取到的变量值: "+hot2);
Log.i(TAG,"MainThread获取到的变量值: "+hot3);
}catch (Exception e){
}
}
private class HotThread1 extends Thread{
@Override
public void run() {
super.run();
mThreadLocal.set("北京热");
hot1=mThreadLocal.get();
}
}
private class HotThread2 extends Thread{
@Override
public void run() {
super.run();
mThreadLocal.set("南京热");
hot2=mThreadLocal.get();
}
}查看输出结果：
HotThread1获取到的变量值: 北京热
HotThread2获取到的变量值: 南京热
MainThread获取到的变量值: 东京热
在这段代码中使用ThreadLocal保存String类型的数据，并且在主线程和两个子线程中为ThreadLocal设置了不同的值，然后再将这些值分别取出。结合输出日志可以发现：在不同的线程中访问了同一个ThreadLocal对象，但是通过mThreadLocal.get()得到的值却是不一样的；也就是说：它们之间没有发生相互的影响而是保持了彼此的独立。明白了ThreadLocal的这个特性之后，我们再去理解Looper的工作机制就会容易得多了。
Looper、线程、消息队列的关系
Google官方建议开发人员使用Handler实现异步刷新UI，我们在平常的工作中也很好地采纳了这个提议：首先在主线程中建立Handler，然后在子线程中利用handler.sendMessage(message)发送消息至主线程，最终消息在handleMessage(Message msg) {}得到相应的处理。这个套路，大家都再熟悉不过了；现在换个角度，我们试试在子线程中建立Handler
private class LooperThread extends Thread{
@Override
public void run() {
super.run();
Handler handler=new Handler();
//doing something
}
}此处的代码很简单：LooperThread继承自Thread，并且在其run( )方法中新建一个Handler。
嗯哼，再运行一下，喔哦，报错了：
Can’t create handler inside thread that has not called Looper.prepare().
咦，有点出师不利呢，刚开始试就出错了…….没事，生活不就是无尽的挫折和希望嘛，这点小事嘛也不算。既然是在调用Handler的构造方法时报的错那就从该构造方法的源码入手，一探究竟:
public Handler() {
this(null, false);
}
public Handler(Callback callback) {
this(callback, false);
}
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur");
}
}
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException
("Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}请注意第20行代码：
如果mLooper == null那么系统就会抛出刚才的错误：Can’t create handler inside thread that has not called Looper.prepare()。这句话的意思是：如果在线程内创建handler必须调用Looper.prepare()。既然这个提示已经提示了我们该怎么做，那就加上这一行代码：
private class LooperThread extends Thread{
@Override
public void run() {
super.run();
Looper.prepare();
Handler handler=new Handler();
System.out.println("add code : Looper.prepare()");
//doing something
}
}嘿嘿，果然不再报错了，运行一下：
既然Looper.prepare()解决了这个问题，那我们就去瞅瞅在该方法中做了哪些操作：
/**Initialize the current thread as a looper.
* This gives you a chance to create handlers that then reference
* this looper, before actually starting the loop. Be sure to call
* loop() after calling this method, and end it by calling quit().
*/
public static void prepare() {
prepare(true);
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}从这段源码及其注释文档我们可以看出：
在prepare()中利用一个Looper来初始化当前线程或者说初始化一个带有Looper的线程。
请注意第14行代码，它是这段源码的核心，现对其详细分析：sThreadLocal.set(new Looper(quitAllowed));
在该行代码中一共执行了两个操作
(1) 构造Looper
private Looper(boolean quitAllowed) { mQueue = new MessageQueue(quitAllowed); mThread = Thread.currentThread(); }在Looper的构造方法中初始化了一个消息队列MessageQueue和一个线程Thread。从这可看出：一个Looper对应着一个消息队列以及当前线程。
当收到消息Message后系统会将其存入消息队列中等候处理。至于Looper，它在Android的消息机制中担负着消息轮询的职责，它会不间断地查看MessageQueue中是否有新的未处理的消息；若有则立刻处理，若无则进入阻塞。(2) 将此Looper保存到sThreadLocal中。
此处的sThreadLocal是定义在Looper类中的一个ThreadLocal类型变量static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
Looper是framework中的一个类，sThreadLocal是它的一个static final变量。当在某一个Thread中执行Looper.prepare()时系统就会将与该Thread所对应的Looper保存到sThreadLocal中。不同的线程对着不同的Looper，但它们均由系统保存在sThreadLocal中并且互不影响，相互独立；并且可以通过sThreadLocal.get()获取不同线程所对应的Looper.
- 在调用prepare()方法后需要调用loop()方法开始消息的轮询，并且在需要的时候调用quit()方法停止消息的轮询
- 假若再次执行Looper.prepare()系统发现sThreadLocal.get()的值不再为null于是抛出异常：
Only one Looper may be created per thread，一个线程只能创建一个Looper！
小结：
- 一个线程对应一个Looper
- 一个Looper对应一个消息队列
- 一个线程对应一个消息队列
- 线程，Looper，消息队列三者一一对应
所以，在一个子线程中使用Handler的方式应该是这样的:
class LooperThread extends Thread {
public Handler mHandler;
public void run() {
Looper.prepare();
mHandler = new Handler() {
public void handleMessage(Message msg) {
}
};
Looper.loop();
}
}看到这个范例，有的人可能心里就犯嘀咕了：为什么我们平常在MainActivity中使用Handler时并没有调用Looper.prepare()也没有报错呢？
这是因为UI线程是主线程，系统会自动调用Looper.prepareMainLooper()方法创建主线程的Looper和消息队列MessageQueue
Message的发送和处理过程
在讨论完Looper、线程、消息队列这三者的关系之后我们再来瞅瞅Android消息机制中对于Message的发送和处理。
平常最常用的方式:
handler.sendMessage(message)——>发送消息
handleMessage(Message msg){}——>处理消息
先来分析消息的入队。
Handler可以通过post()、postAtTime()、postDelayed()、postAtFrontOfQueue()等方法发送消息，除了postAtFrontOfQueue()之外这几个方法均会执行到sendMessageAtTime(Message msg, long uptimeMillis)方法，源码如下：
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis);
}
public final boolean sendMessageAtFrontOfQueue(Message msg) {
MessageQueue queue = mQueue;
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, 0);
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}在这里可以看到sendMessageAtTime()内部又调用了enqueueMessage()，在该方法内的重要操作：
第一步：
给msg设置了target，请参见代码第25行此处的this就是当前Handler对象本身。在这就指明了该msg的来源——它是由哪个Handler发出的，与此同时也指明了该msg的归宿——它该由哪个Handler处理。不难发现，哪个Handler发出了消息就由哪个Handler负责处理。
第二步：
将消息放入消息队列中，请参见代码第29行在enqueueMessage(msg,uptimeMillis)中将消息Message存放进消息队列中，距离触发时间最短的message排在队列最前面,同理距离触发时间最长的message排在队列的最尾端。若调用sendMessageAtFrontOfQueue()方法发送消息它会直接调用该enqueueMessage(msg,uptimeMillis)让消息入队只不过时间为延迟时间为0，也就是说该消息会被插入到消息队列头部优先得到执行。
直觉告诉我们此处的消息队列mQueue就是该线程所对应的消息队列。可是光有直觉是不够的甚至是不可靠的。我们再回过头瞅瞅Handler的构造方法，从源码中找到确切的依据
public Handler(Callback callback, boolean async) { if (FIND_POTENTIAL_LEAKS) { final Class<? extends Handler> klass = getClass(); if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) && (klass.getModifiers() & Modifier.STATIC) == 0) { Log.w(TAG, "The following Handler class should be static or leaks might occur"); } } mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException ("Can't create handler inside thread that has not called Looper.prepare()"); } mQueue = mLooper.mQueue; mCallback = callback; mAsynchronous = async; }(1) 获取Looper，请参见代码第10行
(2) 利用Looper的消息队列为mQueue赋值，请参见代码第15行
(3) 为mCallback赋值，，请参见代码第16行
(4) 为mAsynchronous赋值，，请参见代码第17行嗯哼，看到了吧，这个mQueue就是从Looper中取出来的。在之前我们也详细地分析了Looper、线程、消息队列这三者的一一对应关系，所以此处的mQueue正是线程所对应的消息队列。
看完了消息的入队，再来分析消息的出队。
请看Looper中的loop()方法源码：
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
final long traceTag = me.mTraceTag;
if (traceTag != 0) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
try {
msg.target.dispatchMessage(msg);
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}
msg.recycleUnchecked();
}
}我们发现关于消息的处理是在一个死循环中就行的，请参见代码第13-55行。也就是说在该段代码中Looper一直在轮询消息队列MessageQueue。假若消息队列中没有未处理的消息(即queue.next()==null)则其进入阻塞block状态，假若消息队列中有待处理消息(即queue.next()!=null)则利用msg.target.dispatchMessage(msg)将该消息派发至对应的Handler。
到了这，可能有的人会有一个疑问：系统怎么知道把消息发送给哪个Handler呢？
嘿嘿，还记不记得enqueueMessage()中系统给msg设置了target从而确定了其目标Handler么？嗯哼，所以只要通过msg.target.dispatchMessage(msg)就可以将消息派发至对应的Handler了。那在dispatchMessage()中又会对消息做哪些操作呢？我们继续跟进源码
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}哇哈，看到这，心情就舒畅多了，基本上回到了我们熟悉的地方；在此处对Message消息进行了处理，我们来瞅瞅主要的步骤
第一步：
处理Message的回调callback，请参见代码第3行
比如调用handler.post(Runnable runnable)时，该runnable就会被系统封装为Message的callback。
关于这点在源码中也有非常直观的体现：private static Message getPostMessage(Runnable r) { Message m = Message.obtain(); m.callback = r; return m; }第二步：
处理Handler的回调callback，请参见代码第6行
比如执行Handler handler=Handler(Callback callback)时就会将callback赋值给mCallback，关于这点已经在介绍Handler构造方法时分析过了，不再赘述。第三步：
调用handleMessage()处理消息Message，请参见代码第10行
handleMessage()的源码如下：public void handleMessage(Message msg) { }嗯哼，它是一个空的方法。所以Handler的子类需要覆写该方法，并在其中处理接收到的消息。
梳理Handler工作机制
至此，关于Handler的异步机制及其实现原理已经分析完了。在此，对其作一个全面的梳理和总结。
Android异步消息机制中主要涉及到:Thread、Handler、MessageQueue、Looper，在整个机制中它们扮演着不同的角色也承担着各自的不同责任。
Thread
负责业务逻辑的实施。
线程中的操作是由各自的业务逻辑所决定的，视具体情况进行。Handler
负责发送消息和处理消息。
通常的做法是在主线程中建立Handler并利用它在子线程中向主线程发送消息，在主线程接收到消息后会对其进行处理MessageQueue
负责保存消息。
Handler发出的消息均会被保存到消息队列MessageQueue中，系统会根据Message距离触发时间的长短决定该消息在队列中位置。在队列中的消息会依次出队得到相应的处理。Looper
负责轮询消息队列。
Looper使用其loop()方法一直轮询消息队列，并在消息出队时将其派发至对应的Handler.
为了更好地理解这几者的相互关系及其作用，请参见如下示图
使用Handler的错误姿势及其潜在风险
关于Handler的具体用法，尤其是那些常规的使用方式在此就不再一一列举了。
我们要讨论和分析的是在开发中不恰当地使用Handler的方式及其带来的潜在风险。
第一个问题：
利用handler.post(Runnable runnable)执行耗时操作
请看如下示例：
/**
* 原创作者:
* 谷哥的小弟
*
* 博客地址:
* http://blog.csdn.net/lfdfhl
*/
public class MainActivity extends AppCompatActivity {
private TextView mTextView;
private Handler mHandler;
private ImageView mImageView;
private Resources mResources;
private static final String TAG="stay4it";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
init();
}
private void init(){
mResources=getResources();
mHandler=new Handler();
mTextView=(TextView) findViewById(R.id.textView);
mImageView =(ImageView) findViewById(R.id.imageView);
mImageView.setOnClickListener(new OnClickListenerImpl());
long threadID=Thread.currentThread().getId();
Log.i(TAG,"主线程的线程ID="+threadID);
}
private class OnClickListenerImpl implements View.OnClickListener {
@Override
public void onClick(View v) {
new TestThread().start();
}
}
private class TestThread extends Thread{
@Override
public void run() {
super.run();
mHandler.post(new Runnable() {
@Override
public void run() {
String text=mResources.getString(R.string.text);
long threadID=Thread.currentThread().getId();
Log.i(TAG,"在post(Runnable r)里的run()获取到线程ID="+threadID);
mTextView.setText(text);
}
});
}
}
}
运行一下，观察效果：
我们在开发中可能会做如上的操作：在主线程中创建Handler，然后在子线程里利用handler.post(Runnable runnable)执行某些操作甚至是耗时的操作。可是这么做合适么？我们来看看主线程的ID和在Runnable的run()方法里获取到的线程ID，输出日志如下：
主线程的线程ID=1
在post(Runnable r)里的run()获取到线程ID=1
在这里我们发现在两处获得的线程ID是同一个值，也就是说Runnable的run()方法并不是在一个新线程中执行的，而是在主线程中执行的。
为什么明明把handler.post(Runnable runnable)放入到子线程中了但是Runnable的run()却在主线程中执行呢？
其实，这个问题在之前的分析中已经提到了：调用handler.post(Runnable runnable)时，该runnable会被系统封装为Message的callback。所以，handler.post(Runnable runnable)和handler.sendMessage(Message message)这两个不同的方法在本质上是相同的——Handler发送了一条消息。在该示例中handler是在主线程中创建的，所以它当然会在主线程中处理消息；如此以来该Runnable亦会在主线程中执行；所以，在Runnable的run()方法中执行耗时的操作是不可取的容易导致应用程序无响应。
那么，调用view.post(Runnable runnable)会在子线程中执行还是主线程中执行呢？
我们来瞅瞅它的实现：
public boolean post(Runnable action) {
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
return attachInfo.mHandler.post(action);
}
getRunQueue().post(action);
return true;
}看到这段源码就无需再做过多的解释了，它依然是在主线程中执行的，原理同上。
那么，调用Activity.runOnUiThread(Runnable runnable)方法会在子线程中执行还是主线程中执行呢？
public final void runOnUiThread(Runnable action) {
if (Thread.currentThread() != mUiThread) {
mHandler.post(action);
} else {
action.run();
}
}嗯哼，这段源码就更简单了。如果当前线程是UI线程，那么该Runnable会立即执行；如果当前线程不是UI线程，则使用handler的post()方法将其放入UI线程的消息队列中。
小结：
handler.post(Runnable runnable)、view.post(Runnable runnable)、Activity.runOnUiThread(Runnable runnable)的runnable均会在主线程中执行，所以切勿在其run()方法中执行耗时的操作
第二个问题：
Handler导致的潜在内存泄露
请看如下示例：
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;
/**
* 原创作者:
* 谷哥的小弟
*
* 博客地址:
* http://blog.csdn.net/lfdfhl
*/
public class MainActivity extends AppCompatActivity {
private Handler mHandler;
private static final String TAG="stay4it";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
init();
}
private void init() {
mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
Log.i(TAG,"handle message");
}
};
Message message=Message.obtain();
message.what=9527;
mHandler.sendMessage(message);
mHandler.postDelayed(new Runnable() {
@Override
public void run() {
}
}, 1000 * 20);
}
}
以上是我们在工作中常见的对于Handler的使用方式，为了更形象地说明问题特意把Runnable所延迟时间设置得比较久。如此操作，猛地一看觉得没啥不妥当的地方；但是简单地分析一下这段代码，却发现它存在潜在的内存泄露风险。
- 内部类new Handler(){}持有外部类MainActivity的引用
- 内部类new Runnable(){}持有外部类MainActivity的引用
- new Runnable(){}会被封装成Message的callback且Message会持有Handler的引用
- handler发送了延迟消息，所以消息队列持该Runnable的引用
- 综合这几者，可理解为消息间接地持有了MainActivity的引用
现在假设这么一种情况：进入该Activity后在20秒以内的任意时间旋转屏幕，此时会导致Activity重新绘制。但是通过postDelayed()发出的Runnable还未被执行，所以消息队仍列持有Runnable的引用，而Runnable也依然持有Activity的引用，故此时Activity所占内存并不能向期望的那样被回收，这样就可能会造成内存的泄漏。
优化该问题的方式有多种，在此展示其中一种比较好的实现方式：
/**
* 原创作者:
* 谷哥的小弟
*
* 博客地址:
* http://blog.csdn.net/lfdfhl
*/
public class MainActivity extends AppCompatActivity {
private Activity mActivity;
private static final String TAG="stay4it";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
init();
}
private void init(){
mActivity=this;
BetterHandler betterHandler = new BetterHandler(mActivity);
Message message=Message.obtain();
message.what=9527;
betterHandler.sendMessage(message);
betterHandler.postDelayed(new BetterRunnable(), 1000 * 20);
}
private static class BetterRunnable implements Runnable {
@Override
public void run() {
Log.i(TAG,"Runnable run()");
}
}
private static class BetterHandler extends Handler {
private WeakReference<Activity> activityWeakReference;
public BetterHandler(Activity activity) {
activityWeakReference = new WeakReference<>(activity);
}
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
if (activityWeakReference.get() != null) {
Log.i(TAG,"handle message");
}
}
}
}
看到这段代码，我们发现了一个陌生的东西WeakReference。什么是WeakReference呢？它有什么特点呢？
从JDK1.2开始，Java把对象的引用分为四种级别，这四种级别由高到低依次为：强引用、软引用、弱引用和虚引用。
强引用
我们一般使用的就是强引用，垃圾回收器一般都不会对其进行回收操作。当内存空间不足时Java虚拟机宁愿抛出OutOfMemoryError错误使程序异常终止，也不会回收具有强引用的对象软引用
如果一个对象具有软引用(SoftReference)，在内存空间足够的时候GC不会回收它，如果内存空间不足了GC就会回收这些对象的内存空间。弱引用
如果一个对象具有弱引用(WeakReference)，那么当GC线程扫描的过程中一旦发现某个对象只具有弱引用而不存在强引用时不管当前内存空间足够与否GC都会回收它的内存。由于垃圾回收器是一个优先级较低的线程，所以不一定会很快发现那些只具有弱引用的对象。为了防止内存溢出，在处理一些占用内存大而且生命周期较长的对象时候，可以尽量使用软引用和弱引用.虚引用
虚引用(PhantomReference)与其他三种引用都不同，它并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。所以，虚引用主要用来跟踪对象被垃圾回收器回收的活动，在一般的开发中并不会使用它
嗯哼，在了解这四种引用之后我们继续分析刚才的代码。在该示例中做了如下主要操作：
将Handler和Runnable定义为Activity的静态内部类
这两者定义为静态内部类后它们就不再持有外部类(Activity)的引用，具体代码请参见示例中BetterHandler和BetterRunnable的实现
在BetterHandler内使用弱引用WeakReference持有Activity
在完成这两步操作之后，我们再来分析刚才的场景：进入该Activity后在20秒以内的任意时间旋转屏幕导致Activity重新绘制。此时，消息持有Handler的引用，但Handler对象不再持有Activity的强引用，所以系统可以回收该Activity从而避免了内存泄露的发生。对于这样的做法，可能有的人觉得不是特别好理解，那我再换一种直白的通俗的描述：如果直接将Activity传入BetterHandler中并且不对其使用WeakReference那么它依然是一个强引用，这和之前未优化的代码相比是没有任何差别的。假若把Activity传进BetterHandler之后并用WeakReference“包裹”了它，使之不再是一个强引用而变成了一个弱引用。当Activity发生重绘时，GC发现对于这个Activity没有强引用而只存在一个弱引用，那么系统就将其回收。
在handleMessage( )对Activity进行非空判断
因为Activity可能已经被GC回收，所以在处理消息时要判断Activity是否为null，即if(activityWeakReference.get() != null)从而避免异常的发生。
后语
我想能看到这的人已经不多了。
大家都知道，Handler在Android体系中占有具有举足轻重的作用，只有掌握了Handler的实现原理和工作机制才可能更全面，更深入地掌握Android开发技能。在本文中我力图详细地阐述Handler相关技术，所以文章的篇幅偏长了。如果你耐着性子看到了此处，请为自己点个赞；你的坚持和努力不会白费，它们会让你变得更好。