four types of application components:Activities,Services,Content providers,Broadcast receivers

官方原文：ttp://eloper.android.com/guide/components/fundamentals.html

百度解释:http://zhidao.baidu.com/question/252842928.html

Activities:activity是Android程序与用户交互的窗口，activity特像网站的一个页面。比如一个email应用程序应该有一个activity显示一个新邮件的列表，另一个activity为了读邮件。尽管这两个activity工作在同一个email应用程序中但是他们各自的相对于另一个activity是独立的。因此另一个应用程序可以从这个email应用程序的任何一个activity开始（在这个email应用程序允许的情况下）。比如，为了使用户共享一张图片，相机应用程序可以调email应用程序的新邮件activity。从视觉效果来看，一个Activity占据当前的窗口，响应所有窗口事件，具备有控件，菜单等界面元素。从内部逻辑来看，Activity需要为了保持各个界面状态，需要做很多持久化的事情，还需要妥善管理生命周期，和一些转跳逻辑。对于开发者而言，就需要派生一个Activity的子类，然后埋头苦干上述事情。

Services：该组件运行于后台，用于执行长时间的操作或者执行远程的工作。service不提供用户界面。比如，当用户在使用另一个应用程序时，一个service可以在后台播放music，或者可以在网络上获取数据而不堵塞用户的交互活动（activity）。另一方面，一个activity可以开始于service并运行或者绑定这个交互。

服务，从最直白的视角来看，就是剥离了界面的Activity，它们在很多Android的概念方面比较接近，都是封装有一个完整的功能逻辑实现，只不过Service不抛头露脸，只是默默无声的做坚实的后盾。但其实，换个角度来看，Android中的服务，和我们通常说的Windows服务，Web的后台服务又有一些相近，它们通常都是后台长时间运行，接受上层指令，完成相关事务的模块。用运行模式来看，Activity是跳，从一个跳到一个，呃...，这有点像模态对话框（或者还像web页面好了...），给一个输入（抑或没有...），然后不管不顾的让它运行，离开时返回输出（同抑或没有...）。而Service不是，它是等，等着上层连接上它，然后产生一段持久而缠绵的通信，这就像一个用了Ajax页面，看着没啥变化，偷偷摸摸的和Service不知眉来眼去多少回了。但和一般的Service还是有所不同，Android的Service和所有四大组件一样，其进程模型都是可以配置的，调用方和发布方都可以有权利来选择是把这个组件运行在同一个进程下，还是不同的进程下。这句话，可以拿把指甲刀刻进脑海中去，它凸显了Android的运行特征。如果一个 Service，是有期望运行在于调用方不同进程的时候，就需要利用Android提供的RPC机制，为其部署一套进程间通信的策略。（转自百度，比较形象）

Content providers：一个Content provider 管理了一组应用程序的共享数据。你可以在文件系统中存数据，你的应用程序可以访问SQLite数据库，web，或者任何其他持久性的存储位置。通过content provider，其他应用程序可以查询甚至修改数据（前提是content provider允许）。例如，一个Android系统提供一个content provider来管理用户联系人信息。因此，任何有权限的应用程序都可以查询这个content provider（如ContactsContrac.Data）部分信息来读写一个人的信息。

conteng provider也可以写入和读取数据到你的应用程序是私有的而不是共享的。比如，记事本应用程序使用content provider保存笔记。

Broadcast receivers：该组件用于响应全系统的广播通知。许多广播从系统中发起，比如，广播通知显示屏已经关闭、电池容量过低或者一张图片被截取。应用程序也可以发起广播，比如，让其他应用程序知道一些数据已经被下载到设备和允许使用。尽管broadcast receiver不显示用户窗口，它们可能创建一个状态栏通知来提醒用户。通常情况下，一个broadcast receiver对其他组件来说是一个“网关”和做一些小事，比如，它可能会启动一个服务在这个事件上执行一些工作。