作为比mobile系统更简捷的操作系统，Android提供了更好的机制来增强程序的安全性，Android具有严格的类型安全检查功能，它几乎能找出程序中所有的语法问题，这点大大的帮助了开发人员，下面就谈一谈学习Android感想。

有了framework后，我们不用面对赤裸裸的OS API，做一些重复而繁杂的事情。但天下没有免费的午餐，在Android中，下层是Linux的核，但上层的java做的framework把这一切封装的密不透风。

以消息处理为例，在MFC中，我们可以用PreTranslateMessage等东东自由处理消息。在C#中，Anders Hejlsberg老大说了，他为我们通向底层开了一扇“救生窗”，但很遗憾，在学习Android中，这扇窗户也被关闭了（至少我现在没发现...）。

在学习Android时，你想处理一些消息（比如：Keydown之类的...），你必须寻找Activity为你提供的一些重载函数（比如 onKeyDown之类的...）或者是各式各样的listener（比如OnKeyDownListner之类的...）。这样做的好处是显而易见的，越多的自由就会有越多的危险和越多的晦涩，条条框框画好了，用起来省心看起来省脑，这是一个设计良好的framework应该提供的享受。

对于我目前的工程而言，我没有什么BT的需求在当前API下做不到的，google的设计ms还是很nice的。但世界是残酷的，有的时候我们还是必须有机制提供消息的分发和处理的。

因为有的工作是不能通过直接调用来同步处理的，同时也不能通过Activity中内嵌的消息分发和接口设定来做到，比如说事件的定时触法，异步的循环事件的处理，高耗时的工作等等。

在Android中，它提供了一些蛮有意思的方式来做这件事情（不好意思，我见不多识不广，我没见过类似玩法，有见过的提个醒 && 嘴下超生^_^）。它有一个android.os.Handler的类，这个类接受一个Looper参数，顾名思义，这是一个封装过的，表征消息循环的类。

默认情况下，Handler接受的是当前线程下的消息循环实例，也就是说一个消息循环可以被当前线程中的多个对象来分发，来处理（在UI线程中，系统已经有一个Activity来处理了，你可以再起若干个Handler来处理...）在实例化一个 handlerInstance之后，你可以通过sendMessage等消息发送机制来发送消息，通过重载handleMessage等函数来分发消息。

但是！该handlerInstance能够接受到的消息，只有通过handlerInstance.obtainMessage构造出来的消息（这种说法是不确切的。你也可以手动new一个Message，然后配置成该handlerInstance可以处理的，我没有跟进去分析其识别机制，有兴趣的自己玩吧^_^）。

也就是说A, B, C, D都可以来处理同一线程内的消息分发，但各自都只能处理属于自己的那一份消息，这抹杀了B想偷偷进入A领地，越俎代庖做一些非份之事的可能（从理论上看。

B还是有可能把消息伪装的和A他们家的一样，我没有尝试挑战一下google的智商，有BT需求的自行研究^_^）。这样做，不但兼顾了灵活性，也确保了安全性，用起来也会简单，我的地盘我做主，不用当心伤及无辜，左拥右抱是一件很开心的事情。

很显然，消息发送者不局限于自己线程，否者只能做一些定时，延时之类的事情，岂不十分无趣。在实例化Handler的时候，Looper可以是任意线程的，只要有Handler的指针，任何线程也都可以sendMessage（这种构造方式也很有意思。

你可以在A线程里面传B线程的Looper来构造 Handler，也可以在B线程里构造，这给内存管理的方法带来很大的变数...）。但有条规则肯定是不能破坏的，就是非UI线程，是不能触碰UI类的。

在不同平台上有很多解决方式（如果你有多的不能再多的兴趣，可以看一下很久很久以前我写的一个，不SB不要钱）。我特意好好跟了一下android中的AsyncQueryHandler类，来了解google官方的解决方案。

【编辑推荐】

1. Android应用程序组建原理深入剖析
2. Android SMS短信服务相关概念简述
3. PythonAndroid数据库相关代码解读
4. PythonAndroid安装卸载程序具体操作方法解析
5. Android应用程序的四个关键点