Android组件

http://android.git.kernel.org/

组件（Component），在谈及所谓架构和重用的时候，是一个重要的事情。很多时候都会说基于组件的软件架构，指的是期望把程序做乐高似的，有一堆接口标准封装完整的组件放在哪里，想用的时候取上几个一搭配，整个程序就构建完成了。
在开篇的时候就在说，Android是一个为组件化而搭建的平台，它引入所谓Mash-Up的概念，这使得你在应用的最上层，想做的不组件化都是很困难的一件事情（底层逻辑，好吧，管不了...）。具体说来，Android有四大组件四喜丸子：Activity、Service、Broadcast Receiver、Content Provider。
Activity
做一个完整的Android程序，不想用到Activity，真的是比较困难的一件事情，除非是想做绿叶想疯了。因为Activity是Android程序与用户交互的窗口，在我看来，从这个层面的视角来看，Android的Activity特像网站的页面。
首先，一个网站，如果一张页面都没有，那...，真是一颗奇葩。而一张页面往往都有个独立的主题和功能点，比如登录页面，注册页面，管理页面，如是。
在每个页面里面，会放一些链接，已实现功能点的串联，有的链接点了，刷，跑到同一站点的另一个页面去了；有的链接点了，啾，可能跳到其他网站的页面去；还有的链接点了，恩...，这次没跑，但当前页面的样子可能有所变化了。这些模式，和Activity给人的感觉很像，只不过实现策略不同罢了，毕竟Android这套架构的核心思想，本身就来自源于Web的Mash-Up概念，视为页面的客户端化，也未尝不可。
Activity，在四大组件中，无疑是最复杂的，这年头，一样东西和界面挂上了勾，都简化不了，想一想，独立做一个应用有多少时间沦落在了界面上，就能琢磨清楚了。从视觉效果来看，一个Activity占据当前的窗口，响应所有窗口事件，具备有控件，菜单等界面元素。从内部逻辑来看，Activity需要为了保持各个界面状态，需要做很多持久化的事情，还需要妥善管理生命周期，和一些转跳逻辑。对于开发者而言，就需要派生一个Activity的子类，然后埋头苦干上述事情。对于Activity的更多细节，先可以参见：reference/android/app/Activity.html。后续，会献上更为详尽的剖析。
Service
服务，从最直白的视角来看，就是剥离了界面的Activity，它们在很多Android的概念方面比较接近，都是封装有一个完整的功能逻辑实现，只不过Service不抛头露脸，只是默默无声的做坚实的后盾。
但其实，换个角度来看，Android中的服务，和我们通常说的Windows服务，Web的后台服务又有一些相近，它们通常都是后台长时间运行，接受上层指令，完成相关事务的模块。用运行模式来看，Activity是跳，从一个跳到一个，呃...，这有点像模态对话框（或者还像web页面好了...），给一个输入（抑或没有...），然后不管不顾的让它运行，离开时返回输出（同抑或没有...）。
而Service不是，它是等，等着上层连接上它，然后产生一段持久而缠绵的通信，这就像一个用了Ajax页面，看着没啥变化，偷偷摸摸的和Service不知眉来眼去多少回了。
但和一般的Service还是有所不同，Android的Service和所有四大组件一样，其进程模型都是可以配置的，调用方和发布方都可以有权利来选择是把这个组件运行在同一个进程下，还是不同的进程下。这句话，可以拿把指甲刀刻进脑海中去，它凸显了Android的运行特征。如果一个Service，是有期望运行在于调用方不同进程的时候，就需要利用Android提供的RPC机制，为其部署一套进程间通信的策略。

