Activity官方文档译文简析

CSDN这个垃圾，弄个回收站又不能还原

生命周期

1. 可见的生命周期 
   onStart–>onResume–>onPause–>onStop 
   在这期间可以保留需要展示给用户的信息，例如在onStart中注册BroadCastReceiver，无需展示时在onStop中注销。在显示与隐藏间，这些方法可调用多次。
2. 前台的生命周期 
   onResume–>onPause 
   Activity在活动期间会在这两个方法间频繁切换，例如Activity休眠、接收Result，发送intent，因此，这些方法里的代码务必使轻量级的。

所有的Activity在onCreate中初始化设置，也可以在onPause中提交数据更改，否则准备停止与用户进行交互。生命周期方法在复写时，应该首先调用父类相应的生命周期方法。

1. onCreate 
   首次创建时调用，做一些常规的静态设置，例如创建View，绑定数据到list等等，如果有，该方法也提供一个保存过去冻结状态的Bundle。该方法之后总是跟着onStart
2. onRestart 
   Killable: No 
   onStop之后再次启动时调用，之后总跟着onStart
3. onStart 
   Killable: No 
   由不不可见到可见时调用，之后跟着onResume或者onStop
4. onResume 
   Killable:No 
   与用户开始交互时调用， 之后跟着onPause()
5. onPause 
   Killable: Pre-HONEYCOMB 
   重启旧Activity时调用，通常用来提交持久化数据没来得及保存的更新，停止动画等消耗CPU的动作。如果当前Activity回到前台，紧接着会调用onResume；如果当前Activity对用户不可见，则紧接着调用onStop
6. onStop 
   Killable: Yes 
   对用户不可见时调用。新Activity启动、旧Activity回到前台，或者当前Activity即将销毁时可能发生。所在Activity再次回到前台时紧接着调用onRestart，等待销毁时调用onDestroy。
7. onDestroy 
   Killable: Yes 
   Activity即将销毁时调用，当被finish或者被系统回收时调用，可以通过isFinishing()方法区分这两种情形。

注意：Killable为Yes的方法随着进程被杀可能不会执行，因此需要存储持久化数据请写在onPause中，动态的实例状态存在onSaveInstanceState(Bundle)中，然后在onCreate(Bundle)中接收。持久化数据的存储写在onPause中，不要写在onSaveInstanceState(Bundle)中，因为后者不是生命周期方法，不一定会被调用。 
在以HONYCOMB方式启动的应用级平台略有不同，这种情况下直到onStop返回时才是Killable，这时候onSaveInstanceState(Bundle)会在onPause之后安全调用，并允许在onStop中保存持久化数据。

改变配置

例如屏幕方向，语言，输入设备发生改变时 
一般情况下，改变配置时，原Activity会经onPause、onStop和onDestroy销毁，然后使用onSaveInstanceState(Bundle)中保存的数据经onCreate重新创建新实例。 
特殊情况下，在Menifest的Android:configChanges 中指定配置，这样在该配置发生改变时，Activity中会调用onConfigurationChanged(Configuration)，而不是重新启动。但是不包含在configChanges中的配置变更仍然会使得Activity重启，这时候onConfigurationChanged(Configuration)不会调用。

启动Activity

1. 使用startActivity(Intent)
2. 使用startActivityForResult（Intent, int），第二个参数为请求码 
   A通过startActivityForResult（Intent, int），启动B，B通过setResult(int)设置返回数据，返回后A通过onActivityResult(int, int, Intent)获取该数据。

保存持久化数据

一个Activity通常要处理两种持久化数据： 
1. shared document-like data，共享文档类数据（例如，使用ContentProvider的SQLite数据库） 
2. internal state 内部存储（如user preferences）

对于content provider data, 建议使用“即时编辑”的user model, 也就是用户做出的任何编辑不需要请求额外的确认步骤直接生效，使用这个model通常遵循以下两条规则： 
1. 当创建一个新文档时，立即创建相应的后台数据库的入口或文件。例如，如果用户要写一封新邮件，当用户开始输入内容时，对应该邮件的一个新数据库入口即被创建，这样当用户进入其他界面，这封邮件将保存在草稿箱。 
2. 当Activity的onPause方法调用时，用户做出的更改将提交到后台的content provider或文件。这保证了这些更改对于其他Activity同样适用。你可能需要更主动的在生命周期的关键时刻提交数据，例如在启动新Activity之前，在结束当前Activity之前，在用户切换输入栏的时候等等。 
设计这个module意在当用户切换Activity时防止数据丢失，并且确保系统在onPause之后的任意时刻安全地杀死Activity。注意，这里指的是从Activity中按返回键的时候，而非“取消”，即结束Activity的同时保存数据。在Activity中取消编辑必须通过其他机制，比如“revert”或者“undo”操作。

See the content package for more information about content providers. These are a key aspect of how different activities invoke and propagate data between themselves.

The Activity class also provides an API for managing internal persistent state associated with an activity. This can be used, for example, to remember the user’s preferred initial display in a calendar (day view or week view) or the user’s default home page in a web browser.

对于internal state， getPreferences(int)方法管理Activity的持久化数据，提供获取和修改activity相关的name/value键值对。通过Context.getSharedPreferences()可以实现跨组件数据共享。

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();
     }
 }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Permission

（略）

Process Lifecycle

（略）