Activity组件

AndroidActivity详解

本文总结了网络上的一些文章,进行总结归纳纠错。详细介绍了Activity的生命周期、通信方式、Intent Filter等内容。

 

Activity生命周期

android中,Activity有四个基本状态:

1.       Active:在我们start了一个新的Activity之后,此时activity可见可操作。在代码中,是在onResume执行完毕之后,也就是说onResumeonPause之间的状态是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-----activityonPause状态时,因为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,当你startactivity 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.

 *

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.

 *

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界面。

        2A启动B后,B入栈。此时栈顶为BB呈现的界面将A覆盖,A进入后台运行(此时是activity生命周期的pause状态)或者进入后台但不运行(此时是activity生命周期的stop状态)。

        3B启动C后,C入栈。此时栈顶为CC呈现的界面将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 对象,消息目的地是必须的,而内容则是可选项。

在上面的实例中通过

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值