Android的RPC实现，如上图所示（好吧，也是从SDK中拿来主义的...），无甚稀奇，基于代理模式的一个实现，在调用端和服务端都去生成一个代理类，做一些序列化和反序列化的事情，使得调用端和服务器端都可以像调用一个本地接口一样使用RPC接口。
Android中用来做数据序列化的类是Parcel，参见：/reference/android/os/Parcel.html，封装了序列化的细节，向外提供了足够对象化的访问接口，Android号称实现非常高效。
还有就是AIDL (Android Interface Definition Language) ，一种接口定义的语言，服务的RPC接口，可以用AIDL来描述，这样，ADT就可以帮助你自动生成一整套的代理模式需要用到的类，都是想起来很乏力写起来很苦力的那种。更多内容，可以再看看：guide/developing/tools/aidl.html，如果有兴致，可以找些其他PRC实现的资料lou几眼。
关于Service的实现，还强推参看API Demos这个Sample里面的RemoteService实现。它完整的展示了实现一个Service需要做的事情：那就是定义好需要接受的Intent，提供同步或异步的接口，在上层绑定了它后，通过这些接口（很多时候都是RPC的...）进行通信。在RPC接口中使用的数据、回调接口对象，如果不是标准的系统实现（系统可序列化的），则需要自定义aidl，所有一切，在这个Sample里都有表达，强荐。
Service从实现角度看，最特别的就是这些RPC的实现了，其他内容，都会接近于Activity的一些实现，也许不再会详述了。
Broadcast Receiver
在实际应用中，我们常需要等，等待系统抑或其他应用发出一道指令，为自己的应用擦亮明灯指明方向。而这种等待，在很多的平台上，都会需要付出不小的代价。
比如，在Symbian中，你要等待一个来电消息，显示归属地之类的，必须让自己的应用忍辱负重偷偷摸摸的开机启动，消隐图标隐藏任务项，潜伏在后台，监控着相关事件，等待转瞬即逝的出手机会。这是一件很发指的事情，不但白白耗费了系统资源，还留了个流氓软件的骂名，这真是卖力不讨好的正面典型。
在Android中，充分考虑了广泛的这类需求，于是就有了Broadcast Receiver这样的一个组件。每个Broadcast Receiver都可以接收一种或若干种Intent作为触发事件（有不知道Intent的么，后面会知道了...），当发生这样事件的时候，系统会负责唤醒或传递消息到该Broadcast Receiver，任其处置。在此之前和这以后，Broadcast Receiver是否在运行都变得不重要了，及其绿色环保。
这个实现机制，显然是基于一种注册方式的，Broadcast Receiver将其特征描述并注册在系统中，根据注册时机，可以分为两类，被我冠名为冷热插拔。所谓冷插拔，就是Broadcast Receiver的相关信息写在配置文件中（求配置文件详情？稍安，后续奉上...），系统会负责在相关事件发生的时候及时通知到该Broadcast Receiver，这种模式适合于这样的场景。某事件方式 -> 通知Broadcast -> 启动相关处理应用。比如，监听来电、邮件、短信之类的，都隶属于这种模式。而热插拔，顾名思义，插拔这样的事情，都是由应用自己来处理的，通常是在OnResume事件中通过registerReceiver进行注册，在OnPause等事件中反注册，通过这种方式使其能够在运行期间保持对相关事件的关注。比如，一款优秀的词典软件（比如，有道词典...），可能会有在运行期间关注网络状况变化的需求，使其可以在有廉价网络的时候优先使用网络查询词汇，在其他情况下，首先通过本地词库来查词，从而兼顾腰包和体验，一举两得一石二鸟一箭双雕（注，真实在有道词典中有这样的能力，但不是通过Broadcast Receiver实现的，仅以为例...）。而这样的监听，只需要在其工作状态下保持就好，不运行的时候，管你是天大的网路变化，与我何干。其模式可以归结为：启动应用 -> 监听事件 -> 发生时进行处理。
除了接受消息的一方有多种模式，发送者也有很重要的选择权。通常，发送这有两类，一个就是系统本身，我们称之为系统Broadcast消息，在reference/android/content/Intent.html的Standard Broadcast Actions，可以求到相关消息的详情。除了系统，自定义的应用可以放出Broadcast消息，通过的接口可以是Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者发出的称为Normal broadcast，所有关注该消息的Receiver，都有机会获得并进行处理；后者放出的称作Ordered broadcasts，顾名思义，接受者需要按资排辈，排在后面的只能吃前面吃剩下的，前面的心情不好私吞了，后面的只能喝西北风了。
当Broadcast Receiver接收到相关的消息，它们通常做一些简单的处理，然后转化称为一条Notification，一次振铃，一次震动，抑或是启动一个Activity进行进一步的交互和处理。所以，虽然Broadcast整个逻辑不复杂，却是足够有用和好用，它统一了Android的事件广播模型，让很多平台都相形见绌了。更多Broadcast Receiver相关内容，参见：/reference/android/content/BroadcastReceiver.html。
Content Provider
Content Provider，听着就和数据相关，没错，这就是Android提供的第三方应用数据的访问方案。在Android中，对数据的保护是很严密的，除了放在SD卡中的数据，一个应用所持有的数据库、文件、等等内容，都是不允许其他直接访问的，但有时候，沟通是必要的，不仅对第三方很重要，对应用自己也很重要。
比如，一个联系人管理的应用。如果不允许第三方的应用对其联系人数据库进行增删该查，整个应用就失去了可扩展力，必将被其他应用抛弃，然后另立门户，自个玩自个的去了。
Andorid当然不会真的把每个应用都做成一座孤岛，它为所有应用都准备了一扇窗，这就是Content Provider。应用想对外提供的数据，可以通过派生ContentProvider类，封装成一枚Content Provider，每个Content Provider都用一个uri作为独立的标识，形如：content://com.xxxxx。所有东西看着像REST的样子，但实际上，它比REST更为灵活。和REST类似，uri也可以有两种类型，一种是带id的，另一种是列表的，但实现者不需要按照这个模式来做，给你id的uri你也可以返回列表类型的数据，只要调用者明白，就无妨，不用苛求所谓的REST。
另外，Content Provider不和REST一样只有uri可用，还可以接受Projection，Selection，OrderBy等参数，这样，就可以像数据库那样进行投影，选择和排序。查询到的结果，以Cursor（参见：reference/android/database/Cursor.html ）的形式进行返回，调用者可以移动Cursor来访问各列的数据。
Content Provider屏蔽了内部数据的存储细节，向外提供了上述统一的接口模型，这样的抽象层次，大大简化了上层应用的书写，也对数据的整合提供了更方便的途径。Content Provider内部，常用数据库来实现，Android提供了强大的Sqlite支持，但很多时候，你也可以封装文件或其他混合的数据。
在Android中，ContentResolver是用来发起Content Provider的定位和访问的。不过它仅提供了同步访问的Content Provider的接口。但通常，Content Provider需要访问的可能是数据库等大数据源，效率上不足够快，会导致调用线程的拥塞。因此Android提供了一个AsyncQueryHandler（参见：reference/android/content/AsyncQueryHandler.html），帮助进行异步访问Content Provider。
在各大组件中，Service和Content Provider都是那种需要持续访问的。Service如果是一个耗时的场景，往往会提供异步访问的接口，而Content Provider不论效率如何，都提供的是约定的同步访问接口。我想这遵循的就是场景导向设计的原则，因为Content Provider仅是提供数据访问的，它不能确信具体的使用场景如何，会怎样使用它的数据；而相比之下，Service包含的逻辑更复杂更完整，可以抉择大部分时候使用某接口的场景，从而确定最贴切的接口是同步还是异步，简化了上层调用的逻辑。
配置
四大组件说完了，四大组件幕后的英雄也该出场了，那就是每个应用都会有一份的配置文件，名称是AndroidManifest.xml，在工程的根目录下。在这个配置文件中，不仅会描述一些应用相关的信息，很重要的，会包含一个应用中所有组件的信息。如果你派生Activity或者Service实现了一个相关的类，这只是把它组件化的第一步，你需要把这个类的相关信息写到配置文件中，它才会作为一个组件被应用到，否则只能默默无闻的黯淡度过余生。
 

 

 

