今天研究了一下Google提供的有关Android应用程序组件的解释。了解点理论原理找找Android应用程序开发的思考方向！
至少知道了要开发一个能够与Android系统驱动的移动终端交互的软件，需要从那些方面去撬开Android系统的嘴，让它跟你的应用程序说话，交流，帮你的应用程序做事。
细想一下，开发一个应用程序安装到Android驱动的终端设备上，处理编写一些应用程序要达到的目标所需要的逻辑以外，主要的还是跟Android系统以及它上面的那些功能软件互动，比如相机，蓝牙，网络，电话，通讯录，email等等。它们中有些更是需要硬件的支持。问题出来了，我们写程序是怎么跟这些东西交互呢？
Android的SDK 众多通道给我们，它们以应用程序组件的形式存在。我们编写一般的应用程序基础基本上都是它们来搭建的。
Google说它们是你建造应用程序砖瓦。可不要小瞧这些石头瓦碴，它们可是你的应用程序和Android系统搭上伙的代理人。当然，有些可能不能直接满足你的应用程序跟系统或者其它软件交流的需求，但是它的存在就证明了它是有意义的，它所扮演的角色需要我们慢慢了解。
Google给出了4类组件，需要程序开发者详细研究：
1. Activities：
活动？ 其实就是我们在移动终端上打开一个用户界面进行相关的操作，这就是一个Activity。比如，我们打开Email程序的新邮件列表查看新邮件，这就是一个Activity，同样，打开写邮件页面又是另外一个Activity，从新邮件列表页面选择一个新邮件打开浏览界面又是一个新的Activity。这样看来，一个Email应用程序就成了这么众多的Activity的集合了！
Android系统下这些Activity之间都是相互独立的，当然用户在使用Email程序的时候是感觉不出来的。这众多独立的Activity组合在一起反而给了用户很好的操作体验。那么独立性体现在哪里呢？比如上面Email中的那些Activity，一个其它的的应用程序完全可以在邮件应用程序允许的情况下，启动上面所说的Activity中的任何一个。也就是说Email应用程序可以被肢解这运行，神奇吧！因为Android系统基于Linux内核，Android系统的最独特设计就是任何应用程序都能启动其它应用程序的组件，当然首先得活动许可才行！
如此一来，我们可以理解了，我们为什么能够打开拍照的应用软件，配一张照片然后直接可以选择发邮件跟朋友们共享了，表面上是拍照软件具备了发邮件的功能，其实不然！而是拍照程序调用了Email程序中的发邮件Activity而已。
Activity给了我们超强的灵活性啊，随心所欲的使用其它无论是系统自带的Activity还是其它应用程序中的Activity，只需要事前获得它们的许可即可。
其实我们编写Android应用程序，首先就是考虑怎么把应用定义成一个个的Activity。然后通过实例化Android SDK提供的Activity类来生成这些Activity。
2.Services：
服务！任何系统都不会拒绝它，因为它总是给人们带来默默的帮助，让我们的每一个行动都变得轻松舒心！
Android系统中当然也必须得有啦！ 那么服务到底是什么呢？
Google说：它就是一个运行在后台去执行一个长期操作或者为远程进程默默工作的组件。
你可能一般看不到它，因为它不提供用户界面！但是你能感受到它的存在给你带来的好处。
比如你在跟一个Activity交互呢，另一个组件在帮你从网络上下载数据，但是你没觉察到它，这个组件就是service了！
要实现一个服务组件你需要定义Google提供的Services类的子类，通过继承该类获取一些运行在Android系统的必要接口。
3.Content Providers：
内容提供者，故名思议就是能够给你提供一些内容的一个组件，相当于一个容器。 提供什么内容呢？ 前面说了，Linux下每个应用程序都是运行在自己的线程里的。程序之间都是相互隔离的，同时安全规则限制相互访问时不可能的，那么Android能够启动其它应用程序的组件为自己完成某种功能，完成的结果怎么交流，估计就靠它了！
它的每一个实例都会管理一个应用程序的共享数据集合。说白了，就是给你一个访问其它应用组件的数据和资源的代理或者通道。
因为在Android系统中你可以把应用程序的数据保存到系统文件中，或者集成的一个SQLite数据库中，或者放到网上云端服务器，或者任何你的应用程序能够访问到存储的地方。就通过这个内容提供者，其它的应用程序可以查询甚至在内容提供者允许的情况下修改这些数据。
比如，Android系统提供了一个内容提供者（ContactsContract.Data)管理着用户的通讯录信息，这样任何获得相应许可的应用程序都可以查询内容提供者的部分来读取和回写有关某个特定人的信息了。
Android系统为开发者提供了一个ContentProvider类，我们要使用内容提供者就必须继承这个类，同时你一可以实现一个标准的事务API，来让其具备事务处理能力。
4.BroadCast recievers：
字面意思广播接收者，其实它是Android系统中一个系统和其它应用程序的网关或者通道组件，负责系统范围内广播通知。
比如，我们用手机没电时，总会突然接收到电量不足的通知，这就是Android系统产生的一个广播。其实有许多广播产生于系统，比如一个广播通知说屏幕关闭，电池电量过低，或者一个图片被抓取等等。应用程序也可以初始化广播，比如，通知其它应用程序一些数据被下载到了设备上他们可以使用了。尽管广播系统没有用户界面，但它们可能会创建一个状态栏通知来提示用户一个广播事件发生。
Android系统同样提供了父类BroadcastReciever类来完成基本的一些操作，我们定义广播接收者时需要继承它。
总结Google介绍给我们的这四类组件，我们能够感觉出一个Android应用程序的整体组成。
首先是Activity，它就是你程序完成某个功能的一个流程。从创建到执行到结束，说明你要求的一个功能的完成。当然在这个过程中你可能有中断，之后又继续，还会有意外终止等。Activity是Android系统用来管理你的一个功能进程生命周期的一个类。宏观上说你需要通过Activity来管理你的功能执行过程。你在设计应用程序的时候，首先要考虑怎么设计符合Activity的生命周期。
其次，Service是后台帮助你处理某些长期工作的，能为你的Activity提供长久的支持服务。你的Activity可以对它进行操作，比如启动，暂停，中止，关闭等等。
Service组件可以是你应用程序服务的一部分，也可以是独立的一个应用，辅助你完成一些功能的实现。
而ContentProvider则是一个打开共享的窗口，它帮助你管理你的应用程序的共享数据包括读取，写入存储等等。你可以通过许可设置，来对其它应用程序的ContentProvider调用，从而获取其它应用程序的共享数据资源。而至于BroadCast Receivers 它像信使，之前说过每一个应用程序组件包括系统的组件都是运行在自己的进程中的，而Linux系统对每个应用程序都看作一个独立唯一的用户来管理，所以上面说的Android系统中一个应用程序的组件要想调用另外一个应用程序的Activity来完成某项功能，它就必须为这个Activity所在的应用程序启动一个新的进程来运行，这个过程调用者是不可能直接调用的，它只能表达自己的意思，也就是产生一个想法意图，通过广播或者消息传递给Linux，由Linux帮忙来启动这个应用程序的进程运行相应的Activity。 而这中间的消息传递处理都是靠广播接收者了。