关于activity学习笔记整理——生命周期

详细可查阅官方文档http://developer.android.com/reference/android/app/Activity.html

在网上看到一份中文翻译的 可以参考

1）关于Activity的理解

个人理解，一方面Activity可以看成就是用户所看到屏幕，同时它主要处理程序整体性工作如事件监听、显示指定的View，启动其他activity等

2）Activity生命周期

产生原因：

“我们手机在运行一个应用程序的时候，有可能打进来电话发进来短信，或者没有电了，这时候程序都会被中断，优先去服务电话的基本功能，另

外系统也不允许你占用太多资源，至少要保证电话功能吧,所以资源不足的时候也就有可能被干掉。”——by haric

在android中Activity有四种基本状态：
1、Running/Active
位于屏幕最前端时（即栈顶），此时处于可见状态，和用户可交互的状态。

2、Paused
当Acitivy被另一个透明的或者非全屏的Activity覆盖时的状态叫Paused状态，虽然可见但不可交互，系统依旧保存其全部状态、成员信息。

而且当系统内存需要时会被杀掉。

3、Stop
当Activity被另外一个Activity覆盖、界面不可见时处于Stop状态。此时依旧保存所有状态及成员信息，但是对用户不可见。而且当系统内存需要时会被杀掉。

4、Killed
Activity被系统杀死或者跟本没启动时就是Killed状态。当一个activity处于paused 或者 stop状态时，系统可以要求其结束或者直接杀掉进程。当其再次展示给用户时，必须重新启动和重置之前状态。

Activity生命周期图：



个人备注要点

1.在 Android 系统中，当某个 activity调用 startActivity(myIntent) 时，系统会在所有已经安装的程序中寻找其 intent filter 和 myIntent 最匹配的一个 activity，启动这个进程，并把这个 intent 通知给这个 activity。

2.然而一个程序的“死亡”却不是由程序本身控制（这点与一般桌面应用程序不同），当内存不足或其他情况下系统需要回收该进程时，将会杀死这个进程（当然是在一定条件下）。总结来说，类似于activity的死亡不掌握在自己的手上

3.Android 是通过一种 Activity 栈的方式来管理 Activity 的，一个 Activity 的实例的状态决定它在栈中的位置。处于前台的 Activity 总是在栈的顶端，当前台的 Activity 因为异常或其它原因被销毁时，处于栈第二层的 Activity 将被激活，上浮到栈顶。当新的 Activity 启动入栈时，原 Activity 会被压入到栈的第二层。一个 Activity 在栈中的位置变化反映了它在不同状态间的转换。

监听activity三个关键循环

1.整个生命周期：从开始调用onCreate(Bundle)（初始化全局状态）到最终调用onDestroy()（释放所有资源）

2.可见生命周期：从调用onStart()开始到调用对应的onStop()结束。这两个方法可以多次调用。在这个生命周期内可以保存需要的资源和数据。

3.前台生命周期：从调用onResume()开始到调用对应的onPause()结束。在此期间该activity与用户交互。一个activity经常会频繁的在resumed与paused两个状态间跳转。所以这些方法内的代码尽量要精简。

在android.app.Activity类中已经包含一些相关方法，使用时只需重写这些方法即可

public class Activity extends ApplicationContext {
protected void onCreate(Bundle savedInstanceState);
protected void onStart();

protected void onRestart();
protected void onResume();
protected void onPause();
protected void onStop();
protected void onDestroy();
}

关于这些方法的要点

Method	Description	Killable?	Next
onCreate()	activity创建时即调用。一般将其作为程序入口点，一般做一些如创建视图、绑定数据导列表等初始化工作。 在此处载入设计好的用户界面 此外，还可以从 savedInstanceState读取保存的数据。	No	onStart()
	onRestart()	从Stop状态转换到Activity状态时调用。	No	onStart()
onStart()	当activity可见时被调用。当该activity来到栈顶时紧跟着调用onResume(),如果被隐藏则调用onStop()	No	onResume() or onStop()
	onResume()	位于栈顶时（即可以与用户交互时）被调用	No	onPause()
onPause()	当系统恢复之前的activity时调用该方法。此处应该保存数据，因为处于该状态的activity随时可能被杀死。这个方法的实现里面用时要短，因为下个activity直到这个方法完成才开始。	Yes	onResume() or onStop()
onStop()	对用户不可见时调用该方法。	Yes	onRestart() or onDestroy()
onDestroy()	这是activity销毁前最后一个调用的方法，可以用isFinshing()方法来判断究竟是因为调用了finish()方法销毁的还是因为需要内存而被系统销毁	Yes	nothing

3）进程生命周期

Android系统会尽量保留程序的进程，但当内存过低时会移除一些进程。至于究竟移除哪些进程则是依据一个判断准则，进程被分为4个状态，系统将在必要时杀掉重要性较差的进程。

1. 前台进程。这样的进程拥有一个在屏幕上显示并和用户交互的 activity 或者它的一个IntentReciver 正在运行。这样的程序重要性最高，只有在系统内存非常低，万不得已时才会被结束。

2. 可见进程。在屏幕上显示，但是不在前台的程序。比如一个前台进程以对话框的形式显示在该进程前面。这样的进程也很重要，它们只有在系统没有足够内存运行所有前台进程时，才会被结束。

3.后台进程。这样的程序拥有一个用户不可见的 activity。这样的程序在系统内存不足时，按照 LRU 的顺序被结束。当用户操作“返回”时，也就是说让该进程又回到可见状态时，它的onCreate(Bundle)方法会被调用，传进的参数是之前保存在onSaveInstanceState(Bundle)中的savedInstanceState.

4.空进程。这样的进程不包含任何活动的程序部件（比如Service或BroadcastReceiver类）。系统可能随时关闭这类进程。

4)保存持久状态

两种需要处理的持久状态：

共享文档类数据：（通常通过一个content provider保存在SQLite数据库中）

内部状态：如用户偏好设置

对于内容提供者数据，建议使用“适当编辑”的用户模式，就是说，任何用户的修改是立即有效的。

为此要坚持两个原则：

1.当创建一个新文档，马上创建后台数据库记录或文件。比如，如果用户选择写一个新的电子邮件，当他们开始输入数据时马上为该邮件创建一条新纪录，这样如果他们在此时到其他Activity，该邮件会出现在草稿列表中。

2.当一个Activity的onPause()方法调用时，应该提交用户所作的任何修改到后台内容提供者或文件中。这样确保后来运行的任意Activity可以看到这些变化。你可能希望在你的Activity生命周期的关键时候更积极地提交你的数据：比如开始一个新Activity之前，完成你自己的Activity之前，用户切换输入域时，等等。

这样做的好处是显而易见的，比如当用户切换activity时不会造成数据丢失，或者当系统在内存不足需要杀掉这些activity时不会因此丢失数据。

此外，Activity类还提供了管理内部持久状态数据的API。比如，可以用来记录用户关于一个日历初始显示的偏好设置（日视图或周视图），或者用户Web浏览器的默认主页。

下面是官方文档给的一个例子，保存日历显示设置

public class CalendarActivity extends Activity {
...
static final int DAY_VIEW_MODE = 0;
static final int WEEK_VIEW_MODE = 1;
private SharedPreferences mPrefs;
private int mCurViewMode;
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
SharedPreferences mPrefs = getSharedPreferences();
mCurViewMode = mPrefs.getInt("view_mode" DAY_VIEW_MODE);
}
protected void onPause() {
super.onPause();

SharedPreferences.Editor ed = mPrefs.edit();
ed.putInt("view_mode", mCurViewMode);
ed.commit();
}
}