1.Activity 与 Context 查看一下Activity的继承关系就可以发现，Activity最终是继承了Context.所以这意味着Actvitiy有Context的功能。 而Context是一个抽象类，它的实现在ContextImpl.但是Activity继承自ContextWrapper,ContextWrapper实现了接口但是只不过是把这些方法都转给了它的一个成员变量mBase来处理。而mBase在Activity当中是Activity.attach方法的时候执行才正式生效的。(Activity.attach发生在Activity启动阶段，在onCreate之前)。 Context在源码中的描述为： /** * Interface to global information about an application environment.  This is * an abstract class whose implementation is provided by * the Android system.  It * allows access to application-specific resources and classes, as well as * up-calls for application-level operations such as launching activities,  * broadcasting and receiving intents, etc. */ 总结为两点 1.获取信息 2.进行操作   所以说，作为一个Activity，它有上述两种功能，不过这并不是它的全部。   2.Activity 对象创建和销毁的时机 源码层面是在ActivityThread和Instrumentation类中。   这两个类都不能望文生义，ActivityThread既不是线程也不是Activity,它是管理应用端运行的类，负责与AMS进行交互。它管理着四大组件，也和应用进程的生死紧密关联。   关于Activity的启动流程网上讲述的有很多，读者可自行搜索，大体上是从 应用端A请求-AMS批准-应用端A或B执行启动。其中AMS也控制着Activity的生命周期。   如果你对AMS(ActivityManagerSrevice)不够了解，你可能会疑问为什么采用这种方式来进行操作。 我对此的理解是，一方面，Android是多任务的系统，每个应用进程当然都想在前台活动，但是前台只有一个，所以这就需要调度，保证一切都按照用户的想法来执行。AMS就是负责调度Activity状态的类，它管理了四大组件在前台或后台运行时的状态，在程序切换到后台后，后台的应用得到了通知就不会做一些用户不期待的事情。这样的话在合适时候有合适的回调(在Activity来看就是生命周期)，即方便了系统管理，友方便开发者进行开发。   但是坏处也有，就是开发者不了解Activity的运行机制，就有可能会犯下内存泄漏的错误。 Activity创建的时候开发者可以不用关心，但是销毁的时候是最值得注意的事情，虽然大家都清楚，在onDesstroy后，Activity就不再可用了，ActivityThread最终对其的处理也是把它(实际是ActivityClientRecord)从mActivities中移除出去.这个时机是在performDestroyActivity中(onDestroy就是在这个方法内部调用的)。   而启动的时机是在launch和relaunch中。     3.生命周期的方法被调用的时候应该做什么 常用的生命周期回调是     protected void onCreate(Bundle savedInstanceState);        protected void onStart();        protected void onRestart();        protected void onResume();        protected void onPause();        protected void onStop();        protected void onDestroy();   首先需要说明的是，上面的回调中只有onCreate和onDestroy 是在当前Activity实例中仅执行一次，别的都有可能随着AMS的管理执行多次。   所以在onCreate做的动作是必须而且仅需做一次的工作。onDestroy也是销毁剩下的所有与该Activity有直接依赖的资源。 而在onStart阶段，考虑到onStop的时机，你只需考虑在onStop需要释放什么资源，那么只要在onStart做对应的处理即可。   同样，onPause和onResume应该都不需要做太多的处理，因为对onPasue,AMS对其有限制，最多执行500ms,其中包括了跨进程调用和其它方法的开销。 如果你在500ms没有完成相应的工作，其实也不必担心，它(AMS)只不过强行结束了系统端的处理，马上进行新Activity的Resume调用。   而还有一些onRestart,onPostCreate等方法虽不太常用，但是只需要在ActivityThread或Instrumentation中找到对应的时机，相应应该不难理解。   4.保持数据 onSaveInstanceState 因为Activity的销毁时机是不确定的(几乎所有activity都有回到后台的可能性)，然后很有可能会面临销毁重建的过程。 正常的比如屏幕旋转，不正常的有被内存管理回收给处理的。 所以适当的保持数据可以保证Activity在回到前台的时候不会让用户感到困惑. 而onSaveInstance发生的时机有很多，因为它会在生命周期改变的时候调用.(pause stop)   而onRestoreInstaceState会在onCreate 之后的 onStart之后调用【launcher的时候，而不是reStart的时候】。 同时注意到这两个方法都有一个三个参数的重载方法是为持久化存储准备的。这两中只会调用一种，所以要注意。 参考
http://blog.csdn.net/qq_16628781/article/details/61643150