Activity系列知识-Activity的生命周期方法
大师兄刚学Android那会儿，有个比较要好的同事，一位广东的小伙子（后来不曾想，我孩子居然会和他同名，哈哈，感觉占了大便宜），平时我们在一起，除了开开车，吃吃瓜，也会探讨Android相关的知识。当时我们讨论到Activity时，他说这和Android的硬件啥啥的有关，作为一个个文科生，根本就不知道该怎么接话，只能一个劲儿的点头说是，其实内心对自己是鄙视的，硬件都不知道，电阻都忘了，还来做Android开发，这不是鄙视广大的Androider吗？
当时想想也是，根本没有深入思考过，为什么Activity会有生命周期，或者说根本就没有发挥自己作为一个文科生的本色，讲好Activity相关的事儿。多年以后，当大师兄再去思考这个问题时，我们已经各安天涯了，当对android的那份炙热的心，却还是一样的火热！
首先，Activity之所以会有生命周期，这个和Android的生态有关，或者说和手机相关的移动设备是相关，可以说这是移动设备的出身条件啊，这个无法改变。Android作为移动设备的一员，它存在自身的一些特点，比如那么是6寸的屏幕，也不可能一下子全部展示出一个有几百个条目的列表数据。当用户在切换不同的App时，注定有些App在当前的情况下是可见的，有些App只能退到后台，由可见变成不可见，在切换应用的时候，也就是在各种可见和不可见之间在切换。如果每次去切换，都需要重新的唤醒Activity，换句话时，每次切换的时候，都需要系统来创建一个新的组件吗？
如果是这样的，估计用户得炸了。频繁的切换，就意味着等待，这种体验该是多么的糟心，估计千万个草泥马都涌上了心头。那么这个时候为了应对这种状况（从开发的角度来看，这是活生生的改变不了的需求啊），如果不实现它，产品经理会放过广大的Android人么？（唉，又借机黑了一把产品，这个不是天敌的天敌！）Activity的生命周期方法，就是在诸如此类的客观条件下诞生了，这是现实的需要，不是产品瞎BB的结果！那么一起来看看Activity都有哪些可爱的生命周期方法。
1.当页面变得可见时的生命周期方法--onStart()
比如一个App在启动时，即当前的Activity对于用户来说，是可以被看到的，那么这个时候，Activity的 onStart()就会被调用，它用来告诉系统，当前的Activity已经可以被用户看到了，如果要准备做点啥，就可以准备做了，至于是不是真的要做点啥，这个得用户说了算。
2.用户在页面上点点，会调用的生命周期方法--onResume(）
当用户真的在Activity上点点点的时候，就和Activity中的元素发生了交互，这个时候会调用一个新的方法onResume()，这个方法会告诉系统，用户正在和页面发生交互。
3.当页面只是可见，不能交互，调用的生命周期方法-onPause()
onPause()被调用时Activity可能依然对用户全部可见，如多窗口模式下没有获得焦点时，可见一个View只所以能获取到焦点，是因为焦点已经在当前的Activity中时，才有可能获取到。如果是在onResume()中申请资源在onPause()中释放资源的是不可取的。比如上面提到的多窗口模式下，假如用户操作一番后，有回到当前的Activity，并且在页面可见时，获取的资源，就是页面中要展示的东西，那就尴尬了，这就产生了一个大BUG。
4.页面完全不可见时，会调用的生命周期方法-onStop()
停停停，别演了！这里有问题，我不想看了，这就好比在演戏，突然被导演喊停，不想看到演员，那么这个时候就得停止演戏了，得Stop。在Activity中，当onStop()被调用时，表示用户（其实也是一个导演，不想看到当前的页面，或者说有了新的操作）做了新的操作， Activity已经完全不可见了。那么这个时候就应该少做消耗资源的事情了。比如停止包含动画在内的UI 更新，尽量释放暂时不用的资源，停止视频、音频的播放等。对于stopped 的Activity，系统随时可能杀掉包含这个Activity的进程，如果没有合适的机会可以在onStop()中保存一些数据。
上面说的是用户的操作让页面完全不可见，并且最终被销毁了。但如果是因为Android自身的原因呢，比如Android的内存不够，当前的Activity由于不可见被杀死了，那该如何应对？
这个时候，系统就有专门的方法，记录这个实例曾经存在过，在用户重新回到这个Activity时，第一步是重新创建一个新的实例，然后将之前保存好的实例状态传递给这个新的实例。记住这是保存实例状态的，也就是保存Activity在被杀死前，是处在那种生命周期的方法中。
4.1恢复Activity的实例状态
这个系统之前保存好的用来恢复Activity状态的数据被称为实例状态（Instance state）。
实例状态如何存储数据呢？是以键值对的形式存储在Bundle 对象中的，实际上在上节谈到Intent时就提到过Bundle，它本质上是一个Map。
这个实例状态对象，会恢复新创建的（实际上存在过的Activity）Activity的一些值，那么会恢复哪些？
很可惜，默认系统只能自动存储和恢复有ID 的 View 的简单状态（如输入框的文本，滚动控件的滚动位置，实际上，也只能恢复这些带有ID的对象），对于那些复杂的数据，即使能存储起来，要恢复的话，也会出问题，记住，这些数据的操作是在主线程中的，如果在主线程中序列化或反序列化Bundle对象既消耗时间又消耗系统进程内存，搞不好还会发生程序无响应。因此最好只用它保存简单、轻量的数据。
4.2.onSaveInstanceState（）被调用的时机
对于Build.VERSION_CODES.P及之后的系统该方法会在onStop()之后随时可能被调用，对于之前的系统该方法会在onStop()之前随时被调用。
4.3 onRestoreInstanceState()被调用的时机
如果有实例状态要恢复那么一定会在onStart()之后被调用。
4.4onActivityResult()被调用时机
onResume()之前。目标Activity没有显式返回任何结果或者崩溃，那么resultCode 就会是RESULT_CANCELED。
5.一些要特别注意的点
在保存实例状态之后恢复实例状态之前的一些操作（如Fragment 的事务提交）是不允许的，Android 系统会不惜一切代价避免状态丢失。
Activity#onCreate()方法中提交事务是没问题的，因为你可以在里面根据保存的状态重建，但是在其他生命周期回调中提交事务就可能会出现问题了。FragmentActivity#onPostResume()方法中调用了FragmentActivity#onResumeFragments()方法完成其关联的所有的Fragment 的 resume 事件的分发，执行完这两个方法 Activity 和它关联的所有 Fragment 才算真正的 resumed，才算恢复了状态，才可以提交事务，所以如果非要在Activity#onCreate()之外的回调中提交事务那么FragmentActivity#onPostResume()和FragmentActivity#onResumeFragments()是最好的选择。避免在异步的回调中提交事务: 因为在这些回调执行的时候很难确定当前 Activity 正处于什么生命周期状态，而且突然地提交事务更改大量 UI 会产生糟糕的用户体验，所以如果遇到这样的场景可以考虑换一种实现思路，不要随便使用commitAllowingStateLoss()方法
如非必须，避免使用多层嵌套的Fragment，否则容易出现 Bug。原来多层嵌套Fragment是不被提倡的，这种嵌套在Activity被意外回收时，要恢复到之前的状态，是非常困难的，这些并不是程序无法控制，而是Android本身所存在的客观事实!
Activity的生命周期方法，远不止这些，特别是依赖于Activity的Fragment，就更不一样了。但大师兄相信，上面所说到的一些方法，才是一些特定情况下会发生的，也是必须注意的点。那么Android系统，又是如何管理Activity的，特别是一个App中会有很多Activity的情况，为了避免意外的发生，或者说为了更好的管理Activity。下节中，大师兄同样会以一个文科生的视角来解读系统是如何管理Activity的知识！
