一个活动是一个单一的,集中的东西,用户可以做的。几乎所有的活动与用户交互,因此Activity类需要创建为您窗口,在其中您可以将您的UI与照顾 的setContentView(查看)
。而活动经常呈现给用户作为全屏窗口,它们也可以以其他方式使用:作为浮动窗口(经由与主题windowIsFloating
组)或嵌入另一活性(使用的内部的ActivityGroup
)。有两种方法几乎所有活动的子类将实施:
的onCreate(捆绑)
是你初始化你的活动。最重要的是,在这里你会通常所说的setContentView(int)的
一个布局资源定义你的用户界面,并使用findViewById(INT)
来检索在UI,你需要通过编程交互的小部件。的onPause()
是您处理用户离开你的活动。最重要的是,由用户作出的任何变更应在此时被提交(通常到 的ContentProvider
保持数据)。Context.startActivity()
,所有的活动类都必须有一个相应的
<活动>
在其包装的声明
AndroidManifest.xml中
。
在系统中的活动作为管理活动的堆栈。当一个新的活动开始时,它被放置在堆栈的顶部和成为运行活动-以前的活动始终保持低于它在堆栈,而不会再次到达前台,直到新的活动退出。
活动基本上有四种状态:
下图显示了一个Activity的重要状态路径。长方形表示你可以实现当活动状态之间移动来执行操作的回调方法。彩色的椭圆形是主要国家的活动可在英寸
有三个关键的循环,你可能有兴趣在你的活动范围内的监控:
的onCreate(捆绑)
通过单个最终调用的onDestroy()
。活动会做的的onCreate(“全球性”的状态)的所有设置,并释放所有剩余资源的onDestroy()。例如,如果它有在后台从网络下载数据运行的线程,它可能会在的onCreate(),该线程,然后在的onDestroy停止线程()。调用onStart()
,直到到相应通话 的onStop()
。在此期间,用户可以在屏幕上看到的活性,尽管它可能不是在前台和与用户交互。这两种方法之间就可以保持所需要以显示活动给用户的资源。例如,您可以注册一个广播接收器
在调用onStart()以监控影响您的用户界面的变化,并在注销的onStop它(),当用户不再看你是什么显示。的调用onStart()和的onStop()方法可被调用多次,作为活动变得可见和隐藏到用户。onResume()
,直到到相应通话 的onPause()
。在此期间,该活动是在所有其他活动的前部和与用户交互。一项活动可以续和暂停状态之间频繁地去-例如当设备进入睡眠状态,当一个活动的结果被传递,当一个新的意图传递-因此在这些方法的代码应该是相当轻巧。的onCreate(捆绑)
做他们的初始设置; 许多人也将实施
的onPause()
提交修改到的数据和其它准备停止与用户交互。实现这些方法时,应始终调用你的超类。
一般来说,通过活动的生命周期中的运动看起来是这样的:
方法 | 描述 | Killable? | 下一个 | ||
---|---|---|---|---|---|
的onCreate() |
第一次创建活动时调用。这是你应该做的所有的正常静态设置的:创建视图,数据绑定到列表等等。这种方法还提供了包含捆绑活动的先前冷冻状态时,如果有一个。 总是跟随 |
没有 | 在onStart() |
||
onRestart() |
后您的活动已停止调用,被再次启动之前它。 总是跟随 |
没有 | 在onStart() |
||
在onStart() |
当活动是变对用户可见调用。 其次是 |
没有 | onResume() 或的onStop() |
||
onResume() |
当调用活动将开始与用户交互。在这一点上的活动是在活动堆栈的顶部,与用户输入要它。 总是跟着 |
没有 | 的onPause() |
||
的onPause() |
当调用系统即将开始恢复以前的活动。这通常用于承诺的持久性数据未保存的更改,停止动画和其他的东西,可能会占用CPU等这个方法的实现必须非常快,因为接下来的活动将不会被恢复直到这个方法返回。 后跟 |
预蜂窝 |
onResume() 或的onStop() |
||
的onStop() |
当调用活动不再对用户可见,因为其他活动已经恢复并且覆盖这一个。这种情况可能发生是因为新的活动正在被启动,一个现有的将被带入在这一个的前面,或这一个被销毁。 后跟 |
是 | onRestart() 或的onDestroy() |
||
的onDestroy() |
您的活动前收到的最后通话将被破坏。或者是因为该活动结束会发生这种情况(有人叫光洁度() 就可以了,或因为系统暂时销毁活动的这种情况下,以节省空间,你可以这两个方案的区别isFinishing() 方法。 |
是 | 没有 |
注意在上面的表中的“Killable”列-对于那些标记为killable方法,之后该方法返回承载活动的过程中可能会被系统杀死随时没有其代码的另一行被执行。正因为如此,你应该使用 的onPause()
方法的任何持久性数据(如用户编辑)写入到存储。此外,该方法 的onSaveInstanceState(包)
被放置活动在这样的背景下状态,让您在任何动态实例状态在活动保存消失在给定的捆绑,在稍后收到之前调用 的onCreate(捆绑)
如果活动需要被重新创建。请参阅流程生命周期 部分在流程的生命周期是如何依赖于它承载活动的更多信息。需要注意的是它保存持久性数据是很重要的onPause()
代替的onSaveInstanceState(包)
,因为后者不是生命周期回调的一部分,因此不会在任何情况下它的文档中描述的调用。
要知道,这些语义将针对应用程序平台开始略有改变蜂窝
与 那些针对之前平台。与蜂窝启动,应用程序是不是在killable状态,直到它的onStop()
返回。这种影响时的onSaveInstanceState(包)
可被称为(它可以安全地之后调用()的onPause
并允许应用安全地等到的onStop()
来保存持久状态。
对于那些没有标记为killable方法,该活动的过程中不会被从该方法被称为时间开始和继续返回后系统杀死。因此,一个活动是在killable状态,例如,后之间的onPause()
到开始 onResume()
。
如果该装置的构造(由定义 Resources.Configuration
类)的变化,则任何显示用户界面将需要更新以匹配的配置。由于活动是与用户交互的主要机制,它包括用于处理配置更改特殊支持。
除非你指定,配置变更(如屏幕方向,语言,输入设备等的变化)将导致当前的活动破坏,通过正常活动的生命周期过程中去的onPause()
, 的onStop()
和的onDestroy()
为宜。如果活动已经在前台或对用户可见,一旦的onDestroy()
调用在该实例那么活动的新实例将被创建,与任何savedInstanceState以前的实例已经从生成的onSaveInstanceState(捆绑)
。
这是因为任何应用程序资源,包括布局文件,可以更改基于任何配置值完成。因此,要处理配置更改的唯一安全的方法是重新获取所有资源,包括布局,图形和字符串。由于活动必须已经知道如何保存其状态,并从该国重新打造自己,这是有一个活动的启动本身就带有新配置的简便方法。
在某些特殊情况下,你可能想绕过基于一个或多个类型的配置更改重新启动您的活动。这是用做机器人:configChanges
在它的属性。对于你说你处理没有任何类型的配置更改,您将收到一个电话到你当前活动的 onConfigurationChanged(配置)
方法,而不是被重新启动。如果配置变化涉及任何你不处理,但是,该活动仍然会重新启动并onConfigurationChanged(配置)
将不会被调用。
所述startActivity(意向)
方法用于启动一个新的活动,这将被放置在活动堆栈的顶部。它采用一个参数,一个意图
,它描述了活动的执行。
有时你想要得到的结果,从一个活动回来何时结束。例如,你可以开始一个活动,可以让用户选择一个人的联系人列表; 它结束时,它返回所选定的人。要做到这一点,您可以调用 startActivityForResult(意向,INT)
与第二整数参数识别呼叫版本。结果会通过您的onActivityResult(INT,INT,意图)
的方法。
当一个活动退出,它可以调用 的setResult(INT)
要返回数据,其母公司。它必须始终提供一个结果码,它可以是标准的结果RESULT_CANCELED,RESULT_OK,或开始RESULT_FIRST_USER任何自定义值。此外,它可任选地返回回包含它想要的任何额外数据的意图。所有这些信息似乎回到了父母的Activity.onActivityResult()
,它最初提供的整数标识符一起。
如果一个子活动因任何原因(如崩溃)失败,父活动将收到的代码RESULT_CANCELED的结果。
当用户中压,让他们挑 联系人被选中。在这里,我们将只显示它 //给用户。 startActivity (新的 意向书(意向书。ACTION_VIEW ,数据)); } } } }
这里一般有2种持久状态比活动将涉及:共享类似于文献的数据(通常存储在SQLite数据库使用的是内容提供商)和内部状态,如用户首选项。
对于内容提供商的数据,我们建议活动中使用一个“编辑到位”的用户模型。即,用户品牌被有效地立即进行的任何修改,而无需额外的确认步骤。支持这种模式通常是以下两条规则的一个简单的问题:
当创建一个新的文件,因为它的后盾数据库项或文件立即创建。例如,如果用户选择写一个新的电子邮件,该电子邮件的一个新条目,尽快为他们开始输入数据,因此,如果他们去任何其他活动点此电子邮件后,将创建现在出现在草案的列表。
当一个活动的的onPause()
方法被调用,它应该致力于为后盾内容提供商或文件中的用户所做的改动。这确保了这些变化将由即将运行的任何其他活动中可以看出。你可能会想更积极地在关键时刻你的活动的生命周期中提交你的数据:开始新的活动之前,例如,整理自己的活动,在此之前,当输入字段等的用户切换
该模型的目的是防止当用户正在活动之间导航的数据丢失,并允许该系统已被暂停之后,在任何时候安全地杀死活性(因为需要系统资源的其他地方)。请注意,这意味着用户按下BACK从您的活动并不能 意味着“取消” -这意味着离开活性保存离开其当前内容。在活动取消的修改必须通过其他机制来提供,如明确的“恢复”或“取消”选项。
查看内容包有关内容供应商的详细信息。这些都是不同的活动如何调用和它们之间传播数据的一个重要方面。
Activity类还提供了管理与活动有关的内部持久化状态的API。这可以用来,例如,要记得在日历(日视图或周视图),或者用户的首选初始显示在Web浏览器用户的默认主页。
活动持续状态与方法管理的getPreferences(INT)
,让您检索和修改一组与活动相关的名称/值对。要使用跨多个应用程序组件(活动,接收器,服务提供商)共享的喜好,可以使用底层 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 (); } }
当它在其清单的声明可以被强制启动特定活动的能力<活动>
标记。通过这样做,其他应用需要声明一个相应 <用途-权限>
在自己的清单元素能够启动活动。
当启动一个活动,你可以设置Intent.FLAG_GRANT_READ_URI_PERMISSION
和/或Intent.FLAG_GRANT_WRITE_URI_PERMISSION
的意图。这将授予在Intent活动访问特定的URI。访问将保持到活动结束(它仍将是整个被杀死宿主进程和其他临时破坏)。作为 姜饼
,如果活动已经创建一个新的意图被传递到onNewIntent(意向)
,任何新批的URI权限将被添加到它保持现有的。
请参阅安全性和权限 为一般权限的更多信息和安全文档。
Android系统试图保持应用程序周围尽可能长的时间,但最终会需要时内存不足移除旧的进程。中所述活动的生命周期,对此过程以除去决定紧密联系在一起的用户的与它相互作用的状态。在一般情况下,有四个状态的方法,可以根据在其上运行的活动,在重要性的顺序排列。它诉诸杀戮更重要的进程(第一批),系统会先杀死不太重要进程(最后的)。
的前台活动(在该用户当前交互的屏幕的顶部的活性)被认为是最重要的。其过程将只被杀死作为最后的手段,如果使用更多的内存比可用设备上。通常在此点装置已达到一个存储器寻呼状态,所以这是为了保持用户界面响应必需的。
一个可见的活动(即对用户可见,但不是在前台的活动,例如一个坐在前台后面的对话),被认为是非常重要的,除非必须保持在前台运行的活动将不会被杀死。
一个背景活动(活动是对用户不可见,并已暂停)已不再是关键,所以系统可以安全地杀死它的进程回收内存为其他前景或可见的过程。如果其进程需要被杀害,当用户返回到活动(使它显示在屏幕上再次),它 的onCreate(束)
方法将它在此前提供的savedInstanceState调用的onSaveInstanceState(包)
,使它可以重新启动它本身在相同的状态作为用户最后离开它。
一个空的过程中一个没有举办活动或其他应用程序组件(如服务
或 广播接收器
类)。这些是由系统杀死非常快地存储器变低。出于这个原因,你的活动以外做任何后台操作必须以活动的BroadcastReceiver或服务的上下文中执行,以确保系统知道它需要保持你的进程各地。
服务
中上传发生。这允许系统的过程中进行适当的优先次序(考虑它为比其它非可见应用更为重要),用于上载的,独立的原始活性是否被暂停的持续时间,停止或结束。