摆了一幅图出来，这次不是偷来的，是敝帚自珍原创，所以没有意外的画的很丑，但基本还是可以体现出一些意思。在In Others的部分，这里是一般平台应用之间通信和交互的模型，每个应用都有很强烈的应用边界（往往表现为进程边界...），App 1的还是App 2的，分得很是清楚。每个应用内部，都有自己的逻辑去切分功能组件，这样的切分通常没有什么标准，率性而为。应用间的交互逻辑也比较零散，App 1与App 2交互，往往需要明确知道对方应用的具体信息，比如进程ID，进程名称之类的，这样使得应用和应用之间的联系，变得很生硬。而上层应用和系统应用的通信，往往有很多特定的模式，这种模式，很可能是无法直接应用在普通应用之间的，换而言之，系统应用是有一定特殊性的。
重点，在图的下半部，描述的是Android的应用情形。在Android中，应用的边界，在组件这个层面，是极度模糊，什么进程、什么应用，都可以不必感知到。举个例子，App 1，实现了A和B两个组件，App 2，实现了C这个组件。A和C，都想使用B这个组件，那么它们的使用方式是完全一致的，都需要通过系统核心的组件识别和通信机制，找到和使用组件B。A，虽说和B是一个娘胎里蹦出来的，很不好意思，没有任何特殊的后面和捷径，还是要跑规矩的途径才能用到，一片和谐社会的景象油然而生。
在Android中，所有组件的识别和消息传递逻辑都必须依赖底层核心来进行（通信可以没有底层核心的参与，比如一旦Service找到了，就可以和它产生持久的通信...），没有底层核心的牵线搭桥，任何两个组件都无法产生联系。比如一个Activity，跳到另一个Activity，必须要向底层核心发起一个Intent，有底层解析并认可后，会找到另一个Activity，把相关消息和数据传给它。一个Activity想使用Content Provider中的数据，必须通过底层核心解析相关的uri，定位到这个Content Provider，把参数传递给它，然后返回Activity需要的Cursor。这样的设计，保证了底层核心对所有组件的绝对掌控权和认知权，使得搭积木似的开发变成可能。
为了，使得核心系统能够完整的掌握每个组件的信息，这就需要配置文件了。配置文件，就是将组件插到底层核心上的这个插头。只有通过这个插头插在底层核心的插座上（不要乱想，非十八禁...），组件才能够发光发热，闪耀光芒。
组件的配置信息在我看来主要包含两个方面，一部分是描述如何认知。比如，Activity、Service、Broadcast Receiver都会有名字信息，和希望能够把握的Intent信息（姑且看成消息好了...），Content Provider会有一个描述其身份的uri。当其他组件通过这样的名字或者Intent，就可以找到它。
另一部分是运行相关的信息。这个组件，期望怎么来运行，放在单独的进程，还是和调用者一个进程，还是找相关的其他组件挤在同一个进程里面，这些内容，都可以在配置的时候来决定（调用者在这个约束范围内，有进一步的选择权...）。更多配置项，请参见：guide/topics/manifest/manifest-intro.html。
通过前续内容，也许可以帮助大家对Android组件有个初略的了解。但这些了解都还停留在静态层面，程序是个动态的概念，关于各个组件具体是怎么联系在一起的，如何手拉手运行起来完成一项功能的，这便是后话了。
Intent解析

基于组件的架构体系，除了有定义良好的组件，如何把这些组件组装在一起，也是一门艺术。在Android中，Intent（貌似通常译作：意图...），就是连接各组件的桥梁。
前段时间看同事们做Symbian平台的网易掌上邮（真的是做的用心，NB的一米，热情欢迎所有163邮箱的S60v3用户，猛点击之...），有个功能是为邮件添加附件，比如你想要通过邮件发送一副图片泡mm，可能需要有个很直观的方式从本地选一副珍藏美图，抑或是拿相机来个完美自拍。在Symbian中，这样的功能，都需要你用底层的API，自己一点点写。为了让选图片体验更好，可能需要做一个类似于图片浏览器之类的东西，为了把拍照做的更为顺畅，甚至需要实现从聚焦到调节亮度之类一整套的相机功能。
而其实呢，用户的手机中可能本身就装了其他的专业图片浏览器、相机等应用，这些应用已经非常出色好用，而用户也已然能很纯属使用它们，如果能进行调用，对邮箱的开发者和用户而言，都会是个更好的选择。但在Symbian这样残败的系统里，应用和应用之间的结合能力奇弱无比，想复用，基本比登天还难，作为开发者，只能忍住一次又一次的恶心，为了用户，做这些重复造轮子吃力不讨好的附加工作。
还好还好，在Android中，一切变得美好多了，它将开发者从接口和对象的细节中解救出来，让我们有更多精力投入到核心功能的开发中去。在Android中，如果你需要选个图拍个片，只需要构造一个描述你此项意愿的Intent，发送出去，系统会帮你选择一个能够处理该项业务的组件来满足你的需求，而不再需要纠结在具体的接口和实现上，Perfect World，便应如此。

Intent构成
Intent被译作意图，其实还是很能传神的，Intent期望做到的，就是把实现者和调用者完全解耦，调用者专心将以意图描述清晰，发送出去，就可以梦想成真，达到目的。
当然，这么说太虚了，庖丁解牛，什么东西切开来看看，也许就清晰了。Intent（reference/android/content/Intent.html），在Android中表现成一个类，发起一个意图，你需要构造这样一个对象，并为下列几项中的一些进行赋值：

