Study on Android【三】--Intent消息传递

goandroid

　　【IT168 技术文档】在前面写Android的ContentProvider时候，可以看到那是基于观察者
模式的一个消息传递方法。每一个Cursor、ContentResolver做为一个小的注册中心，相关观察者可以在这个中心注册，更新消息由注册中心
分发给各个观察者。而在MFC或Winform中，都会形成一个消息网，让消息在网中流动，被各节点使用、吃掉或者在出口死掉。
　　相比之下，我个人觉得基于Intent的Android核心消息传递机制是有所不同的。它应该会有一个全局性的注册中心，这个注册中心是隐性
的，整个Android系统中就那么一个。所有的消息接收者，都被隐形的注册到这个中心。包括Activity，Service和
IntentReceiver。其实说隐形注册是不确切的，所有注册都还是我们手动告诉注册中心的，只是与传统的方式不一样，我们通常不是通过代码，而是
通过配置文件来做。在应用的Manifest中，我们会为一些Activity或Service添加上Intent-filter，或在配置文件中添加项。这其实就相当于向系统的注册中心，注册了相关的Intent-filter和receiver(这个事情完全可以通过代码来做，只是这样就失去了修改的灵活性)。
　　当程序有一个消息希望发出去的时候，它需要将消息封装成一个Intent，并发送。这时候，应该是有一个统一的中心(恩，有可能Android
底层实现的时候不是，但简单这样看是没问题的...)接受到这个消息，并对它进行解析、判定消息类型(这个步骤降低了耦合...)，然后检查注册了相匹配
的filter或receiver，并创建或唤醒接收者，将消息分发给它。这样做有很多好处。虽然这种传递有的时候不如点对点的传递快(这有些需要速度的
地方，我们看到Android会通过直接通信来做)，但有时候又因为它只经过一跳(姑且这么叫吧...)，比复杂的流动又要更快。更重要的是，它耦合性
低，在手机平台这种程序组件多变的条件下使用十分适合。并且它可以很容易实现消息的精确或模糊匹配，弹性很大。(我个人曾想在开发一个C++二次平台的时
候引入这样的机制，但在C++中，建立一套完整的数据marshal机制不容易，相比之下，用java来做会简单很多...)
　　恩，废话说了很多，具体讲讲Android中Intent的使用。当你有一个消息需要传递，如果你明确知道你需要哪个Activity或者其他
Class来响应的话，你可以指定这个类来接受该消息，这被称为显性发送。你需要将Intent的class属性设置成目标。这种情况很常见，比如
startActivity的时候，会清楚当前Activity完了应该是哪个Activity，那就明确的发送这个消息。
　　但是，有的时候你并不确定你的消息是需要具体哪个类来执行，而只是知道接收者该符合哪些条件。比如你只需要有一个接收者能显示用户所选的数据，
而不想制定某个具体的方法，这时候你就需要用到隐形发送(传统上，我们可能会考虑用多态，但显然这种方式更为灵活...)。在Android中，你可以为
Intent指定一个action，表示你这个指令需要处理的事情。系统为我们定义了很多Action类型，这些类型使系统与我们通信的语言(比如在
Activity里面加一个Main的filter，该activity就会做成该应用的入口点)，当然你也可以用于你自己的应用之间的通信(同样当然，
也可以自定义...)。强烈建议，在自己程序接收或发出一个系统action的时候，要名副其实。比如你响应一个view动作，做的确实edit的勾当，
你发送一个pick消息，其实你想让别人做edit的事，这样都会造成混乱。当然只有Action有时候是不够的，在Android中我们还可以指定
catalog信息和type/data信息，比如所有的显示数据的Activity，可能都会响应View
action。但很多与我们需要显示的数据类型不一样，可以加一个type信息，明确的指出我们需要显示的数据类型，甚至还可以加上一个catalog信
息，指明只有你只有按的是“中键”并发出这样的消息才响应。
　　从上面可以看出，Android的Intent可以添加上class, action, data/type,
catalog等消息，注册中心会根据这些信息帮你找到符合的接收者。其中class是点对点的指示，一旦指明，其他信息都被忽略。Intent中还可以
添加key/value的数据，发送方和接收方需要保持统一的key信息和value类型信息，这种数据的marshal在java里做，是不费什么力气
的。
　　Android的Intent发送，可以分成单播和广播两种。广播的接收者是所有注册了的符合条件的IntentReceiver。在单播的情
况下，即使有很多符合条件的接收者，也只要有一个出来处理这个消息就好(恩，个人看法，没找到确切条款或抉择的算法，本来想实验一下，没来得及...)，
这样的情况很容易理解，当你需要修改某个数据的时候，你肯定不会希望有十个编辑器轮流让你来处理。当广播不是这样，一个receiver没有办法阻止其他
receiver进行对广播事件的处理。这种情况也很容易理解，比如时钟改变了，闹钟、备忘录等很多程序都需要分别进行处理。在自己的程序的使用中，应该
分清楚区别，合理的使用。
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/85805/showart_1426197.html