Android的Activity详解
本文总结了网络上的一些文章,进行总结归纳纠错。详细介绍了Activity的生命周期、通信方式、Intent
Filter等内容。
Activity生命周期
在android中,Activity有四个基本状态:
1. Active:在我们start了一个新的Activity之后,此时activity可见可操作。在代码中,是在onResume执行完毕之后,也就是说onResume和onPause之间的状态是active的。
2. Pause:当Activity在代码中弹出一个Dialog,或者被一个透明的activity,或者dialog风格的activity所覆盖。这时会调用到onPause。
3. Stopped:当Activity调用finish,或者按back键,或者完全被另一个activity覆盖、失去焦点不可见
4. Killed:Activity被系统回收。这里的话,onDestory在一般情况下是不会被调用到的。只有被系统回收时才会被调用到。
一个Activity实例被创建、销毁、或者启动另一个Activity时,它会在这四种状态中转换。
下面引用网络上的图片:这里红色框需要注意,在lowmemory的情况下可能会出现。不是一定出现的。这部分需要太特别注意。我以前也被忽悠过。这图没什么问题,只是说话说一半。给很多人造成了误解。
正常的说,在桌面上,startActivity就会调到onCreate。我们启动了一个activity,按back键退出,就会调用到onStop。所以,onCreate后,再start一定会调用onCreate。
process is killed-----在activity的onPause状态时,因为lowmemory被杀掉才会去onCreate。

onCreate:第一次创建。在这个里,一般情况下是create
views, bind data to lists. Restore from the activity’s previously frozen state, if there was one.
onRestart: Called after your activity has been stopped, prior to it being. Always followed by onStart()
onStart: Called when the activity is becoming visible to the user.
onResume: Called when the activity will start interacting with the user. At this point your activity is at the top of the activity stack,
with user input going to it. ---- write any persistent data (such as user edits) * to storage.
onPause: Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent
data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns.
onStop: Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This
may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed.---- Starting with Honeycomb, an application is not in
the killable state until its {@link #onStop} has returned.
onDestroy: The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone
called {@link Activity#finish} on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the {@link Activity#isFinishing} method.
onSaveInstanceState: called before placing the activity in such a background
state, allowing you to save away any dynamic instance state in your activity into the given Bundle.
the activity's process will not be killed by the system starting from the time the method is called and continuing after it returns. Thus an activity is in the killable
state, for example, between after onPause() to the start of onResume().
*
If the configuration of the device (as defined by the
* {@link Configuration Resources.Configuration} class) changes,
* then anything displaying a user interface will need to update to match that
* configuration. Because Activity is the primary mechanism for interacting
* with the user, it includes special support for handling configuration
* changes.
*
*
Unless you specify otherwise, a configuration change (such as a change
* in screen orientation, language, input devices, etc) will cause your
* current activity to be destroyed, going through the normal activity
* lifecycle process of {@link #onPause},
* {@link #onStop}, and {@link #onDestroy} as appropriate. If the activity
* had been in the foreground or visible to the user, once {@link #onDestroy} is
* called in that instance then a new instance of the activity will be
* created, with whatever savedInstanceState the previous instance had generated
* from {@link #onSaveInstanceState}.
*
*
This is done because any application resource,
* including layout files, can change based on any configuration value. Thus
* the only safe way to handle a configuration change is to re-retrieve all
* resources, including layouts, drawables, and strings. Because activities
* must already know how to save their state and re-create themselves from
* that state, this is a convenient way to have an activity restart itself
* with a new configuration.
*
*
In some special cases, you may want to bypass restarting of your
* activity based on one or more types of configuration changes. This is
* done with the {@link android.R.attr#configChanges android:configChanges}
* attribute in its manifest. For any types of configuration changes you say
* that you handle there, you will receive a call to your current activity's
* {@link #onConfigurationChanged} method instead of being restarted. If
* a configuration change involves any that you do not handle, however, the
* activity will still be restarted and {@link #onConfigurationChanged}
* will not be called.
当你通过startActivity打开了一个activity,当你start的activity
crash后,信息会返回到parent’s activity,同时这个值是RESULT_CANCELED.
*
The foreground activity (the activity at the top of the screen
* that the user is currently interacting with) is considered the most important.
* Its process will only be killed as a last resort, if it uses more memory
* than is available on the device. Generally at this point the device has
* reached a memory paging state, so this is required in order to keep the user
* interface responsive.
*
A visible activity (an activity that is visible to the user
* but not in the foreground, such as one sitting behind a foreground dialog)
* is considered extremely important and will not be killed unless that is
* required to keep the foreground activity running.
*
A background activity (an activity that is not visible to
* the user and has been paused) is no longer critical, so the system may
* safely kill its process to reclaim memory for other foreground or
* visible processes. If its process needs to be killed, when the user navigates
* back to the activity (making it visible on the screen again), its
* {@link #onCreate} method will be called with the savedInstanceState it had previously
* supplied in {@link #onSaveInstanceState} so that it can restart itself in the same
* state as the user last left it.
*
An empty process is one hosting no activities or other
* application components (such as {@link Service} or
* {@link android.content.BroadcastReceiver} classes). These are killed very
* quickly by the system as memory becomes low. For this reason, any
* background operation you do outside of an activity must be executed in the
* context of an activity BroadcastReceiver or Service to ensure that the system
* knows it needs to keep your process around.
Activity栈
Acitivity是通过栈来管理的。大家都知道栈是弹出,压入。
以下为引用
现有一项测试步骤:包含三个activity分别是:A,B,C;启动顺序为A-->B-->C
首先启动A,那么这个A就是执行这个任务的根activity,任务也是定义在这个activity下的。通过属性Manifest文件中的activity属性中的taskAffinity来定义。
(1)此时A启动后就被压入堆栈,因为此时堆栈中只有这一个activity,所以A处于栈底,也处于栈顶。此时用户能够看到的就是A界面。
(2)A启动B后,B入栈。此时栈顶为B。B呈现的界面将A覆盖,A进入后台运行(此时是activity生命周期的pause状态)或者进入后台但不运行(此时是activity生命周期的stop状态)。
(3)B启动C后,C入栈。此时栈顶为C。C呈现的界面将B覆盖,B进入后台运行。
(4)按back键后就是调用finish函数结束C (activity)的生命。此时C出栈,C的生命周期结束。
(5)继续back键,结束B的生命,此时B出栈。
(6)继续back键,结束A的生命,此时A出栈。
(7)此时栈内所有activity都已出栈,所以就会显示HOME屏幕界面.
总结下,特别需要注意的是,在栈中的任何activity都可能被回收!默认情况下,一个 Activity 的实例越是处在栈的底层,它被系统回收的可能性越大。出于严谨的态度来说,内存回收是有级别的,存在先后顺序,这里都是activity不做讨论。
栈顶被回收,一般在一些ram很小的机子上会出现,客户很变态,ram小还要装一大堆软件。一些不规范的软件会常驻内存。那么,就会出现部分软件在使用过程中,被强制关闭的现象。
Activity之间通信
以下引用部分
在 Android 中,不同的 Activity 实例可能运行在一个进程中,也可能运行在不同的进程中。因此我们需要一种特别的机制帮助我们在 Activity 之间传递消息。Android 中通过 Intent 对象来表示一条消息,一个 Intent 对象不仅包含有这个消息的目的地,还可以包含消息的内容,这好比一封 Email,其中不仅应该包含收件地址,还可以包含具体的内容。对于一个 Intent 对象,消息“目的地”是必须的,而内容则是可选项。
在上面的实例中通过