应用程序基础之02-应用程序组件篇（1）
应用程序基础之02-应用程序组件篇（一）
应用程序基础之02-应用程序组件篇（一）
应用程序组件是一个Android应用程序关键的基石。每一个组件都是系统进入应用程序的不同入口点。对用户而言，并不是所有的组件都是实际入口点，它们之间有一些依赖，但是每一个组件的存在都有它自己的入点，并且扮演着一个特定的角色---每一个组件都是独一无二的构建模块，帮助定义你的应用的整体行为。
有四个不同类型的应用组件。每一种类型都完成特定的目的，每种类型都有一个不同的生命周期来定义该组件的创建和销毁。
一个activity显示一个屏幕，代表一个用户接口（视图）。例如，一个邮件应用会有一个activity展示新邮件列表，一个activity用来写邮件，另一个activity用于读取邮件。在一个邮件应用中尽管所有的activity一起工作形成一个完整的用户体验，但是每一个activity之间却是相互独立的。正因为如此，一个不同的应用可以启动该邮件应用的这些activity中的任意一个（前提是邮件应用允许）。例如，一个照相应用可以启动邮件的一个activity来发送新的邮件，来让用户分享一个图片。
每一个activity被作为Activity类的子类来实现，你可以在开发指南中的“Activitys”章节了解到更多。
Services
service是运行在后台的组件，它一般执行长时间的操作或者执行远程进程工作。一个service不提供用户接口（视图）。例如，当用户在使用另一个不同应用时，一个service可能在后台播放音乐;或者在不妨碍用户互动的情况下通过网络抓取数据。其它的组件（比如一个activity）可以启动一个service，让它单独运行或者绑定到这个activity以便进行交互操作。
每一个service被作为Service类的子类来实现，你可以在开发指南中的“Service”章节中了解到更多。
Content providers
content provider管理一组共享的应用程序数据集。你可以将数据储存在文件系统、SQLite数据库、网络或者任何其它你的应用可以访问到的持久存储位置。通过content provider，其它的应用可以请求甚至编辑共享的数据（前提是content provider允许）。例如，Android系统提供一个content provider来管理用户的通讯信息。因此，任何拥有合理权限的应用都可以查询content provider的部分数据来读取和写入关于某个人的信息。
content provider对于读取或者写入应用的私有不分享数据也是非常有帮助的，例如Note Pad应用便是用一个content provider来保存笔记的。
每一个content provider被作为ContentProvider类的子类来实现，并且必须实现一组标准的APIs以便使其它应用执行交换操作。关于content provider更多的信息，请看开发指南中“Content Provider”章节。
Broadcast receivers
broadcast receivers是一个响应系统广播通知的组件。很多广播都来源于系统，例如屏幕关闭、电量过低或者图片被捕获等。应用程序也能发起广播，例如让其他应用程序知道一些数据已经下载到设备，并且它们可以使用了。尽管broadcast receivers不能显示用户接口(视图)，但是当一个广播事件发生时它们可以创建一个状态栏通知来提醒用户。但是大多数情况下，一个broadcast receivers 仅仅是进入其他应用组件的一个途径，并且只做极少量的工作。例如，一个broadcase receivers会基于某个事件启动一个service来完成相应的工作（译者注：整个过程中broadcast receivers所做的仅仅是启动一个service，大部分工作却由service完成）。
broadcast receivers作为Broadcast receivers类的子类被实现，每一个广播作为一个Intent对象传递。更多详细信息请关注BroadcastReceivers类。
应用程序基础之02-应用程序组件篇（一）
应用程序组件是一个Android应用程序关键的基石。每一个组件都是系统进入应用程序的不同入口点。对用户而言，并不是所有的组件都是实际入口点，它们之间有一些依赖，但是每一个组件的存在都有它自己的入点，并且扮演着一个特定的角色---每一个组件都是独一无二的构建模块，帮助定义你的应用的整体行为。
有四个不同类型的应用组件。每一种类型都完成特定的目的，每种类型都有一个不同的生命周期来定义该组件的创建和销毁。
下面是这四种类型组件的介绍：
Activitys一个activity显示一个屏幕，代表一个用户接口（视图）。例如，一个邮件应用会有一个activity展示新邮件列表，一个activity用来写邮件，另一个activity用于读取邮件。在一个邮件应用中尽管所有的activity一起工作形成一个完整的用户体验，但是每一个activity之间却是相互独立的。正因为如此，一个不同的应用可以启动该邮件应用的这些activity中的任意一个（前提是邮件应用允许）。例如，一个照相应用可以启动邮件的一个activity来发送新的邮件，来让用户分享一个图片。
每一个activity被作为Activity类的子类来实现，你可以在开发指南中的“Activitys”章节了解到更多。
Services
service是运行在后台的组件，它一般执行长时间的操作或者执行远程进程工作。一个service不提供用户接口（视图）。例如，当用户在使用另一个不同应用时，一个service可能在后台播放音乐;或者在不妨碍用户互动的情况下通过网络抓取数据。其它的组件（比如一个activity）可以启动一个service，让它单独运行或者绑定到这个activity以便进行交互操作。
每一个service被作为Service类的子类来实现，你可以在开发指南中的“Service”章节中了解到更多。
Content providers
content provider管理一组共享的应用程序数据集。你可以将数据储存在文件系统、SQLite数据库、网络或者任何其它你的应用可以访问到的持久存储位置。通过content provider，其它的应用可以请求甚至编辑共享的数据（前提是content provider允许）。例如，Android系统提供一个content provider来管理用户的通讯信息。因此，任何拥有合理权限的应用都可以查询content provider的部分数据来读取和写入关于某个人的信息。
content provider对于读取或者写入应用的私有不分享数据也是非常有帮助的，例如Note Pad应用便是用一个content provider来保存笔记的。
每一个content provider被作为ContentProvider类的子类来实现，并且必须实现一组标准的APIs以便使其它应用执行交换操作。关于content provider更多的信息，请看开发指南中“Content Provider”章节。
Broadcast receivers
broadcast receivers是一个响应系统广播通知的组件。很多广播都来源于系统，例如屏幕关闭、电量过低或者图片被捕获等。应用程序也能发起广播，例如让其他应用程序知道一些数据已经下载到设备，并且它们可以使用了。尽管broadcast receivers不能显示用户接口(视图)，但是当一个广播事件发生时它们可以创建一个状态栏通知来提醒用户。但是大多数情况下，一个broadcast receivers 仅仅是进入其他应用组件的一个途径，并且只做极少量的工作。例如，一个broadcase receivers会基于某个事件启动一个service来完成相应的工作（译者注：整个过程中broadcast receivers所做的仅仅是启动一个service，大部分工作却由service完成）。
broadcast receivers作为Broadcast receivers类的子类被实现，每一个广播作为一个Intent对象传递。更多详细信息请关注BroadcastReceivers类。
转载请注明：大飞_Rflyee:http://blog.csdn.net/rflyee/article/details/14046397