Android 中activity的启动方式和一些特定场景的生命周期

好奇怪，做android这么久了，到今天caif才发现自己把Activity的启动方式和特定情景下的生命周期没有彻底的gaom搞明白，简直无语啦！

很简单的问题都不好意思说了，不过还是拉出来给自己长点记性吧。

一、首先说说activity的生命周期吧，我们都知道activity有以下几种生命zho周期，分别是下图所示：

Android 中activity的启动方式和一些特定场景的生命周期_第1张图片

相信老铁们这些都是我的前辈，我就特定说一下我的理解吧!

首先打开一个新的activity实例的时候，系统会依次调用

onCreate（） -> onStart() -> onResume() 然后开始running

　　running的时候被覆盖了（从它打开了新的activity或是被锁屏，但是它依然在前台运行，此刻的activity失去了jiao焦点但是依然可见），调用onPause();

　该方法执行activity暂停，通常用于提交未保存的更改到持久化数据，停止动画和其他的东西。但这个activity还是完全活着（它保持所有的状态和成员信息，并保持连接到窗口管理器）

接下来它有三条出路 ①用户返回到该activity就调用onResume()方法重新running

②用户回到桌面或是打开其他activity，就会调用onStop()进入停止状态（保留所有的状态和成员信息，对用户不可见）

③系统内存不足，拥有更高限权的应用需要内存，那么该activity的进程就可能会被系统回收。（回收onPause()和onStop()状态的activity进程）要想重新打开就必须重新创建一遍。

如果用户返回到onStop()状态的activity（又显示在前台了），系统会调用

onRestart() -> onStart() -> onResume() 然后重新running

在activity结束（调用finish ()）或是被系统杀死之前会调用onDestroy()方法释放所有占用的资源。

activity生命周期中三个嵌套的循环

activity的完整生存期会在 onCreate() 调用和 onDestroy() 调用之间发生。　
activity的可见生存期会在 onStart() 调用和 onStop() 调用之间发生。系统会在activity的整个生存期内多次调用 onStart() 和onStop()，因为activity可能会在显示和隐藏之间不断地来回切换。　
activity的前后台切换会在 onResume() 调用和 onPause() 之间发生。因为这个状态可能会经常发生转换，为了避免切换迟缓引起的用户等待，这两个方法中的代码应该相当地轻量化。

每次面试时候总会被问到横竖屏切换时activity走了那些生命周期，这种问题很简单但是就是回答不正确，我嚼着还是给自己列举一下比较靠谱。

我们新建一个activit 它的生命周期就是正常的周期：

onCreate-->
onStart-->
onResume-->

当我们按下ctr+f12后将屏幕qieh切换成横屏时，我们发现shuc输出的生命周期分别是：

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->，你会惊讶的发现它会先保存现在的状态，然后销毁在重新创建一个activity,当我们在切换成竖屏时发现走了和上面一样的生命周期，然而，我们会发现当我们在配置文件中修改AndroidManifest.xml，把该Activity添加 android:configChanges="orientation"，在切换成横屏时此时输出的生命周期是如下所示：
onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->

这时如果我们再按一次ctr+f12切换回去时我们会发现如下的shen生命周期会shuc输出：

onSaveInstanceState-->
onPause-->
onStop-->
onDestroy-->
onCreate-->
onStart-->
onRestoreInstanceState-->
onResume-->
onConfigurationChanged--> 会发现多了这一行，别慌更奇怪的还在后面了，当我们把AndroidManifest.xml中的属性android:configChanges="orientation" 改成 android:configChanges="orientation|keyboardHidden"，再进行横竖屏的切换时，你会发现只会输出onConfigChanged
onConfigurationChanged-->，再怎么切换都不会了走别的生命周期了，所以横竖屏qieh切换时不一定都是先销毁原有的activ再创建，还是要看我们的配置文件怎么设置了，记忆力不好，留给自己吧，反正也闲着。

二、其次我还想絮叨的就是activity的启动模式了，如果你是大牛请走开！

"standard" （默认模式）

　　当通过这种模式来启动Activity时,　Android总会为目标 Activity创建一个新的实例,并将该Activity添加到当前Task栈中。这种方式不会启动新的Task,只是将新的 Activity添加到原有的Task中。　　　

"singleTop"

　　该模式和standard模式基本一致,但有一点不同:当将要被启动的Activity已经位于Task栈顶时,系统不会重新创建目标Activity实例,而是直接复用Task栈顶的Activity。

"singleTask"

　　Activity在同一个Task内只有一个实例。　　　　如果将要启动的Activity不存在,那么系统将会创建该实例,并将其加入Task栈顶；　

　　如果将要启动的Activity已存在,且存在栈顶,直接复用Task栈顶的Activity。　

　　如果Activity存在但是没有位于栈顶,那么此时系统会把位于该Activity上面的所有其他Activity全部移出Task,从而使得该目标Activity位于栈顶。

生命周期：同SingleTop 模式中的情况一同样。仅仅会又一次回调Activity中的 onNewIntent方法

举例：此时Activity 栈中以此有A、B、C三个Activity。此时C处于栈顶，启动模式为SingleTask 模式。

情况一：在C Activity中加入点击事件，须要跳转到还有一个同类型的C Activity。结果是直接用栈顶的C Activity。情况二：在C Activity中加入点击事件，须要跳转到还有一个A Activity。

结果是将A Activity上面的B、C所有销毁，使A Activity成为栈顶。

"singleInstance"

　　无论从哪个Task中启动目标Activity,只会创建一个目标Activity实例且会用一个全新的Task栈来装载该Activity实例（全局单例）.

　　如果将要启动的Activity不存在,那么系统将会先创建一个全新的Task,再创建目标Activity实例并将该Activity实例放入此全新的Task中。

具有此模式的Activity仅仅能单独位于一个任务栈中。

这个经常使用于系统中的应用，比如Launch、锁屏键的应用等等，整个系统中仅仅有一个！所以在我们的应用中一般不会用到。了解就可以。

举例：比方 A Activity是该模式，启动A后。系统会为它创建一个单独的任务栈，由于栈内复用的特性。兴许的请求均不会创建新的Activity，除非这个独特的任务栈被系统销毁。

　如果将要启动的Activity已存在,那么无论它位于哪个应用程序,哪个Task中;系统都会把该Activity所在的Task转到前台,从而使该Activity显示出来，我之前没有很好的理解singleTask和singleInstance,今天补上吧，其他两种大家都比我好，就不提了

Android 中activity的启动方式和一些特定场景的生命周期

Android 中activity的启动方式和一些特定场景的生命周期

更多相关文章

随机推荐