Action。当日常生活中，描述一个意愿或愿望的时候，总是有一个动词在其中。比如：我想做三个俯卧撑；我要看一部x片；我要写一部血泪史，之类云云。在Intent中，Action就是描述看、做、写等动作的，当你指明了一个Action，执行者就会依照这个动作的指示，接受相关输入，表现对应行为，产生符合的输出。在Intent类中，定义了一批量的动作，比如ACTION_VIEW，ACTION_PICK，之类的，基本涵盖了常用动作，整一个降龙十八掌全集。当然，你也可以与时俱进，创造新的动作，比如lou这样的。与系统预定义的相比，这些自定义动作的流通范围很是有限，除非做了非常NB的应用，大家都需要follow你，否则通常都是应用内部流通。
Data。当然，光有动作还是不够的，还需要有更确切的对象信息。比如，同样是泡这个动作，但泡咖啡，和泡妞，就差之千里了。Data的描述，在Android中，表现成为一个URI。用在内部通信中，可能描述是Content Provider用的形如content://xxxx这样的东东，抑或是外部的一个形如tel://xxxx这样的链接。总而言之，是能够清楚准确的描述一个数据地址的uri。
Type。说了Data，就必须要提Type，很多时候，会有人误解，觉着Data和Type的差别，就犹如泡妞和泡马子之间的差别一样，微乎其微。但其实不然，Type信息，是用MIME来表示的，比如text/plain，这样的东西。说到这里，两者差别就很清晰了，Data就是门牌号，指明了具体的位置，具体问题具体分析，而type，则是强调物以类聚，解决一批量的问题。实际的例子是这样的，比如，从某个应用拨打一个电话，会发起的是action为ACTION_DIAL且data为tel:xxx这样的Intent，对应的人类语言就是拨打xxx的电话，很具象。而如果使用type，就宽泛了许多，比如浏览器收到一个未知的MIME类型的数据（比如一个视频...），就会放出这样的Intent，求系统的其他应用来帮助，表达成自然语言应该就是：查看pdf类文档，这样的。
Category。通过Action，配合Data或Type，很多时候可以准确的表达出一个完整的意图了，但也会有些时候，还需要加一些约束在里面才能够更精准。比如，如果你虽然很喜欢做俯卧撑，但一次做三个还只是在特殊的时候才会发生，那么你可能表达说：每次吃撑了的时候，我都想做三个俯卧撑。吃撑了，这就对应着Intent的Category的范畴，它给所发生的意图附加一个约束。在Android中，一个实例是，所有应用主Activity（就是单独启动时候，第一个运行的那个Activity...），都需要能够接受一个Category为CATEGORY_LAUNCHER，Action为ACTION_Main的意图。
Component。在此之前，我们企图用Action，Data/Type，Category去描述一个意图，这是Android推荐，并期望大家在大多数时候使用的，这样模式在Android中称做Implicit Intents，通过这种模式，提供一种灵活可扩展的模式，给用户和第三方应用一个选择权。比如，还是一个邮箱软件，他大部分功能都好，就是选择图片的功能做的很土，怎么办？如果它采用的是Implicit Intents，那么它就是一个开放的体系了，手机中没有其他图片选择程序的话，可以继续使用邮箱默认的，如果有，你可以任意选择来替代原有模块完整这功能，一切都自然而然。但这种模式，也不是没有成本，需要付出的是一些性能上的开销，因为毕竟有一个检索过程。于是，Android提供了另一种模式，叫做Explicit Intents，就需要Component的帮助了。Component就是类名，完整的，形如com.xxxxx.xxxx，一旦指明了，一切都清晰了，找的到这个类（当然会是一个特定的子类...），成功，反之，失败。这个好处，自然是速度，适合在你明确知道这就是一个内部模块的时候，使用它。
Extras。通过上面的这些项，识别问题，基本完美解决了，剩下一个重要的问题，就是传参。Extras是用来做这个事情的，它是一个Bundle类的对象，有一组可序列化的key/value对组成。每一个Action，都会有与之对应的key和value类型约定，发起Intent的时候，需要按照要求把Data不能表示的额外参数放入Extras中（当然，如果不需要额外附加参数，就算了...），否则执行者拿到的时候会抓狂的。
Flags。能识别，有输入，整个Intent基本就完整了，但还有一些附件的指令，需要放在Flags中带过去。顾名思义，Flags是一个整形数，有一些列的标志位构成，这些标志，是用来指明运行模式的。比如，你期望这个意图的执行者，和你运行在两个完全不同的任务中（或说进程也无妨吧...），就需要设置FLAG_ACTIVITY_NEW_TASK的标志位。

有了上述这些，一个Intent的形象就跃然纸上了，如此丰富的内容，决定了它比传统的模式，都来得强大。

Intent匹配
上次在moto dev上，听人做Android的讲座，下面有很多听客都对Intent这个概念表示出了强烈的兴趣，拿出自己熟悉领域的各类概念进行类比，比如事件、消息之类。当时我在想，Intent作为组件间的通信协定，与一般的简单的通信方式不同，首先，从前面部分可以看到，它的描述是针对需求而不是实现者来进行的。其次，它的解析是依托第三方而不是两方直接进行。
这个概念和设计模式中的中介模式（Mediator Pattern）是一脉的，即所有的外围组件，都只和系统的核心模块发生联系，通过它进行中转，组件之间不直接勾搭。

 

