消息传递机制简析-AHandler/AMessage/ALooper

前言

作为一只小菜鸟,在阅读到Android MediaPlayer相关的Nuplayer代码的时候，发现函数的调用不再是A call B了，阅读起来比较痛苦。

究其原因，是因为采取了一种消息传递机制来控制流程。对于熟悉多线程的童鞋来说，这个并不复杂，也可以说很简单。但是对于我这种刚刚接触Android、多线程的小菜鸟来说，还是值得研究一下的。

我个人习惯从字面意思入手。Message：消息。Handler：处理。ALooper：循环。这里可以给出一个不恰当的比方。

比如在最近很火的某猫超市的自动送货流水线中，一个装有各种各样东西的包裹是一个AMessage的话。那么一个传送履带就是一个ALooper，它将各式各样的AMessage传递给需要进行下一步操作的快递员AHandler。那么这样子，一个完整的快递送货就运转起来了。

同样，在NuPlayer中，各种信息（int，string、buffer等(通过键值对对应起来,方便使用时查找)）都被设置在new出来的一个AMessage的成员变量中。

然后启动一个ALooper（ALooper::LooperThread是继承于Thread的），并且把AHandler注册其中(某通的快递员不能来某猫的超市提取货物吧)。

这样，当某一线程中的函数需要另一函数（有可能是另一线程中的，也有可能就是本线程中的）做事情的时候，就会经过AMessage所在的ALooper发送给指定的AHandler来处理。这样，一次消息传递就完成了。

当然，也有某个函数处理完了某事，需要向调用它函数发送Message，这个之后会具体分析。这里，还需要明确两点概念：

一个ALooper消息队列中可以有多个AHandler注册其中，但是一个AHandler不能注册在多个ALooper下。（一家快递公司能有很多名快递员，但是这些快递员中的一人是不能在多家快递公司任职的）
ALooper启动后（线程启动），会不断轮询，有AMessage，就抛给指定的AHandler处理。并且在发现自己的消息队列中没有任何消息时，会等待，不会一直跑，从而降低CPU的占用率

这里再给出两张图，加深童鞋们的理解（因为手笨，画不好图，就借用别人的图了）。

消息处理图.png

类图.png

就我个人理解来说，Nuplayer在播放的过程中，大概会有7个线程之多，这么多线程，如果是异步操作，那么还不是那么复杂。但是如果要求同步操作，那对于我这种小菜鸟来说是不好实现的。

这里大概有童鞋要问，什么是同步，什么是异步？

假如晚上我邀请张三吃饭，然后等待张三忙完在和他一起去（等待他处理完其他事情，再处理我的请求），这是同步。

假如晚上我邀请张三吃饭，不管他有没有在忙，我先走了（我请求发出了，然后继续做接下来的事情），这是异步。

好，有了同步和异步的概念，我们就可以想象，如果要通过加锁mutex的方式来处理7个以上干不同活的人的相互请求时，是不是很难控制，很容易死锁，所以在NuPlayer中，引入了AMessage、AHandler、ALooper这三个类，来处理线程中的同步和异步问题。

第一次写技术文章，思路和排版想必都比较混乱，万事开头难，希望能坚持下去，并且文章的质量越来越高^_

参考:
http://blog.csdn.net/harman_zjc/article/details/53397945