handler机制
小弟是刚接触android的，在学习android的时候，很快就遇到了Handler这个东东，因为它在android里面实在太频繁了。于是想看看它的机制到底是什么。
二. 最初的理解
我最初的理解它是一个生产者和消费者的模式，一个线程在生产，一个线程在消费。
比如，有如下的代码：
workHandler.sendMessage(msg) ----- 生产者把消息发送到消费者队列里面，也许是个阻塞队列(比如BlockingQueue)
然后在WorkHandler的handleMessage里面有如下的代码：
public final boolean hasMessages (int what) {
switch(what){
case a:
///
case b:.....
}
}
------这里是一个消费者，在消费生产者sendMessage(msg)发过来的消息。
经过一段时间的思考后，我居然发现Handler里面只有一个线程，因为通过自己打印的日志，打印当前线程名称：Thread.currentThread.getName();发现生产者和消费者的线程名称是一样的！
这下自己彻底凌乱了。。
Handler究竟是怎么实现的呢？
二. 后来的思考
再经过一段时间的学习，终于发现Handler有如下几点。
1. 在android里面每个线程只有一个Looper对象，形象点说，每个线程都可以有一个队列，就像一个管子一样，可以用来存放sendMessage发过来的消息。不过，也不是每个线程都一定有Looper，如果没有Looper,那么Looper.myQueue()方法将会抛出空指针异常。
2. 如果单纯使用Handler，就像上面的使用方式一样，那确实只有一个线程在运行。它实现的原理是：当生产者(我们暂且这样称呼)生产一个消息后(sendMessage方法)，直接丢给当前线程的队列，然后当前线程继续从自己的队列里面拿出下一个消息，继续处理。
刚貌似有点感觉在自欺欺人的感觉。因为你不管怎么把消息丢到队列里面去，事情还是要你来做，毕竟只有一个线程在做事情。
但是后来想想，明白了这样设计的必要性。
因为这个唯一的线程一般而言，都是main线程，如果你有个可以分成多个小任务的任务要处理，你没有使用Handler，直接执行，也许系统忙于处理你这个任务，而无法及时响应用户事件，从而导致ANR的抛出(一般Activity 5s之内，Service 10之内没响应，就会ANR).
那如果你把你的任务拆成几个小任务，用Handler来实现，那么系统就可以把你的小任务推到后面来处理，抽出时间来响应用户操作。
当然，如果真的有大任务，一般式需要另外开启服务，或者线程去处理的。也是我们接下来要讲的HandlerThread。
3. 那有些童鞋就要问了，有没有方法重新启动一个线程来充当消费者？答案就是HandlerThread!
我们可以用HandlerThread来启动一个新线程，然后把HandlerThread的Looper对象赋给Handler(这里又是Looper对象，如果你要想理解android的Handler机制，你必须记住：每个线程都最多唯一对应一个Looper)。
代码：
HandlerThread h = new HandlerThread("new thread");
workHandler.setLooper(h.getLooper);
这样，workHandler就运行在新线程里面了。
4. 其实，如果，你的任务非常重要，比如听Mp3，那么开启一个新的线程来播放Mp3也许不是一个好主意。。
我们可以用Service来代替。因为新线程一般依赖原来启动它的那个对象，如果那个对象销毁了，它也将关闭。
但是Service不同，即使启动它的组件，比如Activity被destroy了，它也可以独立存在运行。
不过要说明一点：如果你的Service没有单独开线程，那么它还是运行在main线程里面。如果你要播放Mp3，那么请创建一个Service,然后在Service里面开一个线程来处理！
三. 小结
其实Handler确实是一个非常优美的设计。它区分开了做什么和怎么做的关系。体现了低耦合的思想。线程只需要把任务发出去，根本无需等待。
在worker处理完毕后，直接把结果用sendMessage发回来给发消息的线程处理。
写到这里，真的忍不住为google能设计出这样的模型而鼓掌！
这个就是小弟目前对于Handler的一点理解了。如果以后有更深入的体会，会在后面写出