Activity、Bundle、请求码与结果码、Intent、广播、服务 （二）

 

Intent（意图）

Android基本的设计理念是鼓励减少组件间的耦合，因此Android提供了Intent (意图) ，Intent提供了一种通用的消息系统，它允许在你的应用程序与其它的应用程序间传递Intent来执行动作和产生事件。使用Intent可以激活Android应用的三个核心组件：活动、服务和广播接收器。

Intent可以划分成显式意图和隐式意图。

Intent一旦发出，Android都会准确找到想匹配的一个或多个Activity，Service或BroadcastReceiver作为响应。所以不同的Intent消息不会出现重叠：BroacastIntent消息只会发送给BroadcastReceiver，而绝不可能给Activity或Service。有startActivity()传递的消息也只可能发给Activity，由startService传送的Intent只可能发送给Service。

显式意图：调用Intent.setComponent()或Intent.setClass()方法指定了组件名或类对象的Intent为显式意图，显式意图明确指定了Intent应该传递给哪个组件。

隐式意图：没有调用Intent.setComponent()或Intent.setClass()方法指定组件名或类对象的Intent为隐式意图。 Android系统会根据隐式意图中设置的动作(action)、类别(category)、数据（URI和数据类型）找到最合适的组件来处理这个意图。实际上，一个隐式Intent请求要能通能够传递给目标组件，必须通过这三个方面的检测。如果任何一方面不匹配，Android都不会将该隐式Intent传递给目标组件。

对于隐式意图，Android是怎样寻找到这个最合适的组件呢？记的前面我们在定义活动时，指定了一个intent-filter，Intent Filter（意图过滤器）其实就是用来匹配隐式Intent的，当一个意图对象被一个意图过滤器进行匹配测试时，只有三个方面会被参考到：动作、数据（URI以及数据类型）和类别。

动作测试（Action test）

  一个意图对象只能指定一个动作名称，而一个过滤器可能列举多个动作名称。如果意图对象或过滤器没有指定任何动作，结果将如下：

• 如果过滤器没有指定任何动作，那么将阻塞所有的意图，因此所有的意图都会测试失败。没有意图能够通过这个过滤器。 

• 另一方面，只要过滤器包含至少一个动作，一个没有指定动作的意图对象自动通过这个测试

类别测试（Category test）

对于一个能够通过类别匹配测试的意图，意图对象中的类别必须匹配过滤器中的类别。这个过滤器可以列举另外的类别，但它不能遗漏在这个意图中的任何类别。

原则上一个没有类别的意图对象应该总能够通过匹配测试，而不管过滤器里有什么。大部分情况下这个是对的。但有一个例外，Android把所有传给startActivity()的隐式意图当作他们包含至少一个类别："android.intent.category.DEFAULT" （CATEGORY_DEFAULT常量）。 因此，想要接收隐式意图的活动必须在它们的意图过滤器中包含"android.intent.category.DEFAULT"。（带"android.intent.action.MAIN"和"android.intent.category.LAUNCHER"设置的过滤器是例外）

数据测试（Data test）

<data>元素指定了希望接受的Intent请求的数据URI和数据类型，URI被分成三部分来进行匹配：scheme，authority和path。

当一个意图对象中的URI被用来和一个过滤器中的URI比较时，比较的是URI的各个组成部分。例如，如果过滤器仅指定了一个scheme，所有该scheme的URIs都能够和这个过滤器相匹配；如果过滤器指定了一个scheme、主机名但没有路经部分，所有具有相同scheme和主机名的URIs都可以和这个过滤器相匹配，而不管它们的路经；如果过滤器指定了一个scheme、主机名和路经，只有具有相同scheme、主机名和路经的URIs才可以和这个过滤器相匹配。当然，一个过滤器中的路径规格可以包含通配符，这样只需要部分匹配即可。

数据测试同时比较意图对象和过滤器中指定的URI和数据类型。规则如下：

a. 一个既不包含URI也不包含数据类型的意图对象仅在过滤器也同样没有指定任何URIs和数据类型的情况下才能通过测试。

