初识Android应用程序的五大基本组件

5 Basic Components



1.


Activity

2.


Service

3.


Broadcast Receiver

4.


Content Provider

5.


Intent



Activity


——


应用表示层（

基类
Activity

）




应用程序中的每个屏幕都是通过继承和扩展基类
Activity

来实现的。



同一应用中的每个
Activity

是相互独立的。程序启动后显示的第一幅画面是应用程序的第一个
Activity

（默认窗口），而后可以根据需要从这个
Activity

启动另一个新的
Activity

。


Activity

利用
View

来实现应用中的
GUI

（用户直接通过
GUI

和应用程序做交互）。
Activity

窗口内的可见内容通过基类
View

提供。使用
Activity.setContentView()

方法设置当前
Activity

中的
View

对象。

l


每个
View

对象控制着窗口内的一个矩形空间；

l


View

是一种层次化结构，
Parent View

中的布局属性会被子
View

继承；

l


位于
View

层次关系最底层的子
View

对象所代表的矩形空间就是跟用户进行交互的地方



Activity

状态回调：

l


onCreate

l


onStart

l


onRestart

l


onResume

l


onPause

l


onStop

l


onDestroy



Service




——


没有可见的用户界面，但能够长时间运行于后台（

基类
Service

）




运行于应用程序进程的主线程中，因此
Service

不会阻塞其他组件和用户界面。


Service

是不能自己启动的，必须通过
Context

对象（如一个
Activity

）调用
startService

或
bindService

方法来启动（用这两种方法启动的
Service

的生命周期不同）。

1.


调用
startService

方法

a)


若
Service

没有启动，则首先会调用该
Service

的
onCreate

方法，然后再调用
onStart

方法。

b)


若
Service

已经启动，则会直接调用
onStart

方法

c)


该方法启动的
Service

，可以通过
Context

对象调用
stopService

来关闭，也可以通过
Service

自身调用
stopSelf()

或
stopSelfResult()

来关闭，关闭之前调用
onDestory

方法。

2.


调用
bindService

方法，使当前
Context

对象通过一个
ServiceConnection

的对象绑定到所指定的
Service

a)


若
Service

没有启动，则首先会调用该
Service

的
onCreate

方法初始化启动，然后调用
Service

的
onBind

方法初始化绑定。

b)


如果绑定
Service

的
Context

对象被销毁时，被绑定的
Service

也会调用
onUnbind

和
onDestroy

方法停止运行

c)


注意：
BroadcastReceiver

是不能绑定服务的。

d)


一个绑定
Service

的
Context

对象还可以通过
unbindService()

来取消对服务的绑定。

e)


取消时，
Service

会调用
unbind

方法，若
Service

是通过
bindService

来启动的，还会调用
onDestroy

方法来停止服务。


Service

状态回调：

l


onCreate

l


onStart

l


onBind

l


onRebind

l


onUnbind

l


onDestroy



Broadcast Receiver




——


用户接收广播通知的组件（

基类
BroadcastReceiver

）



Android

中的广播要么来自于系统，要么来自普通应用程序。

很多事件都可能导致系统广播，如手机所在时区发生变化，电池电量低，用户改变系统语言设置等。

来自普通应用程序，如一个应用程序通知其他应用程序某些数据已经下载完毕。



为了响应不同的事件通知，应用程序可以注册不同的
Broadcast Receiver

。所有的
Broadcast Receiver

都继承自基类
BroadcastReceiver

。


BroadcastReceiver

自身并不实现图形用户界面，但是当它收到某个通知后，
BroadcastReceiver

可以启动
Activity

作为响应，或者通过
NotificationMananger

提醒用户。


BroadcastReceiver

是对发送出来的
Broadcast

进行过滤接收并响应的一类组件。





发送
Broadcast

信息

1.


把要发送的信息和用于过滤得信息
(

如
Action

、
Category)

装入一个
Intent

对象

2.


调用
Context.

sendBroadcast()

、
sendOrderBroadcast()

、
sendStickyBroadcast()

方法，广播该
Intent

对象

3.


使用
sendBroadcast()

或
sendStickyBroadcast()

方法发出去的
Intent

，所有满足条件的
BroadcastReceiver

都会随机地执行其
onReceive()

方法；

4.


而
sendOrderBroadcast()

发出去的
Intent

，会根据
BroadcastReceiver

注册时
IntentFilter

设置的优先级的顺序来执行，相同优先级的
BroadcastReceiver

则是随机执行

5.


sendStickyBroadcast()

方法主要的不同是，
Intent

在发送后一直存在，并且在以后调用
registerReceiver()

注册相匹配的
Intent

时会把这个
Intent

直接返回。

6.


若在使用
sendBroadcast()

方法时指定了接收的权限，这只有在
AndroidManifest.xml

