Android四大组件

最新推荐文章于 2024-07-30 21:29:03 发布

顾缘君兮

最新推荐文章于 2024-07-30 21:29:03 发布

阅读量339

点赞数 1

分类专栏：面试文章标签： android

原文链接：https://blog.csdn.net/qq_29966203/article/details/90751361

版权

面试专栏收录该内容

28 篇文章 1 订阅

订阅专栏

Android四大组件

Activity（活动）

是android程序与用户交互的窗口，可以显示一些空间用于监听并处理用户的事件

生命周期

有四个状态、七个方法、两个异常

四个状态

Running：处于栈的最顶端，此时处于不可见并可和用户交互的激活状态

Paused:当Activity被另一个透明的或者Dialog样式的Activity覆盖时的状态，此时仍然可见，但失去了焦点，不可与用户交互

Stopped:Activity完全不可见，处于后台，但仍保留着当前状态和成员信息

Killed:当前界面被销毁，等待被系统回收

七个方法

onCreate():在Activity创建时调用。一般用来做一些初始化操作，如初始化布局setContentLayout()

onStart():在Activity即将显示界面时调用，但用户无法操作。一般也用于做一些初始化操作，但对于Activity而言，onCreate只执行一次，但onStart可执行多次。

onResume():在Activity获取焦点开始与用户交互时调用，此时Activity处于运行状态，位于栈顶。一般用于数据恢复、开启动画等

onPause():在当前Activity被其他Activity覆盖部分或锁屏时调用，此时Activity处于暂停状态，仍然可见，但失去焦点，不能与用户交互。一般用于关闭动画，注销广播等。并应进行状态保存与数据存储，但不适合做耗时操作。（为了让新的Activity尽快切换到前台）

onStop():在Activity对用户完全不可见时调用，此时Activity处于停止状态。此时进程优先级较低，当系统内存不足时，容易被杀死。一般用于进行资源回收。

onDestory():在Activity销毁时调用，常用于释放资源，Activity处于销毁状态后，将被清出内存。

onRestart():在Activity从停止状态再次启动时调用。onRestart一般是应用位于后台重新切换为前台调用，可用于进行数据刷新。其中onCreate() & onDestory()、onStart() & onStop()、onResume() & onPause()成对出现。

两个异常

更高优先级的进程需要内存，但系统内存不足

处于暂停或停止状态（低优先级）的Activity可能会被直接杀死

手动重启当前Activity–>onCreate()–>onStart()–>onResume()–>运行

系统配置发生改变导致Activity意外销毁（如横竖屏切换、键盘事件等）

运行–>onSaveInstanceState()–>onPause()–>onStop()–>onDestory()–>自动重启–>onCreate()–>onStart()–>onRestoreInstanceState()–>onResume()–>运行

在onSaveInstanceState()保存Activity状态，适合保存一些非持久数据，如布局状态、成员变量的值等，持久数据适合在onPause()和onStop()中通过数据库、sharedpreference保存

在onRestoreInstanceState()或onCreate()恢复Activity状态

参数传递

传递基本数据类型putExtra

传递多种数据类型Bundle

传递自定义对象，实现Serializable接口

startActivityForResult

使用EventBus插件传输数据量较大的数据

借助外部存储，如SharedPreference

启动过程

启动模式

standard(标准模式)

只要启动一次Activity，不管该实例是否存在，系统都会在当前任务栈中新建一个Activity实例并将该实例置于栈顶

singleTop(栈顶复用模式)

如果要启动的Activity已经处于栈的顶部，那么此时系统不会创建新的实例，而是复用栈顶的实例，同时它的onNewIntent()方法会被执行，我们可以通过Intent进行传值。否则会创建一个新的实例。
SingleTop适用于接受推送通知的内容显示页面，防止每点击一次通知重新打开重复页面。

singleTask(栈内复用模式)

首先会根据taskAffinity去寻找对应的任务栈：
1、如果不存在指定的任务栈，系统会新建对应的任务栈，并新建一个Activity实例压入栈中。
2、如果存在指定的任务栈，则会查找该任务栈中是否存在该Activity实例
a、如果不存在该实例，则会在该任务栈中新建一个Activity实例压入栈中。
b、如果存在该实例，则将任务栈中该Activity实例之上的所有Activity出栈并将所需Activity置于栈顶。
SingleTask这种启动模式最常使用的就是一个APP的首页，因为一般为一个APP的第一个页面，且长时间保留在栈中，所以最适合设置singleTask启动模式来复用。

singleInstance(单例模式)

拥有singleTask（栈内复用）所有特性外且该Activity实例单独占用一个任务栈，具有全局唯一性。该模式启动的activity在系统中是单例的。如果已存在，则将它所在的任务栈调度到前台，进行复用。
适用于与程序分开，具有独立功能的页面，如闹铃提醒，电话拨号等

Service（服务）

提供需要在后台长期运行的服务，无用户界面。一个组件可以与一个Service进行绑定实现组件之间的交互，可以在后台执行很多任务，如处理网络事务，播放音乐，文件读写下载等