b. 一个包含URI但没有数据类型的意图对象仅在它的URI和一个同样没有指定数据类型的过滤器里的URI匹配时才能通过测试。这通常发生在类似于mailto:和tel：这样的URIs上：它们并不引用实际数据。

c. 一个包含数据类型但不包含URI的意图对象仅在这个过滤器列举了同样的数据类型而且也没有指定一个URI的情况下才能通过测试。

d. 一个同时包含URI和数据类型（或者可从URI推断出数据类型）的意图对象可以通过测试，如果它的类型和过滤器中列举的类型相匹配的话。如果它的URI和这个过滤器中的一个URI相匹配或者它有一个内容content:或者文件file: URI而且这个过滤器没有指定一个URI，那么它也能通过测试。换句话说，一个组件被假定为支持content:和file: 数据如果它的过滤器仅列举了一个数据类型。

 

显示意图和隐式意图在什么时候使用？

显示意图：软件内部组件间通信

隐式意图：软件之间通信

Activity生命周期

Activity有三个状态：

 当它在屏幕前台时（位于当前任务堆栈的顶部），它是激活或运行状态。它就是响应用户操作的Activity。 

 当它失去焦点但仍然对用户可见时（如右图），它处于暂停状态。即在它之上有另外一个Activity。这个Activity也许是透明的，或者没有完全覆盖全屏，所以被暂停的Activity仍对用户可见。暂停的Activity仍然是存活状态（它保留着所有的状态和成员信息并保持和窗口管理器的连接），但系统处于极低内存时仍然可以杀死这个Activity。 

 完全被另一个Activity覆盖时则处于停止状态。它仍然保留所有的状态和成员信息。然而对用户是不可见的，所以它的窗口将被隐藏，如果其它地方需要内存，则系统经常会杀死这个Activity。 

当Activity从一种状态转变到另一种状态时，会调用以下保护方法来通知这种变化：

void onCreate(Bundle savedInstanceState)

void onStart()

void onRestart()

void onResume()

void onPause()

void onStop()

void onDestroy()

这七个方法定义了Activity的完整生命周期。实现这些方法可以帮助我们监视其中的三个嵌套生命周期循环：

 Activity的完整生命周期自第一次调用onCreate()开始，直至调用onDestroy()为止。Activity在onCreate()中设置所有“全局”状态以完成初始化，而在onDestroy()中释放所有系统资源。例如，如果Activity有一个线程在后台运行从网络上下载数据，它会在onCreate()创建线程，而在 onDestroy()销毁线程。 

 Activity的可视生命周期自onStart()调用开始直到相应的onStop()调用结束。在此期间，用户可以在屏幕上看到Activity，尽管它也许并不是位于前台或者也不与用户进行交互。在这两个方法之间，我们可以保留用来向用户显示这个Activity所需的资源。例如，当用户不再看见我们显示的内容时，我们可以在onStart()中注册一个BroadcastReceiver来监控会影响UI的变化，而在onStop()中来注消。onStart() 和 onStop() 方法可以随着应用程序是否为用户可见而被多次调用。 

 Activity的前台生命周期自onResume()调用起，至相应的onPause()调用为止。在此期间，Activity位于前台最上面并与用户进行交互。Activity会经常在暂停和恢复之间进行状态转换——例如当设备转入休眠状态或者有新的Activity启动时，将调用onPause() 方法。当Activity获得结果或者接收到新的Intent时会调用onResume() 方法。

 

注（另外在Activity中的两个重要方法）：

/*使用onSaveInstanceState(Bundle outState)方法以前保存的状态重新初始化某个活动时会调用该方法

 。默认实现会还原用户界面的状态*/

@Override

protected void onRestoreInstanceState(Bundle savedInstanceState) {

Log.i(TAG, "onRestoreInstanceState()");

super.onRestoreInstanceState(savedInstanceState);

}

/*Android调用该方法的作用是让活动可以保存每个实例的状态，如光标在文本字段中的位置。

通常你无需复写该方法，因为该方法的实现会自动保存所有用户界面控制的状态。*/

@Override

protected void onSaveInstanceState(Bundle outState) {

Log.i(TAG, "onSaveInstanceState()");

super.onSaveInstanceState(outState);

}