应用程序组件有一个生命周期——一开始Android实例化他们响应意图,直到结束实例被销毁。在这期间,他们有时候处于激活状态,有时候处于非激活状态;对于活动,对用户有时候可见,有时候不可见。组件生命周期将讨论活动、服务、广播接收者的生命周期——包括在生命周期中他们可能的状态、通知状态改变的方法、及这些状态的组件寄宿的进程被终结和实例被销毁的可能性。
本文主要讨论活动的生命周期及他们可能的状态、通知状态改变的方法。分为以下三部分:
一个活动有三个基本状态:
如果一个活动被暂停或停止,系统可以将它从内存移除,通过要求它结束(通过调用它的finish()方法),或简单地杀掉它的进程。当它再次显示给用户时,必须要完全重新启动和恢复到之前的状态。随着活动从一个状态转为另一个状态,通过调用下面的受保护的方法通知该改变:
所有这些方法都是钩子,你可以重写当状态改变时做适当的工作。所有的活动必须要实现onCreate()去做一些初始化的设置,当对象第一次实例化的时候。很多活动也会实现onPause()去提交数据修改或准备停止与用户交互。
将他们合并在一起,这七个方法定义了活动的整个生命周期。有三个嵌套的循环,你可以通过这七个方法监视:
下面这个图解释了这三个循环和状态之间状态的可能路径。着色的椭圆表示活动的主要状态,矩形表示当活动在状态之间转换时你可以执行的回调方法。
图1、活动生命周期(来源:Android SDK)
下面的表格对每个方法更详细的描述和在活动的整个生命周期中的定位。
注意上面表格的Killable列,它表示当方法返回时没有执行活动的其它代码,系统是否能杀死活动寄宿的进程。三个方法(onPause()、onStop()、onDestroy())标记为Yes。因为onPause()是唯一一个保证在进程被杀之前会调用的,因此你应该使用onPause()来写任何持久化存储数据。
被标记为No的方法保护活动寄宿的进程在他们调用的时候不会被杀掉。因此活动是可杀掉状态,例如onPause()返回到onResume()调用期间。直到onPause()再次返回,活动是不可杀掉的。其实,没有标记为Killable的活动也是可以系统被杀掉的,不过这仅仅发生在极端困难的情况下,没有有任何其他资源可用。
当系统而不是用户关闭一个活动来节省内存时,用户可能希望返回到活动且是它之前的状态。为了获得活动被杀之前的状态,你可以执行活动的onSaveInstanceState()方法。Android在活动容易被销毁前调用这个方法,也就是调用onPause()之前。该方法的参数是一个Bundle对象,在这个对象你可以以名值对记录活动的动态状态。当活动再次启动时,Bundle同时被传递到onCreate()和调用onCreate()之后的方法,onRestoreInstanceState(),因此使用一个或两个可以重新创建捕获的状态。
因为onSaveInstanceState()方法不总是被调用,你应该仅使用onSaveInstanceState()它来记录活动的临时状态,而不是持久的数据。应该使用onPause()来存储持久数据。
当一个活动启动另一个活动,他们都经历生命周期转换。一个暂停或许是停止,然而另一个启动。有时,你可能需要协调这些活动。生命周期的回调顺序是明确界定的,特别是当这两个活动在同一个进程中:
修正:第一节——活动生命周期中的表格第一、二行中的第二列(description)中的onRestart()应该为onStart()。
1000多的点击,居然没有人发现这个错误,看了大家根本就没认真看或者说根本没有静心看园子里的任何博文,心痛!还是水帖比较受欢迎。
组件生命周期(二)
应用程序组件有一个生命周期——一开始Android实例化他们响应意图,直到结束实例被销毁。在这期间,他们有时候处于激活状态,有时候处于非激活状态;对于活动,对用户有时候可见,有时候不可见。组件生命周期将讨论活动、服务、广播接收者的生命周期——包括在生命周期中他们可能的状态、通知状态改变的方法、及这些状态的组件寄宿的进程被终结和实例被销毁的可能性。
上篇Android开发之旅:组件生命周期(一)讲解了论活动的生命周期及他们可能的状态、通知状态改变的方法。本篇将介绍服务和广播接收者的生命周期:
一个服务可以用在两个方面:
这两种模式并不是完全分离的。你可以绑定到一个用startService()启动的服务。例如,一个后台音乐服务可以通过使用定义了音乐播放的Intent对象调用startService()启动。直到后来,用户可能想对播放器做一些控制或者获取当前歌曲的一些信息,一个活动将调用bindService()与服务建立连接。在这种情况下,实际上直到最后一个绑定关闭stopService()并不会停止。
像活动一样,一个服务也有生命周期方法,你可以执行监视它的状态改变。但是比活动的生命周期方法更少,只有三个且它们是公有的(public)而不是受保护的(protected)(说明:活动的生命周期方法是protected的):
通过这三个方法,你可以监视服务生命周期的两个嵌套循环:
startService()和onDestory()被所有服务调用,不管是通过Context.startService()启动还是通过Context.bindService()启动的。然而,onStart()仅被通过startService()启动的服务调用。
如果一个服务允许别的绑定到它,有一些额外的回调方法来实现它:
onBind()回调传递的参数是传给bindService()的Intent对象,onUnbind()回调传递的参数是传给unbindService()的Intent对象。如果服务允许绑定,onBind()返回客户端与服务交互的通信通道。onUnbind()方法可以要求调用onRebind(),如果一个新的客户端连接到服务。
下图解释了服务的回调方法。虽然,它分离了由startService()启动的服务和由bindService()启动的服务,记住任何服务,无论它怎么启动的,都可能允许客户端绑定到它,因此任何服务可能接收onBind()和onUnbind()调用。
一个广播接收者有一个回调方法:void onReceive(Context curContext, Intent broadcastMsg)。当一个广播消息到达接收者是,Android调用它的onReceive()方法并传递给它包含消息的Intent对象。广播接收者被认为仅当它执行这个方法时是活跃的。当onReceive()返回后,它是不活跃的。
有一个活跃的广播接收者的进程是受保护的,不会被杀死。但是系统可以在任何时候杀死仅有不活跃组件的进程,当占用的内存别的进程需要时。
这带来一个问题,当一个广播消息的响应时费时的,因此应该在独立的线程中做这些事,远离用户界面其它组件运行的主线程。如果onReceive()衍生线程然后返回,整个进程,包括新的线程,被判定为不活跃的(除非进程中的其它应用程序组件是活跃的),将使它处于被杀的危机。解决这个问题的方法是onReceive()启动一个服务,及时服务做这个工作,因此系统知道进程中有活跃的工作在做。
组件生命周期(三)
Android系统试图尽可能长地保持一个应用程序进程,但是当内存低时它最终还是需要移除旧的进程。为了决定保持哪个进程及杀死哪个进程,Android将每个进程放入一个基于运行于其中的组件的重要性等级和这些组件的状态。重要性最低的进程首先被杀死,然后是次低,以此类推。总共有5个层次等级。下列清单按重要性顺序列出:
Android把进程标记为它可以的最高级,即进程中活跃的组件中重要性最高的那个(选取重要性最高的那个作为进程的重要性级别)。例如,有一个进程寄宿着一个服务和一个可视活动,进程的级别被设置为可视进程级别,而不是服务进程级别(因为可视进程级别比服务进程级别高)。
此外,一个进程的排名因为其他进程依赖它而上升。一个进程服务其它进程,它的排名从不会比它服务的进程低。例如,进程A中的一个内容提供者服务进程B中的一个客户,或者进程A中的一个服务绑定到进程B中的一个组件,进程A总是被认为比进程B重要。
因为一个运行一个服务进程排名比一个运行后台活动的进程排名高,一个活动启动一个服务来初始化一个长时间运行操作,而不是简单地衍生一个线程——特别是如果操作很可能会拖垮活动。这方面的例子是在后台播放音乐和上传相机拍摄的图片到一个网站。使用服务保证操作至少有“服务进程”的优先级,无论活动发生什么情况。