如上图所示，要想跑通整个流程，另一个很重要的东西，就是Intent Filters，它是用来描述一个Activity或Serveice等组件，期望能够响应怎么样的Intent。如果一个组件，只希望别的组件通过Explicit Intents（就是指明Component...）的方式来找到它，那么就不需要添加Intent Filters，反之，一定需要一个或若干个Intent Filters。Intent Filter的各个项，犹如Intent照镜子过来的效果，包括Action，Catagory，Data，Type等。
Intent Filters可以写到配置文件中，和那些组件的配置一起（不记得什么是配置文件了，可以看这里...），若干的实例可以在Intent介绍页面上找到（reference/android/content/Intent.html）。同样，Intent Filters可以在代码中，动态插拔，这个是和动态插拔的Broadcast Receiver是配套使用的。
系统核心的模块，会负责收集这些Intent Filters，和它们对应的组件信息。当请求者需要一个组件帮忙，并构造了描述它需求的Intent发送到系统核心，系统核心会将其与已知的各个Intent Filters进行匹配，挑选一个符合需求的组件返回。如果有多个符合的，会尝试看看有没有默认执行的，如果没有默认的，就会构造UI，让用户帮助抉择，如是，整个流程就跑通了。

Intent实现

 

上图，是请求一个Activity组件的简单实现流程图，算是用的最多的Intent解析实例。流程从调用Context.startActivity(Intent)开始，调用者传入构造好的Intent对象，然后流程会让实际的执行者，是Instrumentation对象来完成。它是整个应用激活的Activity管理者，集中负责该应用内所有Activity的起承转合生离死别。它有一个隐藏的方法execStartActivity方法，就是负责根据Intent启动Activity的。去掉一些细节，它做得最重要的事情，就是将此调用，通过RPC的方式，传递到ActivityManagerService。
前面一直再说，系统核心层，其实这里所谓的系统核心层，就是负责Android一些关键事务的一组服务。它们同样运行在虚拟机上，和普通的Service实现机理是一致的，只不过它们不抛头露脸只是默默的在下层服务，故谓之核心嘛。AcitivityManagerService，是负责Activity调度的服务，也许日后提及调度细节的时候还会有涉及。
在这里，AcitivityManagerService会分两个步骤完成相关操作，首先把Intent递交给另一个服务PackageManagerService，此服务掌握整个软件包及其各组件的信息，它会将传递过来的Intent，与已知的所有Intent Filters进行匹配（如果带有Component信息，就不用比了...），找到了，就把相关Component的信息通知回AcitivityManagerService，在这里，会完成启动Activity这个很多细节的事情。
由此可知，启动Activity，要经过多个服务的处理，并不是非常轻量的过程，在Android随机文档介绍性能的一节中，对此有一个评估。但这样的操作不是会放在循环里反复折磨的那种，因此整体效果与其付出的性能代价相比，觉得是物超所值的。
事件 Task栈（粗体为栈顶组件）
点开Email应用，进入收件箱（Activity A） A
选中一封邮件，点击查看详情（Activity B） AB
点击回复，开始写新邮件（Activity C） ABC
写了几行字，点击选择联系人，进入选择联系人界面（Activity D） ABCD
选择好了联系人，继续写邮件 ABC
写好邮件，发送完成，回到原始邮件 AB
点击返回，回到收件箱 A
退出Email程序 null

 

 