启动方式

startService()，调用者与Service没有关联，只有Service调用stopSelf()或者调用者调用stopService()才能停止服务

bindService()，调用者与Service绑定，可以与Service进行交互，当所有调用者退出后，Service自动停止

生命周期

onStartCommand():其他组件(如活动)通过调用startService()来请求启动服务时，系统调用该方法

onBind():其他组件(如活动)通过调用bindService()来请求启动服务时，系统调用该方法

onUnbind():当客户中断所有服务发布的特殊接口时，系统调用该方法

onCreate()：当服务通过onStartCommand()和onBind()被第一次创建的时候，系统调用该方法

onDestory()：当服务不再有用或者被销毁时，系统调用该方法。你的服务需要实现该方法来清理任何资源，如线程，已注册的监听器，接收器等

使用场景

提高进程的优先级，系统不容易回收进程，适合长期在后台运行的操作

分类

不可交互的后台服务：通过startService()方式开启。Service的生命周期很简单，分别为onCreate、onStartCommand、onDestroy

可交互的后台服务：前台页面可以调用后台服务的方法，通过bindService()方式开启。Service的生命周期很简单，分别为onCreate、onBind、onUnBind、onDestroy

前台服务：通过一定的方式将服务所在的进程级别提升了。前台服务会一直有一个正在运行的图标在系统的状态栏显示，非常类似于通知的效果。由于后台服务优先级相对比较低，当系统出现内存不足的情况下，它就有可能会被回收掉，所以前台服务就是来弥补这个缺点的，它可以一直保持运行状态而不被系统回收。

Service和Activity通信

bindService + 回调函数

Activity调用bindService方法，绑定一个Service。通过实例化ServiceConnection接口内部类监听的方法获取Service中的Binder对象,并将该接口传给binderService方法。如果想实现主动通知Activity的，还可以在Service中添加回调方法。

广播(推荐LocalBroadcastManager)

Activity调用registerReceiver注册广播接收器，通过startService启动一个Service,之后Service调用sendBoardcast向Activity发送广播，Activity则通过onReceive方法接收Service发送的消息

Content Provider（内容提供者）

是官方推荐的不同应用程序间进行数据交互和共享的方式。为存储和获取数据提供统一的接口，相当于数据的搬运工，真正的数据源是Sqlite/文件/XML/网络等

它一般为存储和获取数据提供统一的接口，可以在不同的应用程序之间共享数据

设计目的在于：对底层数据库的抽象，提供一种跨进程数据共享方式，用安全的方式对数据进行封装

使用原理：内容提供者是一种跨应用访问数据库的方式，一个应用可以通过内容提供者将自己的私有数据暴露出来，其他应用通过内容解析者对数据进行增删改查

使用场景：由于内容提供者是向其他应用暴露数据库接口，不能保证应用所定义的数据库的安全性。因此不用于自定义数据库，适用于获取系统数据库的接口，如短信数据库，联系人数据库

Broadcast Receiver（广播接收器）

相当于一个全局监听器，用于接收应用间/应用内发出的广播信息，并做出响应

分为广播发送者和广播接收者。

系统在特定场景会发送广播，如电量低、插入耳机等，每个应用都会收到，应用程序也可以发送广播来通知其他app状态变化

原理

广播使用的是设计模式中的观察者模式，基于消息的发布/订阅事件模型。模型中有三个角色：消息订阅者（广播接受者），消息发布者（广播发布者），消息中心（AMS）

1.广播接收者通过Binder机制在AMS注册

2.广播发送者通过Binder机制向AMS发送广播

3.AMS根据广播发送者的要求，在已注册列表中寻找合适的广播接收者

4.AMS将广播发送到合适的广播接收者相应的消息循环队列中

5.广播接收者通过消息循环拿到此广播，回调onReceive()

注册方式

静态注册

动态注册

使用方式

发送广播

接收广播

屏蔽广播

Context

上下文，提供了关于应用环境全局信息的接口，可以通过这个接口获取应用程序的资源和类，可以进行应用级别的操作，如启动Activity,弹出对话框，启动服务，发送广播，加载资源等

继承关系：Context是一个抽象类，具体实现类是ContextImpl，包装类是ContextWrapper。Activity,Application,Service继承自ContextWrapper,初始化过程会创建一个具体的ContextImpl实例，由ContexxtImpl实现Context中的方法。ContextThemeWrapper继承自ContextWrapper,相当于ContextWrapper添加了与主题相关的接口。Application和Service直接继承自ContextWrapper，Activity直接继承自ContextThemeWrapper

内存泄漏：一般Context造成的内存泄漏，是当Context销毁的时候，因为被引用而导致销毁失败。

而Application的Context对象可以理解为随着进程存在，所以：

生命周期长的对象，优先使用Application的Context

不要让生命周期长于Activity的对象持有Activity的引用

尽量不要在Activity中使用非静态内部类