之前零零散散地学了很多,但总感觉没有一个系统的结构,想想原因有两个:
1.没有及时总结,不要觉得看过了,会了就可以了,那会忘记的,还会二次学习的!
2.没有看官方的资料! 官方资料很经典!
今天我学习了google官方的trainning模块的《管理Activity的生命周期》中文版,链接 点击打开链接
开始总结:
<span style="white-space:pre"> </span><activity android:name=".MainActivity" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity>
onCreate:声明UI元素,定义成员变量,配置UI等。(onCreate里面尽量少做事情,避免程序启动太久都看不到界面),savedInstanceState: 重新创建activity涉及到
activity的第一个生命周期回调函数是 onCreate(),它最后一个回调是onDestroy().当收到需要将该activity彻底移除的信号时,系统会调用这个方法。
大多数 app并不需要实现这个方法,因为局部类的references会随着activity的销毁而销毁,
并且我们的activity应该在onPause()与onStop()中执行清除activity资源的操作。然而,如果activity含有在onCreate调用时创建的后台线程,
或者是其他有可能导致内存泄漏的资源,则应该在OnDestroy()时进行资源清理,杀死后台线程。
activity一旦进入paused状态,系统就会调用activity中的onPause()方法, 该方法中可以停止不应该在暂停过程中执行的操作,如暂停视频播放;或者保存那些有可能需要长期保存的信息。如果用户从暂停状态回到当前activity,系统应该恢复那些数据并执行onResume()方法。
是用户要离开我们的activtiy的第一个信号
停止动画或者是其他正在运行的操作,那些都会导致CPU的浪费.
提交在用户离开时期待保存的内容(例如邮件草稿).
释放系统资源,例如broadcast receivers, sensors (比如GPS), 或者是其他任何会影响到电量的资源。
通常,不应该使用onPause()来保存用户改变的数据 (例如填入表格中的个人信息) 到永久存储(File或者DB)上。仅仅当确认用户期待那些改变能够被自动保存的时候(例如正在撰写邮件草稿),才把那些数据存到永久存储 。但是,我们应该避免在onPause()时执行CPU-intensive 的工作,例如写数据到DB,因为它会导致切换到下一个activity变得缓慢(应该把那些heavy-load的工作放到onStop()去做)。
如果activity实际上是要被Stop,那么我们应该为了切换的顺畅而减少在OnPause()方法里面的工作量。
系统每次调用这个方法时,activity都处于前台,包括第一次创建的时候。所以,应该实现onResume()来初始化那些在onPause方法里面释放掉的组件,并执行那些activity每次进入Resumed state都需要的初始化动作 (例如开始动画与初始化那些只有在获取用户焦点时才需要的组件)
系统在activity停止时会在内存中保存Activity的实例
无论什么原因导致activity停止,系统总是会在onStop()之前调用onPause()方法。
一旦activity停止了,系统会在需要内存空间时摧毁它的实例(和栈结构有关,通常back操作会导致前一个activity被销毁)。
极端情况下,系统会直接杀死我们的app进程,并不执行activity的onDestroy()回调方法,
因此我们需要使用onStop()来释放资源,从而避免内存泄漏。(这点需要注意)
尽管onPause()方法是在onStop()之前调用,我们应该使用onStop()来执行那些CPU intensive的shut-down操作,例如往数据库写信息。
activity已经停止后,Activity对象会保存在内存中,并在activity resume时被重新调用。
我们不需要在恢复到Resumed state状态前重新初始化那些被保存在内存中的组件。系统同样保存了每一个在布局中的视图的当前状态,
如果用户在EditText组件中输入了text,它会被保存,因此不需要保存与恢复它。
当activity从Stopped状态回到前台时,它会调用onRestart().系统再调用onStart()方法,onStart()方法会在每次activity可见时都会被调用。onRestart()方法则是只在activity从stopped状态恢复时才会被调用,因此我们可以使用它来执行一些特殊的恢复(restoration)工作,请注意之前是被stopped而不是destrory。
使用onRestart()来恢复activity状态是不太常见的,因此对于这个方法如何使用没有任何的guidelines。然而,
因为onStop()方法应该做清除所有activity资源的操作,我们需要在重启activtiy时重新实例化那些被清除的资源,同样,
我们也需要在activity第一次创建时实例化那些资源。介于上面的原因,应该使用onStart()作为onStop()所对应方法。
因为系统会在创建activity与从停止状态重启activity时都会调用onStart()。也就是说,我们在onStop里面做了哪些清除的操作,
就该在onStart里面重新把那些清除掉的资源重新创建出来。
例如:因为用户很可能在回到这个activity之前已经过了很长一段时间,所以onStart()方法是一个比较好的地方来验证某些必须的系统特性是否可用。
当系统Destory我们的activity,它会为activity调用onDestroy()方法。因为我们会在onStop方法里面做释放资源的操作,那么onDestory方法则是我们最后去清除那些可能导致内存泄漏的地方。因此需要确保那些线程都被destroyed并且所有的操作都被停止。
为了使Android系统能够恢复Activity中的View的状态,每个View都必须有一个唯一ID,由android:id定义。
为了可以保存额外更多的数据到saved instance state。在Activity的生命周期里面存在一个额外的回调函数,你必须重写这个函数。该回调函数并没有在前面课程的图片示例中显示。这个方法是onSaveInstanceState() ,当用户离开Activity时,系统会调用它。当系统调用这个函数时,系统会在Activity被异常Destory时传递 Bundle 对象,这样我们就可以增加额外的信息到Bundle中并保存到系统中。若系统在Activity被Destory之后想重新创建这个Activity实例时,之前的Bundle对象会(系统)被传递到你我们activity的onRestoreInstanceState()方法与 onCreate() 方法中。
(通常来说,跳转到其他的activity或者是点击Home都会导致当前的activity执行onSaveInstanceState,因为这种情况下的activity都是有可能会被destory并且是需要保存状态以便后续恢复使用的,而从跳转的activity点击back回到前一个activity,那么跳转前的activity是执行退栈的操作,所以这种情况下是不会执行onSaveInstanceState的,因为这个activity不可能存在需要重建的操作)
由于 onCreate() 方法会在第一次创建新的Activity实例与重新创建之前被Destory的实例时都被调用,我们必须在尝试读取 Bundle 对象前检测它是否为null。如果它为null,系统则是创建一个新的Activity实例,而不是恢复之前被Destory的Activity。