API拾遗录之Activity

1. Using Intent filters

在manifest.xml文件中必须为每一个activity申明一个<activity>元素标签。在这个标签中可以指定多个intent filters。它的作用是申明如何让其它应用组件启动它。

当我们创建一个应用程序时，最基础的那个activity包含的一个intent filter总是申明了该activity对"main"方法的反馈结果，并且需要放置在"launcher" category中。如下所示：下面的这个<intent-filter>是所有应用程序有且只有一个的配置。

<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

<action>标签指定了这个activity是该应用的main入口。<category>标签表明这个activity需要放置在系统的launcher中。允许用户启动该activity。

2. Starting an activity for a result

有时候我们想从启动的那个activity中获取一个result。我们可以使用startActivityForResult()方法代替常规的startActivity()方法。并且需要实现onActivityResult()回调函数。当启动的那个activity运行结束时，它返回一个Intent到我们的onActivityResult()回调中。例如：

private void pickContact() {
    // Create an intent to "pick" a contact, as defined by the content provider URI
    Intent intent = new Intent(Intent.ACTION_PICK, Contacts.CONTENT_URI);
    startActivityForResult(intent, PICK_CONTACT_REQUEST);
}

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    // If the request went well (OK) and the request was PICK_CONTACT_REQUEST
    if (resultCode == Activity.RESULT_OK && requestCode == PICK_CONTACT_REQUEST) {
        // Perform a query to the contact's content provider for the contact's name
        Cursor cursor = getContentResolver().query(data.getData(),
        new String[] {Contacts.DISPLAY_NAME}, null, null, null);
        if (cursor.moveToFirst()) { // True if the cursor is not empty
            int columnIndex = cursor.getColumnIndex(Contacts.DISPLAY_NAME);
            String name = cursor.getString(columnIndex);
            // Do something with the selected contact's name...
        }
    }
}

上例中，resultCode检查启动要求是否成功，成功返回RESULT_OK。接着检查startActivityForResult中的要求返回的结果(本例中为PICK_CONTACT_REQUEST)是否可知，即requestCode与之是否匹配。然后处理需要返回的数据。从上述代码可知，对数据的操作都是在onActivityResult()中完成的，和启动的那个activity一点关系没有。这里的data(intent)由启动的那个activity的setResult(PICK_CONTACT_REQUEST, intent)传回。

这里的逻辑是：

Intent intent = new Intent(...)指定Intent数据要求。

startActivityForResult(intent, RequestCode)启动第二个activity

Bundle bundle = new Bundle(); intent.putExtra(bundle);

setResult(RequestCode, intent)传回数据

onActivityForResult(...)接收数据并处理数据。

具体的个函数的用法可参照相关API文档。

Managing the Activity Lifecycle

一个activity的声明周期受到与之相关的其它activities和它的任务栈的影响。一个activity本质上有三中存活状态。

Resumed                      activity处于屏幕前台并拥有用户焦点(这也常认为是运行态)

Paused                          其它activity处于屏幕前台并拥有用户焦点，而这个activity也是可见的。这意味着，前台的activity在这个activity之上，并且是部分透明的没有覆盖全部屏幕空间。暂停态的activity是完全激活的状态(activity对象保留在内存中，并保存这所有的状态和成员信息，并同window manager保持联系)，但是系统内存很低的情况下会杀死这个activity。

Stopped                          activity被完全覆盖，处于后台。停止态的activity仍然是激活的(activity对象仍保留在内存中，它也还保存着状态和成员信息，但是不受window manager控制)。然后，它永不可见，并且随时都可能被系统回收内存而杀死对象。

当一个activity处于暂停态或停止态时，系统可以通过finish()回收该对象或直接杀死进程。当重新打开该activity时，此时就需要重新创建该对象。

结合上图和前面的三态可知，一个activity对象完全杀死是在onDestroy()被回调之后或者在onPause()和onStop()中因内存过低被系统回收了该对象。

Saving activity state