如上表所示，是一个实例。从用户从进入邮箱开始，到回复完成，退出应用整个过程的Task栈变化。这是一个标准的栈模式，对于大部分的状况，这样的Task模型，足以应付，但是，涉及到实际的性能、开销等问题，就会变得残酷许多。比如，启动一个浏览器，在Android中是一个比较沉重的过程，它需要做很多初始化的工作，并且会有不小的内存开销。但与此同时，用浏览器打开一些内容，又是一般应用都会有的一个需求。设想一下，如果同时有十个运行着的应用（就会对应着是多个Task），都需要启动浏览器，这将是一个多么残酷的场面，十个Task栈都堆积着很雷同的浏览器Activity，是多么华丽的一种浪费啊。于是你会有这样一种设想，浏览器Activity，可不可以作为一个单独的Task而存在，不管是来自那个Task的请求，浏览器的Task，都不会归并过去。这样，虽然浏览器Activity本身需要维系的状态更多了，但整体的开销将大大的减少，这种舍小家为大家的行为，还是很值得歌颂的。
如此值得歌颂的行为，Android当然会举双手支持的。在Android中，每一个Activity的Task模式，都是可以由Activity提供方（通过配置文件...）和Activity使用方（通过Intent中的flag信息...）进行配置和选择。当然，使用方对Activity的控制力，是限定在提供方允许的范畴内进行，提供方明令禁止的模式，使用方是不能够越界使用的。
在SDK中（guide/topics/fundamentals.html#acttask），将两者实现Task模式配置的方式，写的非常清晰了，我再很絮叨挑选一些来解释一下（完整可配置项，一定要看SDK，下面只是其中常用的若干项...）。提供方对组件的配置，是通过配置文件（Manifest） 项来进行的，而调用方，则是通过Intent对象的flag进行抉择的。相对于标准的Task栈的模式，配置的主要方向有两个：一则是破坏已有栈的进出规则，或样式；另一则是开辟新Task栈完成本应在同一Task栈中完成的任务。
对于应用开发人员而言，中的launchMode属性，是需要经常打交道的。它有四种模式："standard", "singleTop", "singleTask", "singleInstance"。
standard模式， 是默认的也是标准的Task模式，在没有其他因素的影响下，使用此模式的Activity，会构造一个Activity的实例，加入到调用者的Task栈中去，对于使用频度一般开销一般什么都一般的Activity而言，standard模式无疑是最合适的，因为它逻辑简单条理清晰，所以是默认的选择。
而singleTop模式，基本上于standard一致，仅在请求的Activity正好位于栈顶时，有所区别。此时，配置成singleTop的Activity，不再会构造新的实例加入到Task栈中，而是将新来的Intent发送到栈顶Activity中，栈顶的Activity可以通过重载onNewIntent来处理新的Intent（当然，也可以无视...）。这个模式，降低了位于栈顶时的一些重复开销，更避免了一些奇异的行为（想象一下，如果在栈顶连续几个都是同样的Activity，再一级级退出的时候，这是怎么样的用户体验...），很适合一些会有更新的列表Activity展示。一个活生生的实例是，在Android默认提供的应用中，浏览器（Browser）的书签Activity（BrowserBookmarkPage），就用的是singleTop。
singleTop模式，虽然破坏了原有栈的逻辑（复用了栈顶，而没有构造新元素进栈...），但并未开辟专属的Task。而singleTask，和singleInstance，则都采取的另辟Task的蹊径。标志为singleTask的Activity，最多仅有一个实例存在，并且，位于以它为根的Task中。所有对该Activity的请求，都会跳到该Activity的Task中展开进行。singleTask，很象概念中的单件模式，所有的修改都是基于一个实例，这通常用在构造成本很大，但切换成本较小的Activity中。在Android源码提供的应用中，该模式被广泛的采用，最典型的例子，还是浏览器应用的主Activity（名为Browser...），它是展示当前tab，当前页面内容的窗口。它的构造成本大，但页面的切换还是较快的，于singleTask相配，还是挺天作之合的。
相比之下，singleInstance显得更为极端一些。在大部分时候singleInstance与singleTask完全一致，唯一的不同在于，singleInstance的Activity，是它所在栈中仅有的一个Activity，如果涉及到的其他Activity，都移交到其他Task中进行。这使得singleInstance的Activity，像一座孤岛，彻底的黑盒，它不关注请求来自何方，也不计较后续由谁执行。在Android默认的各个应用中，很少有这样的Activity，在我个人的工程实践中，曾尝试在有道词典的快速取词Activity中采用过，是因为我觉得快速取词入口足够方便（从notification中点选进入），并且会在各个场合使用，应该做得完全独立。
除了launchMode可以用来调配Task，的另一属性taskAffinity，也是常常被使用。taskAffinity，是一种物以类聚的思想，它倾向于将taskAffinity属性相同的Activity，扔进同一个Task中。不过，它的约束力，较之launchMode而言，弱了许多。只有当中的allowTaskReparen ting设置为true，抑或是调用方将Intent的flag添加FLAG_ACTIVITY_NEW_TASK属性时才会生效。如果有机会用到Android的Notification机制就能够知道，每一个由notification进行触发的Activity，都必须是一个设成FLAG_ACTIVITY_NEW_TASK的Intent来调用。这时候，开发者很可能需要妥善配置taskAffinity属性，使得调用起来的Activity，能够找到组织，在同一taskAffinity的Task中进行运行。

进程
在大多数其他平台的开发中，每个开发人员对自己应用的进程模型都有非常清晰的了解。比如，一个控制台程序，你可以想见它从main函数开始启动一个进程，到main函数结束，进程执行完成退出；在UI程序中，往往是有一个消息循环在跑，当接受到Exit消息后，退出消息循环结束进程。在该程序运行过程中，启动了什么进程，和第三方进程进行通信等等操作，每个开发者都是心如明镜一本帐算得清清楚楚。进程边界，在这里，犹如国界一般，每一次穿越都会留下深深的印迹。
在Android程序中，开发人员可以直接感知的，往往是Task而已。倍感清晰的，是组件边界，而进程边界变得难以琢磨，甚至有了进程托管一说。Android中不但剥夺了手工锻造内存权力，连手工处置进程的权责，也毫不犹豫的独占了。
当然，Android隐藏进程细节，并不是刻意为之，而是自然而然水到渠成的。如果，我们把传统的应用称为面向进程的开发，那么，在Android中，我们做得就是面向组件的开发。从前面的内容可以知道，Android组件间的跳转和通信，都是在第三方介入的前提下进行，正由于这种介入，使得两个组件一般不会直接发生联系（于Service的通信，是不需要第三方介入的，因此Android把它全部假设成为穿越进程边界，统一基于RPC来通信，这样，也是为了掩盖进程细节...），其中是否穿越进程边界也就变得不重要。因此，如果这时候，还需要开发者关注进程，就会变得很奇怪，很费解，干脆，Android将所有的进程一并托管去了，上层无须知道进程的生死和通信细节。
在Android的底层，进程构造了底部的一个运行池，不仅仅是Task中的各个Activity组件，其他三大组件Service、Content Provider、Broadcast Receiver，都是寄宿在底层某个进程中，进行运转。在这里，进程更像一个资源池（概念形如线程池，上层要用的时候取一个出来就好，而不关注具体取了哪一个...），只是为了承载各个组件的运行，而各个组件直接的逻辑关系，它们并不关心。但我们可以想象，为了保证整体性，在默认情况下，Android肯定倾向于将同一Task、同一应用的各个组件扔进同一个进程内，但是当然，出于效率考虑，Android也是允许开发者进行配置。
在Android中，整体的 （将影响其中各个组件...）和底下各个组件，都可以设置 属性，相同属性的组件将扔到同一个进程中运行。最常见的使用场景，是通过配置的process属性，将不同的相关应用，塞进一个进程，使得它们可以同生共死。还有就是将经常和某个Service组件进行通信的组件，放入同一个进程，因为与Service通信是个密集操作，走的是RPC，开销不小，通过配置，可以变成进程内的直接引用，消耗颇小。
除了通过属性，不同的组件还有一些特殊的配置项，以Content Provider为例（通过 项进行配置...）。项有一个mutiprocess的属性，默认值为false，这意味着Content Provider，仅会在提供该组件的应用所在进程构造一个实例，第三方想使用就需要经由RPC传输数据。这种模式，对于构造开销大，数据传输开销小的场合是非常适用的，并且可能提高缓存的效果。但是，如果是数据传输很大，抑或是希望在此提高传输的效率，就需要将mutiprocess设置成true，这样，Content Provider就会在每一个调用它的进程中构造一个实例，避免进程通信的开销。
既然，是Android系统帮助开发人员托管了进程，那么就需要有一整套纷繁的算法去执行回收逻辑。Android中各个进程的生死，和运行在其中的各个组件有着密切的联系，进程们依照其上组件的特点，被排入一个优先级体系，在需要回收时，从低优先级到高优先级回收。Android进程共分为五类优先级，分别是：Foreground Process, Visible Process, Service Process, Background Process, Empty Process。顾名思义不难看出，这说明，越和用户操作紧密相连的，越是正与用户交互的，优先级越高，越难被回收。具体详情，参见：guide/topics/fundamentals.html#proclife。
有了优先级，还需要有良好的回收时机。回收太早，缓存命中概率低可能引起不断的创造进程销毁进程，池的优势荡然无存；回收的太晚，整体开销大，系统运行效率降低，好端端的法拉利可能被糟蹋成一枚QQ老爷车。Android的进程回收，最重要的是考量内存开销，以及电量等其他资源状况，此外每个进程承载的组件数量、单个应用开辟的进程数量等数量指标，也是作为衡量的一个重要标识。另外，一些运行时的时间开销，也被严格监控，启动慢的进程会很被强行kill掉。Android会定时检查上述参数，也会在一些很可能发生进程回收的时间点，比如某个组件执行完成后，来做回收的尝试。
从用户体验角度来看，Android的进程机制，会有很可喜的一面，有的程序启动速度很慢，但是在资源充沛的前提下，你反复的退出再使用，则启动变得极其快速（进程没死，只是从后台弄到了前台），这就是拜进程托管所赐的。当然，可喜的另一面就是可悲了，Android的托管算法，还时不时的展现其幼稚的一面，明明用户已经明显感觉到操作系统运行速度下降了，打开任务管理器一看，一票应用还生龙活虎的跳跃着，必须要手动帮助它们终结生命找到坟墓，这使得任务管理器基本成为Android的装机必备软件。
从开发角度上来看，Android这套进程机制，解放了开发者的手脚。开发人员不需要处心积虑的构造一个后台进程偷偷默默监听某个时间，并尝试用各种各样的守护手段，把自己的进程锻造的犹如不死鸟一辉一般，进程生死的问题，已经原理了普通开发人员需要管理的范畴内。但同时，于GC和人肉内存管理的争议一样，所有开发人员都不相信算法能比自己做得效率更高更出色。但我一直坚信一点，所有效率的优势都会随着算法的不断改良硬件的不断提升而消失殆尽，只有开发模式的简洁不会随时间而有任何变化。

