Activity的生命周期<菜鸟总结>

生命周期学得不是特别好所以最近拿出来重新学

public class BaseActivity  extends Activity{

  /**
   * 为了可以保存额外更多的数据到saved instance state。在Activity的生命周期里面存在一个额外的回调函数，你必须重写这个函数。
   * 该回调函数并没有在前面课程的图片示例中显示。
   * 这个方法是onSaveInstanceState() ，当用户离开Activity时，系统会调用它。
   * 当系统调用这个函数时，系统会在Activity被异常Destory时传递 Bundle 对象，这样我们就可以增加额外的信息到Bundle中并保存到系统中。
   * 若系统在Activity被Destory之后想重新创建这个Activity实例时，之前的Bundle对象会(系统)被传递到你我们activity的onRestoreInstanceState()方法与 onCreate() 方法中。
   *
   * 当我们的activity开始Stop，系统会调用 onSaveInstanceState() ，Activity可以用键值对的集合来保存状态信息。这个方法会默认保存Activity视图的状态信息，如在 EditText 组件中的文本或 ListView 的滑动位置。
   *
   *为了给Activity保存额外的状态信息，你必须实现onSaveInstanceState() 并增加key-value pairs到 Bundle 对象中，例如：
   */
  @Override protected void onSaveInstanceState(Bundle outState) {
    super.onSaveInstanceState(outState);
  }

  /**
   * 当Activity从Destory中重建，我们可以从系统传递的Activity的Bundle中恢复保存的状态。
   * onCreate() 与 onRestoreInstanceState() 回调方法都接收到了同样的Bundle，里面包含了同样的实例状态信息。
*
 *  由于 onCreate() 方法会在第一次创建新的Activity实例与重新创建之前被Destory的实例时都被调用，我们必须在尝试读取 Bundle 对象前检测它是否为null。如果它为null，
   *  系统则是创建一个新的Activity实例，而不是恢复之前被Destory的Activity。
   */

  /**
   * 程序启动的时候执行，执行时间相对较短
   * 适合完成的工作内容：初始化工作
   * 忌讳：做耗时过长的操作，导致运行不流程体验不好
   * 这个阶段Activity特点：Activity获取系统资源，没有显示在界面上
   * @param savedInstanceState
   */