中用
<uses-permission>

标签声明了拥有此权限的
BroadcastReceiver

才会有可能接收到发送来
Broadcast

。

7.


若在注册
BroadcastReciever

时，指定了可接收的
Broadcast

的权限，则只有在包内的
AndroidManifest.xml

中用
<uses-permission>

标签声明了，拥有此权限的
Context

对象所发送的
Broadcast

才有可能被这个
BroadcastReceiver

所接收。

接收
Broadcast

消息

1.


继承
BroadcastReceiver

类，并实现
onReceive

方法

2.


注册
Broadcast Receiver

（有
2

种方法：一种方法是，静态地在
AndroidManifest.xml

中用
<receiver>

标签声明，并在标签内用
<intent-filter>

标签设置过滤器；

另一种方法，动态地在代码中先定义并设置好一个
IntentFilter

对象，然后再需要注册的地方调用
Context.registerReceiver()

方法）

（取消注册时，调用
Context.unregisterReceiver()

方法）



Content Provider




——


为解决应用程序间数据通信、共享的问题（

基类
ContentProvider

）




在
Android

中，每个应用程序都是用自己的用户
ID

并在自己的进程中运行。这样的好处是，可以有效地保护系统及应用程序，避免被其他不正常德应用程序所影响，每个进程都拥有独立的进程地址空间和虚拟空间。


Content Provider

可以将应用程序特定的数据提供给另一个应用程序使用。其数据存储方式可以是
Android

文件系统、
SQLite

数据库或者其他合理的方式。



当数据需要在应用程序间共享时，我们就可以利用
ContentProvider

为数据定义一个
URI

。之后，其他应用程序对数据进行查询或者修改时，只需要从当前上下文对象获得一个
ContentResolver,

然后传入响应的
URI

就可以了。


Content Provider

继承自基类
ContentProvider

，并且实现了一组标准接口。通过这组接口，其他应用程序能对数据进行读写和存储。然而，需要使用数据的应用程序并不是直接调用这组方法，而是通过调用
ContentResolver


对象的方法来完成。
ContentResolver

对象可以与任意
ContentProvider

通信。



要为当前应用程序的私有数据定义
URI

，就需要专门定义一个继承自
ContentProvider

的类，然后根据不同的操作调用的方法去实现这些方法的功能。


ContentResolver

类为应用程序提供了接入
Content

机制的方法。要构造一个
ContentResolver

对象可以为构造方法
ContentResolver(Context context)

传入一个
Context

对象，也可以直接通过
Context

对象调用
getContentResolver()

方法获得

——

有的
ContentResolver

对象后，就可以通过调用其
query()

、
insert()

、
update()

等方法来对数据进行操作了。



一旦需要以上
4

种
Android

应用程序基本组件完成请求，
Android

会首先确认该组件所在进程是否运行，如果没有运行，
Android

将先启动进程，同时确认被请求组件的实例是否存在，否则将创建一个新的组件实例。



Intent


——



连接组件的纽带




以上
4

种基本组件中，除了
Content Provider

是通过
Content Resolver

激活外，其他
3

种组件
Activity

、
Service

和
Broadcast Receiver

都是由
Intent

异步消息激活的。


Intent

在不同的组件之间传递消息，将一个组件的请求意图传给另一个组件。因此，
Intent

是包含具体请求信息的对象。

针对不同的组件，
Intent

所包含的消息内容有所不同，且不同组件的激活方式也不同，

且不同类型组件有传递
Intent

的不同方式。


Intent

是一种运行时绑定（
runtime binding

）机制，它能够在程序运行的过程中连接两个不同的组件。通过
Intent

，你的程序可以向
Android

表到某种请求或者意愿，
Android

会根据意愿的内容选择适当的组件来处理请求。

l


激活一个新的
Activity

，或者让一个现有的
Activity

执行一个新的操作，可以通过调用如下两种方法
(

这两汇总方法需要传入的
Intent

参数称为
Activity Action Intent)

：

1.


Context.startActivity()

2.


Activity.startActivityForResult()

l


启动一个新的服务，或者向一个已有的服务传递新的指令，可以调用如下两种方法：

1.


Context.startService()

2.


Context.bindService()

l


发送广播
Intent(

所有已注册的拥有与之相匹配
IntenFilter

的
BroadcastReceiv

就会被激活
)

，可以调用如下三种方法：

1.


Context.sendBroadcast()

2.


Context.sendOrderBroadcast()

3.


Context.sendStickBroadcast()

Intent

一旦发出，
Android

都会准确找到相匹配的一个或多个
Activity

、
Service

或
BroadcastReceiver

作响应。所以，不同类型的
Intent

消息不会出现重叠，
BroadcastIntent

消息只会发送给
BroadcastReceiver

，而绝不可能发送给
Activity

或
Server

