interView - Activity生命周期，启动模式

Activity生命周期？

onCreate()：进行布局的初始化，当需要用到数据库时对数据进行绑定等操作，

onStart()：当activity对用户即将可见的时候调用。

onResume()：当activity将要与用户交互时调用此方法,此时activity在activity栈的栈顶,用户输入已经 可以传递给它

onRestart():当activity从停止状态重新启动时调用

onPause()：当系统要启动一个其他的activity时调用（其他的activity显示之前），这个方法被用来提交那些持久数据的改变、停止动画、
和其他占用 CPU资源的东西。当程序再次运行时这些信息不会丢失。由于下一个activity在这个方法返回之前不会resumed，
所以实现这个方法时代码执行要尽可能快。
onStop()：当activity不可见时调用

onDestory()：当activity不需要时或进程终止时调用，用于释放资源,

当Activity上面有另外一个Activity，使它失去了焦点但仍然对用户可见时,
比如弹出个dialog,此Activity不会被调用onStop

当第一个Activity第一次被启动时会执行
onCreate() -> onStart() -> onResume()
当按下BACK键应用程序结束会调用
onPause()->onStop()->onDestory()
当按下HOME键会调用
onPause()->onStop()
当我们再次启动Activity应用程序时会执行
onRestart()->onStart()->onResume()

从第二个activity返回到第一个activity时，第二个activity会执行onPause，然后第一个activity会执行onStart,onResume，最后第二个activity会执行onStop和onDestroy。

onSaveInstanceState和onRestoreInstanceState触发的时机?

onSaveInstanceState  Activity即将移出栈顶保留UI状态时调用此方法
onRestoreInstanceState  onCreate完成后被调用，用来回复UI状态

onRestoreInstanceState方法，我 们可以清楚地知道当某个activity（假定为activity A）显示在当前task的最上层时，其onSaveInstanceState方法会在什么时候被执行，有这么几种情况： 
1、当用户按下HOME键时。这是显而易见的，系统不知道你按下HOME后要运行多少其他的程序，自然也不知道activity A是否会被销毁，故系统会调用onSaveInstanceState，让用户有机会保存某些非永久性的数据。以下几种情况的分析都遵循该原则 
2、长按HOME键，选择运行其他的程序时。 
3、按下电源按键（关闭屏幕显示）时。 
4、从activity A中启动一个新的activity时。 
5、屏幕方向切换时，例如从竖屏切换到横屏时。在屏幕切换之前，系统会销毁activity A，在屏幕切换之后系统又会自动地创建activity A，所以onSaveInstanceState一定会被执行 
总而言之，onSaveInstanceState的调用遵循一个重要原则，即当系统“未经你许可”时销毁了你的activity，则 onSaveInstanceState会被系统调用，这是系统的责任，因为它必须要提供一个机会让你保存你的数据（当然你不保存那就随便你了）。 


不要将这个方法和activity生命周期回调如onPause()或onStop()搞混淆了，onPause()在activtiy被放置到背景或者 自行销毁时总会被调用，onStop()在activity被销毁时被调用。一个会调用onPause()和onStop()，但不触发 onSaveInstanceState的例子是当用户从activity B返回到activity A时：没有必要调用B的onSaveInstanceState(Bundle)，此时的B实例永远不会被恢复，因此系统会避免调用它。一个调用 onPause()但不调用onSaveInstanceState的例子是当activity B启动并处在activity A的前端：如果在B的整个生命周期里A的用户界面状态都没有被破坏的话，系统是不会调用activity A的onSaveInstanceState(Bundle)的。 


至于onRestoreInstanceState方法，需要注意的是，onSaveInstanceState方法和 onRestoreInstanceState方法“不一定”是成对的被调用的，onRestoreInstanceState被调用的前提 是，activity A“确实”被系统销毁了，而如果仅仅是停留在有这种可能性的情况下，则该方法不会被调用，例如，当正在显示activity A的时候，用户按下HOME键回到主界面，然后用户紧接着又返回到activity A，这种情况下activity A一般不会因为内存的原因被系统销毁，故activity A的onRestoreInstanceState方法不会被执行 

另外，onRestoreInstanceState的bundle参数也会传递到onCreate方法中，你也可以选择在onCreate方法中做数据还原。

Activity启动模式？

Activity的四种启动模式：

    1. standard
        默认启动模式，每次激活Activity时都会创建Activity，并放入任务栈中。


    2. singleTop
        如果在任务的栈顶正好存在该Activity的实例， 就重用该实例，否者就会创建新的实例并放入栈顶(即使栈中已经存在该Activity实例，只要不在栈顶，都会创建实例)。