上文提到，当一个activity处于暂停态或者停止态时，activity的状态信息和成员信息仍存活于内存中。这意味着，activity中的任何改变都会被保存下来，当activity回到前台时，这些改变仍然存在。

然而当系统摧毁activity回收内存后，activity对象便不存在了，所以系统不能简单的回复它的状态。当用户导航回到它时，系统需要重新创建这个activity对象。然而，用户不需要知道系统已经摧毁了它并重建它，用户只想知道它已经恢复到了之前的状态即可。在这种情况下，我们需要保证activity的重要信息和activity状态被完全恢复而增加了一个额外的回调方法允许用户保存activity的状态和成员信息：它就是onSaveInstanceState()。

系统在activity即将被摧毁之前调用onSaveInstanceState()。系统传递一个Bundle数据到这个方法，在这个Bundle数据中我们可以保存任何状态信息。然后，当系统杀死应用程序进程后导航回这个activity时，系统重新创建这个activity并把这个Bundle数据传递给onCreate()和onRestoreInstanceState()。无论使用这两个方法中的哪一个，都可以从Bundle中取出保存信息恢复activity之前的状态。

这段文字的关键在于，activity被完全杀死后获取到杀死之前的信息。如果我们想保存这样的信息，这需要在onSaveInstanceState()回调中保存数据到Bundle中。

注意：我们不能保证在activity被摧毁之前一定会回调onSaveInstanceState()方法。因为存在这不想要保存信息的情况(例如当用户使用Back按钮离开activity时，这就明确的告诉了我们用户要关闭这个activity)。如果系统调用了onSaveInstanceState()，一定是在onStop()之前，也有可能在onPause()之前。

然而，即使我们不做任何事，不实现onSaveInstanceState()，activity的一些状态信息也会被activity类的缺省onSaveInstanceState()实现保存。典型的情况是，缺省实现在布局中为每个View调用它们自己的onSaveInstanceState()方法。这意味着，允许每个view提供相关信息并保存它们。几乎所有的android framework提供的widget都实现了这个方法，所以任何视图可见性的改变在activity重建时，UI都会自动保存和恢复这些信息。比如，EditText会保存用户输入的文本信息，CheckBox会保存是否Checked信息。我们要作的唯一工作就是为每个我们需要保存状态的widget提供一个特殊的ID(android:id属性)，系统会保存它们的信息。Activity的界面是由一个一个widget组成的，因此缺省情况下，系统会调用每个widget自身的onSaveInstanceState()方法保存信息。这就是每次回调onCreate()时，相应的各个widget的信息仍然如初的原因。我们如果有额外的信息需要保存则需要我们自己在activity中调用onSaveInstanceState()方法实现。例如，在activity生命周期中我们需要保持成员值(UI相关的成员值可能已经被UI widget保存，但是保存UI成员的变量值在缺省情况下是没有被保存的)。

缺省情况下，onSaveInstanceState()会保存UI状态，所以我们在实现onSaveInstanceState()时必须现调用super的该函数。同样的对于onRestoreInstanceState()也一样。

注意：因为不能保证一定会调用onSaveInstanceState()函数，所以我们应该使用它来保存activity的transient state(UI状态)——永远都不要使用它来保存persistent data。确认代之的是，当用户要离开activity时，我们应该使用onPause()函数来保存persistent数据(比如需要保存到database中的数据)

一个好的测试应用程序保存状态能力的方法是旋转设备，当用户屏幕横竖切换时都会摧毁和重建activity。

Handling configuration changes

一些设备配置信息会在运行时进行改变(比如屏幕方向，是否使用键盘和语言)。当改变出现时，安卓系统重建正在运行的这个activity(系统调用onDestroy()紧接着立即调用onCreate())。

一个好的方式处理这样的activity restart是如上文所述的使用onSaveInstanceState()和onRestoreInstanceState()(或者onCreate())保存和存储activity状态。具体信息可参见http://developer.android.com/guide/topics/resources/runtime-changes.html