组件生命周期
任何架构上的变化，都会引起上层开发模式的变化，Android的进程模型，虽然使开发者不再需要密切关注进程的创建和销毁的时机，但仍然需要关注这些时间点对组件的影响。比如，你可能需要在进程销毁之前，将写到内存上的内容，持久化到硬盘上，这就需要关注进程退出前发生的一些事件。
在Android中，把握这些时间点，就必须了解组件生命周期（Components Lifecycles）。所谓组件的生命在周期，就是在组件在前后台切换、被用户创建退出、被系统回收等等事件发生的时候，会有一些事件通知到对应组件上，开发人员可以选择性的处理这些事件在对应的时间点上来完成一些附加工作。
除Content Provider，其他组件都会有生命周期的概念，都需要依照这个模型定时定点处理一些状况，全部内容参见：guide/topics/fundamentals.html#lcycles。在这里，擒贼先擒王，还是拿Activity出来作楷模。

 

继续偷图，来自SDK。一个自然的Activity生命旅途，从onCreate开始，到onDestroy消亡。但月有阴晴圆缺组件有祸福旦夕，在系统需要的时候且组件位于后台时，所在的进程随时可能为国捐躯被回收，这就使得知道切入后台这个事情也变得很重要。
当组件进入栈顶，与用户开始交互，会调用onResume函数，类似，当退出栈顶，会有onPause函数被呼唤。onResume和onPause可以处理很多事情，最常规的，就是做一些文件或设置项的读写工作。因为，在该组件不再前台运行的时候，可能别的组件会需要读写同样一份文件和设置，如果不再onResume做刷新工作，用的可能就是一份脏数据了（当然，具体情况，还需要具体分析，如果文件不会被多头读写，可以放到onCreate里面去做读工作）。
除了前述切入后台会被其他组件骚扰的问题，另外，死无定因也是件很可怕的事情。在Android中，组件都有两种常见的死法，一种是自然消亡，比如，栈元素ABC，变成AB了，C组件就自然消亡了。这种死发轻如鸿毛，不需要额外关心。但另一种情况，就是被系统回收，那是死的重如泰山，为国捐躯嘛。
但这种捐躯的死法，对用户来说，比较费解。想象一下，一款游戏，不能存盘，你一直玩啊玩，三天三夜没合眼，这时候你mm打来电话鼓励一下，你精神抖擞的准备再接再厉，却发现你的游戏进程，在切入后台之后，被系统回收了，一夜回到解放前三天努力成为一场泡影，你会不会想杀做游戏的人，会不会会不会会不会，一定会嘛。这时候，如果没有Activity生命周期这码事，游戏程序员一定是被冤死的，成了Android的替罪羊。但是，Android的组件是有生命周期的，如果真的发生这样情况，不要犹豫，去杀开发的程序员吧。
为了逃生，程序员们有一块免死金牌，那就是Android的state机制。所谓state，就是开发人员将一些当前运行的状态信息存放在一个Bundle对象里面，这是一个可序列化键值对集合。如果该Activity组件所处的进程需要回收，Android核心会将其上Activity组件的Bundle对象持久化到磁盘上，当用户回到该Activity时候，系统会重新构造该组件，并将持久化到磁盘上的Bundle对象恢复。有了这样的持久化的状态信息，开发人员可以很好的区分具体死法，并有机会的使得死而复生的Activity恢复到死前状态。开发者应该做的，是通过onSaveInstanceState函数把需要维系的状态信息（在默认的状态下，系统控件都会自己保存相关的状态信息，比如TextView，会保存当前的Text信息，这都不需要开发人员担心...），写入到Bundle对象，然后在onRestoreInstanceState函数中读取并恢复相关信息（onCreate，onStart，也都可以处理...）。

