ANDROID的Activity的生命周期
2009-09-16 11:20
525 查看
注
意到在Activity的API中有大量的onXXXX形式的函数定义,除了我们前面用到的onCreate以外,还有onStart,onStop以及
onPause等等。从字面上看,它们是一些事件回调,那么次序又是如何的呢?其实这种事情,自己做个实验最明白不过了。在做这个实验之前,我们先得找到
在Android中的Log是如何输出的。
显然,我们要用的是android.util.log类,这个类相当的简单易用,因为它提供的全是一些静态方法:
Log.v(String tag, String msg); //VERBOSE
Log.d(String tag, String msg); //DEBUG
Log.i(String tag, String msg); //INFO
Log.w(String tag, String msg); //WARN
Log.e(String tag, String msg); //ERROR
前面的tag是由我们定义的一个标识,一般可以用“类名_方法名“来定义。
输出的LOG信息,如果用Eclipse+ADT开发,在LogCat中就可以看到,否则用adb logcat也行,不过我是从来都依赖于IDE环境的。
好了,现在我们修改前面的HelloThree代码:
public
void
onStart()
...
{
super
.onStart();
Log.v(TAG,
"
onStart
"
);
}
public
void
onStop()
...
{
super
.onStop();
Log.v(TAG,
"
onStop
"
);
}
public
void
onResume()
...
{
super
.onResume();
Log.v(TAG,
"
onResume
"
);
}
public
void
onRestart()
...
{
super
.onRestart();
Log.v(TAG,
"
onReStart
"
);
}
public
void
onPause()
...
{
super
.onPause();
Log.v(TAG,
"
onPause
"
);
}
public
void
onDestroy()
...
{
super
.onDestroy();
Log.v(TAG,
"
onDestroy
"
);
}
public
void
onFreeze(Bundle outState)
...
{
super
.onFreeze(outState);
Log.v(TAG,
"
onFreeze
"
);
}
在HelloThreeB中也同样增加这样的代码,编译,运行一下,从logcat中分析输出的日志。
在启动第一个界面Activity One时,它的次序是:
onCreate (ONE) - onStart (ONE) - onResume(ONE)
虽然是第一次启动,也要走一遍这个resume事件。然后,我们点goto跳到第二个Activity Two中(前一个没有关闭),这时走的次序是:
onFreeze(ONE) - onPause(ONE) - onCreate(TWO) - onStart(TWO) - onResume(TWO) - onStop(ONE)
说明,第二个Activity Two在启动前,One会经历一个:冻结、暂停的过程,在启动Two后,One才会被停止?
然后,我们再点back回到第一个界面,这时走的次序是:
onPause(TWO) - onActivityResult(ONE) - onStart(ONE) - onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO)
说明,返回时,Two没有经历冻结就直接暂停了,在One接收参数,重启后,Two就停止并被销毁了。
最后,我们点一下Exit退出应用,它的次序是:
onPause(ONE) - onStop(ONE) - onDestroy(ONE)
说明如果我们用了finish的话,不会有freeze,但是仍会经历pause - stop才被销毁。
这
里有点疑问的是:为什么回来时先是Start才是Restart?可是文档中的图上画的却是先restart再start的啊?不过,后面的表格中的描述
好象是正确的,start后面总是跟着resume(如果是第一次)或者restart(如果原来被stop掉了,这种情况会在start与resume
中插一个restart)。
下面不跑例子了,看看文档吧。
1.Android用Activity Stack来管理多个Activity,所以呢,同一时刻只会有最顶上的那个Activity是处于active或者running状态。其它的Activity都被压在下面了。
2.
如果非活动的Activity仍是可见的(即如果上面压着的是一个非全屏的Activity或透明的Activity),它是处于paused状态的。在
系统内存不足的情况下,paused状态的Activity是有可被系统杀掉的。只是不明白,如果它被干掉了,界面上的显示又会变成什么模样?看来下回有
必要研究一下这种情况了。
3.几个事件的配对可以比较清楚地理解它们的关系。Create与Destroy配成一对,叫entrie
lifetime,在创建时分配资源,则在销毁时释放资源;往上一点还有Start与Stop一对,叫visible
lifetime,表达的是可见与非可见这么一个过程;最顶上的就是Resume和Pause这一对了,叫foreground
lifetime,表达的了是否处于激活状态的过程。
4.因此,我们实现的Activity派生类,要重载两个重要的方法:onCreate()进行初始化操作,onPause()保存当前操作的结果。
除了Activity Lifecycle以外,Android还有一个Process Lifecycle的说明:
在内存不足的时候,Android是会主动清理门户的,那它又是如何判断哪个process是可以清掉的呢?文档中也提到了它的重要性排序:
1.
最容易被清掉的是empty
process,空进程是指那些没有Activity与之绑定,也没有任何应用程序组件(如Services或者IntentReceiver)与之绑定
的进程,也就是说在这个process中没有任何activity或者service之类的东西,它们仅仅是作为一个cache,在启动新的
Activity时可以提高速度。它们是会被优先清掉的。因此建议,我们的后台操作,最好是作成Service的形式,也就是说应该在Activity中
启动一个Service去执行这些操作。
2.接下来就是background
activity了,也就是被stop掉了那些activity所处的process,那些不可见的Activity被清掉的确是安全的,系统维持着一个
LRU列表,多个处于background的activity都在这里面,系统可以根据LRU列表判断哪些activity是可以被清掉的,以及其中哪一
个应该是最先被清掉。不过,文档中提到在这个已被清掉的Activity又被重新创建的时候,它的onCreate会被调用,参数就是onFreeze时
的那个Bundle。不过这里有一点不明白的是,难道这个Activity被killed时,Android会帮它保留着这个Bundle吗?
3.然后就轮到service process了,这是一个与Service绑定的进程,由startService方法启动。虽然它们不为用户所见,但一般是在处理一些长时间的操作(例如MP3的播放),系统会保护它,除非真的没有内存可用了。
4.接着又轮到那些visible activity了,或者说visible process。前面也谈到这个情况,被Paused的Activity也是有可能会被系统清掉,不过相对来说,它已经是处于一个比较安全的位置了。
5.最安全应该就是那个foreground activity了,不到迫不得已它是不会被清掉的。这种process不仅包括resume之后的activity,也包括那些onReceiveIntent之后的IntentReceiver实例。
在Android
Application的生命周期的讨论中,文档也提到了一些需要注意的事项:因为Android应用程序的生存期并不是由应用本身直接控制的,而是由
Android系统平台进行管理的,所以,对于我们开发者而言,需要了解不同的组件Activity、Service和IntentReceiver的生
命,切记的是:如果组件的选择不当,很有可能系统会杀掉一个正在进行重要工作的进程。
意到在Activity的API中有大量的onXXXX形式的函数定义,除了我们前面用到的onCreate以外,还有onStart,onStop以及
onPause等等。从字面上看,它们是一些事件回调,那么次序又是如何的呢?其实这种事情,自己做个实验最明白不过了。在做这个实验之前,我们先得找到
在Android中的Log是如何输出的。
显然,我们要用的是android.util.log类,这个类相当的简单易用,因为它提供的全是一些静态方法:
Log.v(String tag, String msg); //VERBOSE
Log.d(String tag, String msg); //DEBUG
Log.i(String tag, String msg); //INFO
Log.w(String tag, String msg); //WARN
Log.e(String tag, String msg); //ERROR
前面的tag是由我们定义的一个标识,一般可以用“类名_方法名“来定义。
输出的LOG信息,如果用Eclipse+ADT开发,在LogCat中就可以看到,否则用adb logcat也行,不过我是从来都依赖于IDE环境的。
好了,现在我们修改前面的HelloThree代码:
public
void
onStart()
...
{
super
.onStart();
Log.v(TAG,
"
onStart
"
);
}
public
void
onStop()
...
{
super
.onStop();
Log.v(TAG,
"
onStop
"
);
}
public
void
onResume()
...
{
super
.onResume();
Log.v(TAG,
"
onResume
"
);
}
public
void
onRestart()
...
{
super
.onRestart();
Log.v(TAG,
"
onReStart
"
);
}
public
void
onPause()
...
{
super
.onPause();
Log.v(TAG,
"
onPause
"
);
}
public
void
onDestroy()
...
{
super
.onDestroy();
Log.v(TAG,
"
onDestroy
"
);
}
public
void
onFreeze(Bundle outState)
...
{
super
.onFreeze(outState);
Log.v(TAG,
"
onFreeze
"
);
}
在HelloThreeB中也同样增加这样的代码,编译,运行一下,从logcat中分析输出的日志。
在启动第一个界面Activity One时,它的次序是:
onCreate (ONE) - onStart (ONE) - onResume(ONE)
虽然是第一次启动,也要走一遍这个resume事件。然后,我们点goto跳到第二个Activity Two中(前一个没有关闭),这时走的次序是:
onFreeze(ONE) - onPause(ONE) - onCreate(TWO) - onStart(TWO) - onResume(TWO) - onStop(ONE)
说明,第二个Activity Two在启动前,One会经历一个:冻结、暂停的过程,在启动Two后,One才会被停止?
然后,我们再点back回到第一个界面,这时走的次序是:
onPause(TWO) - onActivityResult(ONE) - onStart(ONE) - onRestart(ONE) - onResume(ONE) - onStop(TWO) - onDestroy(TWO)
说明,返回时,Two没有经历冻结就直接暂停了,在One接收参数,重启后,Two就停止并被销毁了。
最后,我们点一下Exit退出应用,它的次序是:
onPause(ONE) - onStop(ONE) - onDestroy(ONE)
说明如果我们用了finish的话,不会有freeze,但是仍会经历pause - stop才被销毁。
这
里有点疑问的是:为什么回来时先是Start才是Restart?可是文档中的图上画的却是先restart再start的啊?不过,后面的表格中的描述
好象是正确的,start后面总是跟着resume(如果是第一次)或者restart(如果原来被stop掉了,这种情况会在start与resume
中插一个restart)。
下面不跑例子了,看看文档吧。
1.Android用Activity Stack来管理多个Activity,所以呢,同一时刻只会有最顶上的那个Activity是处于active或者running状态。其它的Activity都被压在下面了。
2.
如果非活动的Activity仍是可见的(即如果上面压着的是一个非全屏的Activity或透明的Activity),它是处于paused状态的。在
系统内存不足的情况下,paused状态的Activity是有可被系统杀掉的。只是不明白,如果它被干掉了,界面上的显示又会变成什么模样?看来下回有
必要研究一下这种情况了。
3.几个事件的配对可以比较清楚地理解它们的关系。Create与Destroy配成一对,叫entrie
lifetime,在创建时分配资源,则在销毁时释放资源;往上一点还有Start与Stop一对,叫visible
lifetime,表达的是可见与非可见这么一个过程;最顶上的就是Resume和Pause这一对了,叫foreground
lifetime,表达的了是否处于激活状态的过程。
4.因此,我们实现的Activity派生类,要重载两个重要的方法:onCreate()进行初始化操作,onPause()保存当前操作的结果。
除了Activity Lifecycle以外,Android还有一个Process Lifecycle的说明:
在内存不足的时候,Android是会主动清理门户的,那它又是如何判断哪个process是可以清掉的呢?文档中也提到了它的重要性排序:
1.
最容易被清掉的是empty
process,空进程是指那些没有Activity与之绑定,也没有任何应用程序组件(如Services或者IntentReceiver)与之绑定
的进程,也就是说在这个process中没有任何activity或者service之类的东西,它们仅仅是作为一个cache,在启动新的
Activity时可以提高速度。它们是会被优先清掉的。因此建议,我们的后台操作,最好是作成Service的形式,也就是说应该在Activity中
启动一个Service去执行这些操作。
2.接下来就是background
activity了,也就是被stop掉了那些activity所处的process,那些不可见的Activity被清掉的确是安全的,系统维持着一个
LRU列表,多个处于background的activity都在这里面,系统可以根据LRU列表判断哪些activity是可以被清掉的,以及其中哪一
个应该是最先被清掉。不过,文档中提到在这个已被清掉的Activity又被重新创建的时候,它的onCreate会被调用,参数就是onFreeze时
的那个Bundle。不过这里有一点不明白的是,难道这个Activity被killed时,Android会帮它保留着这个Bundle吗?
3.然后就轮到service process了,这是一个与Service绑定的进程,由startService方法启动。虽然它们不为用户所见,但一般是在处理一些长时间的操作(例如MP3的播放),系统会保护它,除非真的没有内存可用了。
4.接着又轮到那些visible activity了,或者说visible process。前面也谈到这个情况,被Paused的Activity也是有可能会被系统清掉,不过相对来说,它已经是处于一个比较安全的位置了。
5.最安全应该就是那个foreground activity了,不到迫不得已它是不会被清掉的。这种process不仅包括resume之后的activity,也包括那些onReceiveIntent之后的IntentReceiver实例。
在Android
Application的生命周期的讨论中,文档也提到了一些需要注意的事项:因为Android应用程序的生存期并不是由应用本身直接控制的,而是由
Android系统平台进行管理的,所以,对于我们开发者而言,需要了解不同的组件Activity、Service和IntentReceiver的生
命,切记的是:如果组件的选择不当,很有可能系统会杀掉一个正在进行重要工作的进程。
相关文章推荐
- 【Android Training - 01】详解Activity生命周期 [ Lesson 1 - 启动与销毁Activity ]
- Android开发艺术探索---第一章activity生命周期之自我总结
- Android Fragment---与Activity生命周期的协调
- android的activity生命周期问题
- Android 学习记录3 -Activity 的生命周期
- Android 面试之横竖屏切换的Activity生命周期
- 深入剖析Android四大组件(一)——Activity生命周期具体解释
- 一个demo,帮助您加深理解和记忆android activity 生命周期
- Android activity的生命周期
- android82 启动Actvity和Activity的生命周期
- Android Activity 生命周期的透彻理解
- 诠释Android中Activity的生命周期
- android手机横竖屏切换时Activity的生命周期:
- Android-Activity生命周期 基本方法的作用
- android Activity Lifecycle即生命周期
- Android Activity& service&Broadcast receiver 生命周期
- Android Activity的生命周期和启动模式(一)——典型情况下的生命周期分析
- 【Android Activity相关】Activity的生命周期问题总结
- android虚席总结(16.08.26)Activity的生命周期
- [Android]Activity生命周期