Android学习笔记

疯狂Android讲义


文章目录

  • Android学习笔记
  • 疯狂Android讲义
  • 第1章 Android 应用和开发环境
  • 1.7 Android应用的基本组件介绍
  • 1.7.1 Activity和View
  • 1.7.2 Service
  • 1.7.3 BroadcastReceiver
  • 1.7.4 ContentProvider
  • 1.7.5 Intent与IntentFilter


第1章 Android 应用和开发环境

1.7 Android应用的基本组件介绍

1.7.1 Activity和View

Activity是 Android应用中负责与用户交互的组件，只能通过setContentView(View)来显示指定组件。

View组件是所有UI控件、容器控件的基类，View组件就是Android应用中用户实实在在看到的部分。但View组件需要放到容器组件中，或者使用Activity将它显示出来。如果需要通过某个Activity把指定View显示出来，调用Activity的setContentView()方法即可。

//创建一个线性布局管理器
LinearLayout layout = new LinearLayout(this);
//设置该Activity显示layout
setContentView(layout);
//设置Activity显示activity_main.xml文件定义的view
setContentView(R.layout.activity_main);

实际上Activity是Window的容器，Activity包含一个getWindow()方法,该方法返回该Activity所包含的窗口。对于Activity而言，开发者一般不需要关心 Window对象。如果应用程序不调用Activity 的 setContentView()来设置该窗口显示的内容，那么该程序将显示一个空窗口。

android组件化 缺点 安卓中什么是组件_学习

Activity为 Android应用提供了可视化用户界面，如果该Android应用需要多个用户界面，那么这个Android应用将会包含多个Activity，多个Activity组成Activity栈，当前活动的Activity位于栈顶。

Activity包含了一个setTheme(int resid)方法来设置其窗口的风格。

1.7.2 Service

Service 与Activity的地位是并列的，它也代表一个单独的Android组件。Service与Activity的区别在于:Service通常位于后台运行，它一般不需要与用户交互，因此Service组件没有图形用户界面。

与Activity组件需要继承Activity基类相似，Service组件需要继承Service基类。一个 Service组件被运行起来之后，它将拥有自己独立的生命周期，Service组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。

1.7.3 BroadcastReceiver

BroadcastReceiver 是Android应用中另一个重要的组件，顾名思义，BroadcastReceiver 代表广播消息接收器。从代码实现角度来看，BroadcastReceiver非常类似于事件编程中的监听器。与普通事件监听器不同的是，普通事件监听器监听的事件源是程序中的对象;而 BroadcastReceiver 监听的事件源是Android应用中的其他组件，因此 BroadcastReceiver相当于一个全局的事件监听器。
使用BroadcastReceiver组件接收广播消息比较简单，开发者只要实现自己的BroadcastReceiver子类，并重写onReceive(Context context,Intent intent)方法即可。当其他组件通过sendBroadcast()、sendStickyBroadcast()或sendOrderedBroadcast()方法发送广播消息时，如果该BroadcastReceiver也对该消息“感兴趣”(通过IntentFilter配置)，BroadcastReceiver的 onReceive(Context context, Intent intent)方法将会被触发。

开发者实现了自己的 BroadcastReceiver 之后，通常有两种方式来注册这个系统级的“事件监听器”。

  • 动态注册
    在Java或Kotlin代码中通过Context.registReceiver()方法注册 BroadcastReceiver。
  • 静态注册
    在 AndroidManifest.xml文件中使用<receiver…/>元素完成注册。
1.7.4 ContentProvider

对于Android应用而言，它们必须相互独立，各自运行在自己的进程中，如果这些Android应用之间需要实现实时的数据交换——例如,我们开发了一个发送短信的程序，当发送短信时需要从联系人管理应用中读取指定联系人的数据——这就需要多个应用程序之间进行数据交换。
Android系统为这种跨应用的数据交换提供了一个标准:ContentProvider。当用户实现自己的ContentProvider 时，需要实现如下抽象方法。

  • insert(Uri, ContentValues):向 ContentProvider插入数据。
  • delete(Uri, ContentValues):删除 ContentProvider 中指定数据。
  • update(Uri, ContentValues, String, String[D):更新ContentProvider 中指定数据。
  • query(Uri,String[], String, String[],String):从 ContentProvider查询数据。

通常与ContentProvider结合使用的是 ContentResolver，一个应用程序使用 ContentProvider暴露自己的数据，而另一个应用程序则通过 ContentResolver来访问数据。

1.7.5 Intent与IntentFilter

Intent并不是Android应用的组件，但它对于Android应用的作用非常大——它是 Android应用内不同组件之间通信的载体。当Android运行时需要连接不同的组件时,通常就需要借助于Intent来实现。Intent 可以启动应用中另一个Activity，也可以启动一个 Service组件，还可以发送一条广播消息来触发系统中的 BroadcastReceiver。也就是说，Activity、Service、BroadcastReceiver三种组件之间的通信都以Intent作为载体，只是不同组件使用Intent 的机制略有区别而已。

  • 当需要启动一个 Activity时，可调用 Context 的 startActivity (Intent intent)或startActivityForResult(Intent intent, int requestCode)方法，这两个方法中的Intent参数封装了需要启动的目标Activity的信息。
  • 当需要启动一个 Service时，可调用 Context的 startService(Intent intent)方法或 bindService(Intent service, ServiceConnection conn, int flags)方法，这两个方法中的Intent参数封装了需要启动的目标 Service的信息。
  • 当需要触发一个 BroadcastReceiver 时，可调用 Context 的 sendBroadcast(Intent intent)、sendStickyBroadcast(Intent intent)或sendOrderedBroadcast(Intent intent,String receiverPermission)方法来发送广播消息,这三个方法中的 Intent参数封装了需要触发的目标BroadcastReceiver的信息。

Intent封装了当前组件需要启动或触发的目标组件的信息。

当一个组件通过Intent表示了启动或触发另一个组件的“意图”之后，这个意图可分为两类。

  • 显式 Intent:显式 Intent 明确指定需要启动或者触发的组件的类名。
    对于显式 Intent而言，Android系统无须对该Intent做任何解析，系统直接找到指定的目标组件，启动或触发它即可。
  • 隐式Intent:隐式 Intent 只是指定需要启动或者触发的组件应满足怎样的条件。
    对于隐式 Intent而言，Android系统需要对该Intent进行解析，解析出它的条件，然后再去系统中查找与之匹配的目标组件。如果找到符合条件的组件，就启动或触发它们。

Android系统如何判断被调用组件是否符合隐式Intent呢?这就需要靠IntentFilter 来实现了,被调用组件可通过IntentFilter 来声明自己所满足的条件——也就是声明自己到底能处理哪些隐式Intent。