线程
读取数据，后台处理，这些猥琐的伙计，自然少不了线程的参与。在Android核心的调度层面，是不屑于考量线程的，它关注的只有进程，每一个组件的构造和处理，都是在进程的主线程上做的，这样可以保证逻辑的足够简单。多线程，往往都是开发人员需要做的。
Android的线程，也是通过派生Java的Thread对象，实现Run方法来实现的。但当用户需要跑一个具有消息循环的线程的时候，Android有更好的支持，来自于Handler和Looper。Handler做的是消息的传送和分发，派生其handleMessage函数，可以处理各种收到的消息，和win开发无异。Looper的任务，则是构造循环，等候退出或其他消息的来临。在Looper的SDK页面，有一个消息循环线程实现的标准范例，当然，更为标准的方式也许是构造一个HandlerThread线程，将它的Looper传递给Handler。
在Android中，Content Provider的使用，往往和线程挂钩，谁让它和数据相关呢。在前面提到过，Content Provider为了保持更多的灵活性，本身只提供了同步调用的接口，而由于异步对Content Provider进行增删改查是一个常做操作，Android通过AsyncQueryHandler对象，提供了异步接口。这是一个Handler的子类，开发人员可以调用startXXX方法发起操作，通过派生onXXXComplete方法，等待执行完毕后的回调，从而完成整个异步调用的流程，十分的简约明了。

实现
整个任务、进程管理的核心实现，尽在ActivityManagerService中。上一篇说到，Intent解析，就是这个ActivityManagerService来负责的，其实，它是一个很名不副实的类，因为虽然名为Activity的Manager Service，但它管辖的范围，不只是Activity，还有其他三类组件，和它们所在的进程。
在ActivityManagerService中，有两类数据结构最为醒目，一个是ArrayList，另一个是HashMap。ActivityManagerService有大量的ArrayList，每一个组件，会有多个ArrayList来分状态存放。调度工作，往往就是从一个ArrayList里面拿出来，找个方法调一调，然后扔到另一个ArrayList里面去，当这个组件没对应的ArrayList放着的时候，说明它离死不远了。HashMap，是因为有组件是需要用名字或Intent信息做定位的，比如Content Provider，它的查找，都是依据Uri，有了HashMap，一切都顺理成章了。
ActivityManagerService用一些名曰xxxRecord的数据结构，来表达各个存活的组件。于是就有了，HistoryRecord（保存Activity信息的，之所以叫History，是相对Task栈而言的...），ServiceRecord，BroadcastRecord，ContentProviderRecord，TaskRecord，ProcessRecord，等等。
值得注意的，是TaskRecord，我们一直再说，Task栈这样的概念，其实，真实的底层，并不会在TaskRecord中，维系一个Activity的栈。在ActivityManagerService中，各个任务的Activity，都以HistoryRecord的形式，集中存放在一个ArrayList中，每个HistoryRecord，会存放它所在TaskRecord的引用。当有一个Activity，执行完成，从概念上的Task栈中退出，Android是通过从当前HistoryRecord位置往前扫描同一个TaskRecord的HistoryRecord来完成的。这个设计，使得上层很多看上去逻辑很复杂的Task体系，在实现变得很统一而简明，值得称道。
ProcessRecord，是整个进程托管实现的核心，它存放有运行在这个进程上，所有组件的信息，根据这些信息，系统有一整套的算法来决议如何处置这个进程，如果对回收算法感兴趣，可以从ActivityManagerService的trimApplications函数入手来看。
对于开发者来说，去了解这部分实现，主要是可以帮助理解整个进程和任务的概念，如果觉得这块理解的清晰了，就不用去碰ActivityManagerService这个庞然大物了。

任务、进程和线程
关于Android中的组件和应用，之前涉及，大都是静态的概念。而当一个应用运行起来，就难免会需要关心进程、线程这样的概念。在Android中，组件的动态运行，有一个最与众不同的概念，就是Task，翻译成任务，应该还是比较顺理成章的。

Task的介入，最主要的作用，是将组件之间的连接，从进程概念的细节中剥离出来，可以以一种不同模型的东西进行配置，在很多时候，能够简化上层开发人员的理解难度，帮助大家更好的进行开发和配置。

任务
在SDK中关于Task（guide/topics/fundamentals.html#acttask），有一个很好的比方，说，Task就相当于应用（application）的概念。在开发人员眼中，开发一个Android程序，是做一个个独门独户的组件，但对于一般用户而言，它们感知到的，只是一个运行起来的整体应用，这个整体背后，就是Task。
Task，简单的说，就是一组以栈的模式聚集在一起的Activity组件集合。它们有潜在的前后驱关联，新加入的Activity组件，位于栈顶，并仅有在栈顶的Activity，才会有机会与用户进行交互。而当栈顶的Activity完成使命退出的时候，Task会将其退栈，并让下一个将跑到栈顶的Activity来于用户面对面，直至栈中再无更多Activity，Task结束。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wanghui_nju/archive/2010/05/27/5625552.aspx