Activity-基础梳理

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

你可能感兴趣的:(Activity-基础梳理)