singleTop模式应用场景 ：
　　App程序中(或浏览器中)保存的书签，假如用户看到一个界面保存自己喜欢的标签，假如要保存10个，这个时候用户在返回键的时候，则会返回10次才能返回到App应用中， Android下singleTop 则解决该问题。

    3. singleTask
        如果在栈中已经有该Activity的实例，就重用该实例(会调用实例的onNewIntent())。重用时，会让该实例回到栈顶，因此在它上面的实例将会被移除栈。如果栈中不存在该实例，将会创建新的实例放入栈中。 

singleTask模式应用场景 ：
   最近研究android浏览器browser，这个BrowserActivity的launcherMode="singleTask"，因为browser不断地启动自己，所以要求这个栈中保持只能有一个自己的实例，就像别人总结的这样“注意：singleTask模式的Activity不管是位于栈顶还是栈底，再次运行这个Activity时，都会destory掉它上面的Activity来保证整个栈中只有一个自己，切记切记”这点是毋庸置疑的。


    4. singleInstance
        在一个新栈中创建该Activity实例，并让多个应用共享该栈中的该Activity实例。一旦该模式的Activity的实例存在于某个栈中，任何应用再激活改Activity时都会重用该栈中的实例，其效果相当于多个应用程序共享一个应用，不管谁激活该Activity都会进入同一个应用中。

应用场景:比如说有道词典,金山词典,通过抽屉的NotifityCation下拉后进入查词的
Activity,这个查词Activity要求是一个完全独立的Activity,与任何应用程序没有关系
整个手机里只有一个实例存在.  在全局的系统程序应用,达到节省内存使用的目的.

如前所述，“singleTask”或“singleInstance”模式的activity永远不会存在多于一个实例。所以实例将处理所有新的intent。一个“singleInstance”模式的activity永远保持在堆栈的顶部（因为它是那个堆栈中唯一的一个activity），所以它一直坚守在处理intent的岗位上。然而，对一个“singleTask”模式的activity来说，它上面可能有，也可能没有别的activity和它处于同一堆栈。在有的情况下，它就不在能够处理intent的位置上，则那个intent将被舍弃。（即便在intent被舍弃的情况下，它的抵达仍将使这个任务切换至前台，并一直保留）

横竖屏切换时候activity的生命周期?

1.不设置Activity的android:configChanges时,切屏会重新调用各个生命周期,切横屏时会执行一次,切竖屏时会执行两次. 
2.设置Activity的android:configChanges="orientation"时,切屏还是会重新调用各个生命周期,切横、竖屏时只会执行一次. 
3.设置Activity的android:configChanges="orientation|keyboardHidden"时,切屏不会重新调用各个生命周期,只会执行onConfigurationChanged方法.

onNewIntent什么时候被调用？

Activity设置了其它的启动模式(singleTop此Activity在顶端)后第二次进入此界面不会调用onCreate方法，而是调用onNewIntent。

Activity生命周期进程类型?

　　在Android系统中，即使不关掉程序，当应用程序处于某种进程类时，也有可能被系统kill掉。

　　Android系统通过运行机制，依照哪些画面或消息对使用者最重要以及当前内存使用状况，而做出是否kill Activity的决定。

　　foreground process（前景模式）是当前显示于手机屏幕上的应用程序画面，被定义为前景模式的进程，其中由onCreate()、onStart() 、onResume() 函数调用的Activity都会变成foreground process正在运行的Activity。

　　visible process（可见模式）：visible process最常发生的情况是当应用程序弹出对话框要与用户交互时，原应用程序就会变成透明（不可见）的，而对话窗口就会变成前景。

　　当对话窗口退出后，原应用程序马上就又变回原前景模式了。

　　在Activity窗口画面变为透明时，就会由onPause()函数掌控进入暂停状态。

　　当前景进程退出时，该Activity就会再度被拉到前景模式，由onResume() 函数唤醒。

　　background process是在Activity窗口画面被其他Activity完全盖掉，窗口画面已经完全看不见时，则会进入onStop()停止状态。

　　这种情况通常发生在两个不同的应用程序开启时，后开启的应用程序会覆盖掉原应用程序。


　　此时对background process Activity的处理有两种选择：一是直接被onDestroy()退出，该程序将完全关闭，无法再使用任何返回键回到该程序；另一个处理方式是当其他Activity需要内存时，这个background process会先被清除掉，按照LRU顺序释放出内存。

　　如果使用者再度浏览刚刚被清除掉的background process，则Android系统会自动再运行onCreate()重新启动该Activity，所以当系统需要内存时，就会暂时将背景进程清除，让它变成empty process（空白模式） ， 所以空白进程最重要的目的就是暂时释放出内存，直到使用者再度唤醒该empty process Activity时，才会将空白进程变成前景进程。

　　（Service相关）service process（服务模式进程）是由startService()所产生的，虽然服务进程有点类似背景进程在背景状态运行，但是它的运行等级和前景进程几乎一样高。

　　服务模式进程是持续运行的，虽然使用者看不到任何运行画面，Android系统不会自动关闭此类的服务进程，除非使用者自行关闭。这部分内容可在Service详解里面再讨论。