  @Override protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Log.e("TAG","onCreate");
//    if (savedInstanceState != null) {
//      // Restore value of members from saved state
//      mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
//      mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
//    } else {
//      // Probably initialize members with default values for a new instance
//    }
  }

  /**
   * 执行重启的情况：
   * 用户打开最近使用app的菜单并从我们的app切换到另外一个app，这个时候我们的app是被停止的
   * 如果用户通过手机主界面的启动程序图标或者最近使用程序的窗口回到我们的app，那么我们的activity会重启。
   * 用户在我们的app里面执行启动一个新activity的操作，当前activity会在第二个activity被创建后stop。如果用户点击back按钮，第一个activtiy会被重启
   * 用户在使用我们的app时接收到一个来电通话
   */
  @Override protected void onRestart() {
    super.onRestart();
    Log.e("TAG", "onRestart");
  }

  /**
   *用于显示界面，从这里开始Activity的属性是visible
   */
  @Override protected void onStart() {
    super.onStart();
    Log.e("TAG", "onStart");
  }

  /**
   *
   * @param savedInstanceState
   * @param persistentState
   */
  @Override public void onRestoreInstanceState(Bundle savedInstanceState, PersistableBundle persistentState) {
    super.onRestoreInstanceState(savedInstanceState, persistentState);
//    mCurrentScore = savedInstanceState.getInt(STATE_SCORE);
//    mCurrentLevel = savedInstanceState.getInt(STATE_LEVEL);
  }

  /**
   * Activity阶段：该状态下，activity处在前台，用户可以与它进行交互。(通常也被理解为"running" 状态)
   *
   *
   */
  @Override protected void onResume() {
    super.onResume();
    Log.e("TAG", "onResume");
    // Get the Camera instance as the activity achieves full user focus
   /* if (mCamera == null) {
      initializeCamera(); // Local method to handle camera init
    }*/
  }

  /**
   * Activity处于 Partially visible阶段 activity的部分被另外一个activity所遮盖  被暂停的activity不再接受用户的输入且不再执行任何代码。
   *
   * 当启动另外一个Activity时 执行顺序是  onPause(A)---Oncreate(B)---Onstart(B)---OnResume(B)--OnStop(A)
   *
   * 应该在这个方法中执行以下操作
   * 停止动画或者是其他正在运行的操作，那些都会导致CPU的浪费.
   * 提交在用户离开时期待保存的内容(例如邮件草稿).
   * 释放系统资源，例如broadcast receivers, sensors (比如GPS), 或者是其他任何会影响到电量的资源。
   *
   * 通常，不应该使用onPause()来保存用户改变的数据到永久存储(File或者DB)上。
   * 仅仅当确认用户期待那些改变能够被自动保存的时候，才把那些数据存到永久存储 。
   * 但是，我们应该避免在onPause()时执行CPU-intensive 的工作，
   * 例如写数据到DB，因为它会导致切换到下一个activity变得缓慢(应该把那些heavy-load的工作放到onStop()去做)。
   *
   */
  //TODO
  @Override protected void onPause() {
    super.onPause();
    Log.e("TAG", "onPause");
//    if (mCamera != null) {
//      mCamera.release()
//      mCamera = null;
//    }
  }

  /**
   * 处于Hidden阶段
   * activity已经停止后，Activity对象会保存在内存中，并在activity resume时被重新调用。
   * 我们不需要在恢复到Resumed state状态前重新初始化那些被保存在内存中的组件。
   * 系统同样保存了每一个在布局中的视图的当前状态，如果用户在EditText组件中输入了text，它会被保存，因此不需要保存与恢复它。
   * 如果有图片的话，一定要记得recycle掉
   *Andorid限制了8M的图片内存，如果超过了就会溢出，那就是要及时释放内存中的图片资源。
   *我之前的做法是简单对图片对象设置null。其实这样是不行的，图片依然在内存中的。那如何做更有效呢?很简单。有代码有真相。
   *
   * 一个图片加载到内存里，其实是有两部分数据组成，一部分是图片的相关描述信息，另一部分就是最重要的像素信息（这部分是有byte数组组成的），android系统为了提高对图片的处理效率，对于图片的处理都是调用了底层的功能（由C语言实现的），也就是说一个图片加载到内存里后是使用两部分的内存区域，简单的说：一部分是java可用的内存区，一部分是c可用的内存区，这两个内存区域是不能相互直接使用的，
   *这个bitmap对象是有java分配的，当然不用的时候系统会自动回收了，可是那个对应的C可用的内存区域jvm是不能直接回收的，这个只能调用底层的功能释放。所以你要调用recycle方法来释放那一部分内存
   *http://site.leshou.com/s/15119624.html资源回收讲解
   * ListView 回收机制http://blog.csdn.net/hknock/article/details/9329761
   * Android系统清理机制http://www.zzzyk.com/show/1bebcec33f129c80.htm
   * 释放资源优先级 http://www.android-study.net/listxx.aspx?id=194
   * 比较好的释放xml文件资源方式http://blog.csdn.net/chen825919148/article/details/23843049
   * http://blog.csdn.net/chen825919148/article/details/23918611
   * WebView 内存泄漏问题 http://blog.csdn.net/chen825919148/article/details/23920013
   * 如果线程不关闭，资源就不会回收
   * http://blog.sina.com.cn/s/blog_4b9f8cdd0101kyzg.html//TODO
   */
  @Override protected void onStop() {
    super.onStop();
    Log.e("TAG", "onStop");
//    if(!bitmap.isRecycled()){//先判断图片是否已释放了
//
//      bitmap.recycle();
//
//    }
  }

  /**
   * 用于释放Oncreate时创建的资源 局部类的引用会随着activity的销毁而销毁
   * 如果activity含有在onCreate调用时创建的后台线程，或者是其他有可能导致内存泄漏的资源，则应该在OnDestroy()时进行资源清理，杀死后台线程。
   * 当activity调用onStop()方法, activity不再可见，并且应该释放那些不再需要的所有资源。
   * 一旦activity停止了，系统会在需要内存空间时摧毁它的实例(和栈结构有关，通常back操作会导致前一个activity被销毁)。
   * 极端情况下，系统会直接杀死我们的app进程，并不执行activity的onDestroy()回调方法, 因此我们需要使用onStop()来释放资源，从而避免内存泄漏。(这点需要注意)
   *
   *有几个场景中，Activity是由于正常的程序行为而被Destory的。
   * 例如当用户点击返回按钮或者是Activity通过调用finish()来发出停止信号。
   * 系统也有可能会在Activity处于stop状态且长时间不被使用，或者是在前台activity需要更多系统资源的时关闭后台进程，以图获取更多的内存。
   *当Activity是因为用户点击Back按钮或者是activity通过调用finish()结束自己时，系统就丢失了对Activity实例的引用，因为这一行为意味着不再需要这个activity了。
   * 然而，如果因为系统资源紧张而导致Activity的Destory， 系统会在用户回到这个Activity时有这个Activity存在过的记录，系统会使用那些保存的记录数据（描述了当Activity被Destory时的状态）来重新创建一个新的Activity实例。
   * 那些被系统用来恢复之前状态而保存的数据被叫做 "instance state"
   *，它是一些存放在Bundle对象中的key-value pairs。(请注意这里的描述，这对理解onSaveInstanceState执行的时刻很重要)
   */
  @Override protected void onDestroy() {
    super.onDestroy();
    android.os.Debug.stopMethodTracing();
 Log.e("TAG","onDestroy");
  }
}