onPause()

系统将会调用这个方法作为用户离开activity的首先提示（虽然这并不意味着activity正在被销毁）。

这通常是你应该在用户会话之前提交并保存任何更改的时机。 （因为用户可能不会再回到这个activity）

.addView()

你也可以在activity代码里自己新建View，并通过插入子View到ViewGroup。 然后把这些视图的根视图传入到setContentView()。

onActivityResult(int requestCode, int resultCode, Intent data)

 第一步要判断请求是否被成功响应，通过判断resultCode 是不是RESULT_OK

管理activity的生命周期activity可能处于三种基本的状态

Resumed

 activity在屏幕的前台并且拥有用户的焦点。（这个状态有时也被叫做“running”。）

 Paused 

另一个activity在前台并拥有焦点，但是本activity还是可见的。 也就是说，另外一个activity覆盖在本activity的上面，并且那个activity是部分透明的或没有覆盖整个屏幕。 一个paused的activity是完全存活的（Activity 对象仍然保留在内存里，它保持着所有的状态和成员信息，并且保持与window manager的联接），但在系统内存严重不足的情况下它能被杀死。

 Stopped 

本activity被其它的activity完全遮挡住了（本activity目前在后台）。 一个stopped的activity也仍然是存活的（Activity 对象仍然保留在内存中，它保持着所有的状态和成员信息，但是不再与window manager联接了）。 但是，对于用户而言它已经不再可见了，并且当其它地方需要内存时它将会被杀死。 如果activity被paused或stopped了，则系统可以从内存中删除它，通过请求finish（调用它的 finish() 方法）或者直接杀死它的进程。 当这个activity被再次启动时（在被finish或者kill后），它必须被完全重建。

注意： activity被销毁之前，并不能确保每次都会调用 onSaveInstanceState() ，因为存在那些不必保存状态的情况（比如用户使用BACK键离开了你的activity，因为用户明显是关了这个activity）。 如果系统要调用 onSaveInstanceState() 方法，那么它通常会在 onStop() 方法之前并且可能是在 onPause() 之前调用。

不过，即使你没有实现 onSaveInstanceState() 方法，有些activity状态还是会通过 Activity 类缺省实现的onSaveInstanceState() 方法保存下来。特别的是，缺省为layout中的每个 View 实现了调用相应的onSaveInstanceState() 方法，这允许每一个view提供自己需被保存的信息。 几乎Android框架下所有的widget都会在适当的时候实现该方法，这样，任何UI上可见的变化都会自动保存下来，并在activity重建后自动恢复。 例如，EditText widget会保存所有用户已经输入的文本， CheckBoxwidget 也会保存是否被选中。你所要做的工作仅仅是为每一个你想要保存其状态的widget提供一个唯一的ID（就是 android:id 属性）。如果这个widget没有ID的话，系统是无法保存它们的状态的。

通过把android:saveEnabled 设置为"false",或者调用 setSaveEnabled() 方法，你也可以显式地阻止layout中的某个view保存状态。 通常不应该禁用保存，不过假如你需要恢复activity UI的各个不同的状态，也许可以这么做。

尽管缺省实现的 onSaveInstanceState() 方法会保存activity UI的有用信息，你仍然需要覆盖它来存入更多的信息。 例如，你可能需要保存在activity生命周期中改变的成员变量值（可能是关于UI恢复的值，但是默认情况下，存放这些UI状态的成员变量值是不会被恢复的）。

因为默认实现的 onSaveInstanceState() 方法已经帮你保存了一些UI的状态，所以如果你重写此方法是为了保存更多的状态信息，那么在执行自己的代码之前应该确保先调用一次父类的 onSaveInstanceState() 方法。同理，如果重写 onRestoreInstanceState() 的话，也应该调用一次父类的该方法，这样缺省的代码就能正常恢复view的状态了。

注意：因为 onSaveInstanceState() 并不保证每次都会被调用，所以你应该只用它来记录activity的一些临时状态信息（UI的状态）——千万不要用它来保存那些需要长久保存的数据。 替代方案是，你应该在用户离开activity的时候利用 onPause() 来保存永久性数据（比如那些需要存入数据库里的数据）。

一个检测应用程序状态恢复能力的好方法就是旋转设备，使得屏幕方向发生改变。 当屏幕的方向改变时，因为要换用符合实际屏幕参数的资源，系统会销毁并重建这个activity。 正因如此，你的activity能够在被重建时完整地恢复状态是非常重要的，因为用户会在使用应用程序时会频繁地旋转屏幕。

配置改动后的处理

设备的某些配置可能会在运行时发生变化（比如屏幕方向、键盘可用性以及语言）。 当发生这些变化时，Android会重建这个运行中的activity（系统会调用 onDestroy() ，然后再马上调用 onCreate() ）。这种设计有助于应用程序适用新的参数配置，通过把你预置的可替换资源（比如对应各种屏幕方向和尺寸的layout）自动重新装载进入应用程序的方式来实现。

多activity的合作

当activity启动另一个activity时，它俩生命周期的状态都会发生转换。 第一个activity paused并stopped（尽管它也可能不会被stopped，如果它仍然后台可见的话），而另一个activity是被created。 如果这两个activity共用了保存在磁盘或其它地方的数据，那么请明白：在第二个activity被created之前，第一个activity还没有完全被stopped，这点非常重要。 或多或少，第二个activity的启动进程与第一个activity的关闭进程在时间上会发生重叠。

from-->http://www.android-doc.com/guide/components/activities.html