。有
startActivity()

传递的消息也只可能发送给
Activity

，由
startService()

传递的
Intent

只可能发送给
Service

。




Intent

对象抽象地描述了执行操作，
Intent

的主要组成部分；

1.


目标组件名称。
[

可选项
]

a)


组件名称是一个
ComponentName

对象，是目标组件类名和目标组件所在应用程序包的组合

b)


组件中的包名不一定要和
manifes

文件中包名完全匹配

c)


如果
Intent

消息中指明了目标组件的名称，这就是一个显示消息，
Intent

会传递给指明的组件。

d)


如果目标组件名称并没有指定，
Android

则通过
Intent

内的其他信息和已注册的
IntentFilter

的比较来选择合适的目标组件

2.


Action [

隐式比较
]

a)


描述
Intent

所触发动作的名字字符串。

b)


理论上
Action

可以为任何字符串，而与
Android

系统应用有关的
Action

字符串以静态字符串常量的形式定义在了
Intent

类中。

3.


Data [

隐式比较
]

a)


描述
Intent

要操作的的数据的
URI

和数据类型。

b)


正确设置
Intent

的数据对于
Android

寻找系统中匹配
Intent

请求的组件很重要。

4.


Category [

隐式比较
]

a)


是对被请求组件的额外描述信息。

b)


Android

也在
Intent

类中定义了一组静态字符串常量表示
Intent

不同的类别。

5.


Extra

a)


当我们使用
Intent

连接不同组件时，有时需要在
Intent

中附加额外的信息，以便将数据传递给目标
Activity

。

b)


Extra

用键值对结构保存在
Intent

对象当中，
Intent

对象通过调用方法
putExtras()

和
getExtras()

来存储和获取
Extra

c)


Extra

是以
Bundle

对象的形式来保存的，
Bundle

对象提供了一系列
put

和
get

方法来设置、提取相应键值信息。

d)


在
Intent

类中同样为
Android

系统应用的一些
Extra

的键值定义了静态字符串常量。

6.


Flag



决定
Intent

目标组件的因素：

n


在显式
Intent

消息中，决定目标组件的唯一要素就是组件名称（不用再定义其他
Intent

内容）

n


而隐式
Intent

消息中，由于没有目标组件名称，所以必须由
Android

系统帮助应用程序寻找与
Intent

请求意图最匹配的组件。

n


隐式
Intent

消息中目标组件具体选择方法是：
android

将
Intent

的请求内容和一个叫做
IntentFilter

的过滤器比较，
IntentFilter

中包含系统中所有可能的待选组件。如果
IntentFilter

中某一个组件匹配隐式
Intent

请求内容，那么
Android

就选择该组件作为该隐式
Intent

的目标组件。



IntenFilter



应用程序的组件为了告诉
Android

自己能响应、处理哪些隐式
Intent

请求，可以声明一个甚至多个
IntentFilter

。



每个
IntentFilter

描述该组件所能响应
Intent

请求的能力

——

组件希望接收什么类型的请求行为，什么类型的请求数据。



隐式
Intent

和
IntentFilter

进行比较时的三要素：
Action

、
Data

、
Category

。



一个隐式
Intent

请求要能够传递给目标组件，必需通过以上三个方面的检查。如果任何一方面不匹配，
Android

都不会将该隐式
Intent

传递给目标组件。


<intent-filter>


<action android:name=””/>


<category android:name=””/>


<data android:type=”” android:scheme=”” android:authority=”” android:path=””/>


</intent-filter>

1.


动作测试

a)


一条
<intent-filter>

中至少应该包含一个
<action>,

否则任何
Intent

请求都不能和该
<intent-filter>

匹配。

b)


如果
IntentFilter

中没有包含任何
Actino

类型，那么无论什么
Intent

请求都无法和这条
IntentFilter

匹配。

c)


如果
Intent

请求中没有设定
Action

类型，那么只要
IntentFilter

中包含有
Action

类型，这个
Intent

请求将顺利通过
IntentFilter

的测试。

2.


类别测试

a)


只有当
Intent

请求中所有的
Category

与组件中的某一个
IntentFilter

的
category

完全匹配，才会让该
Intent

请求通过测试，
IntentFilter

中的多余
category

声明并不会导致匹配失败。

b)


一个没有指定任何类别的
IntentFilter

仅仅只会匹配没有设置类别的
Intent

请求。

3.


数据测试

a)


<data>

元素指定了希望接受的
Intent

请求的数据
URI

和数据类型：
URI

被分成三部分类进行匹配，
scheme

、
authority

和
path.

b)


使用
setData

设定的
Intent

请求的
URI

数据类型和
scheme

，必须与
IntentFilter

中指定的一致

若
IntentFilter
中还指定了
authority
或
path
，他们也需要相匹配才会通过测试。