📷 前言 距离上次更新过去一周多了,打破了之前两到三天一更的惯例,主要还是要研究的东西太杂了 本篇文章将对 BroadcastReceiver 开发中,可能用到的知识点,可能遇到的问题进行总结。 希望本文能帮助你揭开 Android 开发过程中的难题。 最后,希望大家都能有所收获,欢迎食用! 文章目录 ---- 📷 方便大家学习,我在 GitHub 上建立个 仓库 ---- 仓库内容与博客同步更新。由于我在 稀土掘金 简书 CSDN 博客园 等站点,都有新内容发布。所以大家可以直接关注该仓库,以免错
BroadcastReceiver(广播接收器),在Android开发中,BroadcastReceiver的应用场景非常多,属于Android四大组件之一。
Android程序中耗电最多的地方在以下几个方面 : 1、 大数据量的传输。 2、 不停的在网络间切换。 3、 解析大量的文本数据。 那么我们怎么样来改善一下我们的程序呢? 1、 在需要网络连接的程序中,首先检查网络连接是否正常,如果没有网络连接,那么就不需要执行相应的程序。 检查网络连接的方法如下: [*]ConnectivityManager mConnectivity; [*]TelephonyManager mTelephony; [*]…… [*]// 检查网络连接,如果无网络
检查设备的网络连接 设备可以有许多种网络连接。这节主要关注使用 Wi-Fi 或移动网络连接的情况。关于所有可能的网络连接类型,请看ConnectivityManager。通常 Wi-Fi 是比较快的。移动数据通常都是需要按流量计费,会比较贵。通常我们会选择让 app 在连接到 WiFi 时去获取大量的数据。 在执行网络操作之前,检查设备当前连接的网络连接信息是个好习惯。这样可以防止我们的程序在无意间连接使用了非意向的网络频道。如果网络连接不可用,那么我们的应用应该优雅地做出响应。为了检测网络连接,我们需要使
Android 中的广播使用了设计模式中的观察者模式:基于消息的发布/订阅事件模型。
前言:最近公司项目重构,为了提高用户的体验,项目中要求添加当前网络状态的实时监听,以便在无网络状态时给用户友好的提醒并修改UI界面。本文将介绍使用四大组件之一的BroadcastReceiver实现全局的网络状态监听,使用动态方式注册。
Android有四大组件:Activity、Service、Broadcast Receiver、ContentProvider。 Activity 做一个完整的Android程序,不想用到Activity,真的是比较困难的一件事情,除非是想做绿叶想疯了。因为Activity是Android程序与用户交互的窗口,在我看来,从这个层面的视角来看,Android的Activity特像网站的页面。 Activity,在四大组件中,无疑是最复杂的,这年头,一样东西和界面挂上了勾,都简化不了,想一想,独立做一个应用有多少时间沦落在了界面上,就能琢磨清楚了。从视觉效果来看,一个Activity占据当前的窗口,响应所有窗口事件,具备有控件,菜单等界面元素。从内部逻辑来看,Activity需要为了保持各个界面状态,需要做很多持久化的事情,还需要妥善管理生命周期,和一些转跳逻辑。对于开发者而言,就需要派生一个Activity的子类,然后埋头苦干上述事情。对于Activity的更多细节,先可以参见:reference/android/app/Activity.html。后续,会献上更为详尽的剖析。 Service 服务,从最直白的视角来看,就是剥离了界面的Activity,它们在很多Android的概念方面比较接近,都是封装有一个完整的功能逻辑实现,只不过Service不抛头露脸,只是默默无声的做坚实的后盾。 但其实,换个角度来看,Android中的服务,和我们通常说的Windows服务,Web的后台服务又有一些相近,它们通常都是后台长时间运行,接受上层指令,完成相关事务的模块。用运行模式来看,Activity是跳,从一个跳到一个,呃...,这有点像模态对话框(或者还像web页面好了...),给一个输入(抑或没有...),然后不管不顾的让它运行,离开时返回输出(同抑或没有...)。 而Service不是,它是等,等着上层连接上它,然后产生一段持久而缠绵的通信,这就像一个用了Ajax页面,看着没啥变化,偷偷摸摸的和Service不知眉来眼去多少回了。 但和一般的Service还是有所不同,Android的Service和所有四大组件一样,其进程模型都是可以配置的,调用方和发布方都可以有权利来选择是把这个组件运行在同一个进程下,还是不同的进程下。这句话,可以拿把指甲刀刻进脑海中去,它凸显了Android的运行特征。如果一个Service,是有期望运行在于调用方不同进程的时候,就需要利用Android提供的RPC机制,为其部署一套进程间通信的策略。 Android的RPC实现,如上图所示(好吧,也是从SDK中拿来主义的...),无甚稀奇,基于代理模式的一个实现,在调用端和服务端都去生成一个代理类,做一些序列化和反序列化的事情,使得调用端和服务器端都可以像调用一个本地接口一样使用RPC接口。 Android中用来做数据序列化的类是Parcel,参见:/reference/android/os/Parcel.html,封装了序列化的细节,向外提供了足够对象化的访问接口,Android号称实现非常高效。 还有就是AIDL (Android Interface Definition Language),一种接口定义的语言,服务的RPC接口,可以用AIDL来描述,这样,ADT就可以帮助你自动生成一整套的代理模式需要用到的类,都是想起来很乏力写起来很苦力的那种。更多内容,可以再看看:guide/developing/tools/aidl.html,如果有兴致,可以找些其他PRC实现的资料lou几眼。 关于Service的实现,还强推参看APIDemos这个Sample里面的RemoteService实现。它完整的展示了实现一个Service需要做的事情:那就是定义好需要接受的Intent,提供同步或异步的接口,在上层绑定了它后,通过这些接口(很多时候都是RPC的...)进行通信。在RPC接口中使用的数据、回调接口对象,如果不是标准的系统实现(系统可序列化的),则需要自定义aidl,所有一切,在这个Sample里都有表达,强荐。 Service从实现角度看,最特别的就是这些RPC的实现了,其他内容,都会接近于Activity的一些实现,也许不再会详述了。 Broadcast Receiver 在实际应用中,我们常需要等,等待系统抑或其他应用发出一道指令,为自己的应用擦亮明灯指明方向。而这种等待,在很多的平台上,都会需要付出不小的代价。 比如,在Symbian中,你要等待一个来电消息,显示归属地之类的,必须让自己的应用忍辱负重偷偷摸摸的开机启动,消隐图标隐藏任务项,潜伏在后台,监控着相关事件,等待转瞬即逝的出手机会。这是一件很发指的事情,不但白白耗费了系统资源,还留了个流氓软件的骂名,这真是卖力不讨好的正面典型。 在Android中,充分考虑了广泛的这类需
背景 广播作为Android 四大组件有非常广泛的用途。广播可以用作进程间通信,也会用作进程内部某些组件内消息的传递。 这就会有个问题,如果想让发送的广播只有我自己能收到,不想被别人劫持到,来获取到广播中的敏感信息。 另外其他人如果发送相同Action的广播来伪造真正的广播,就会欺骗我的receiver。 如何安全高效的实现进程内部的广播发送呢? 有人说可以使用给广播加权限啊,你可以在Intent中指定PackageName 啊,后面的文章详解,先简单看下: 当应用程序发送某个广播时系统会将发送的Inten
Android 中每个应用程序都可以对自己感兴趣的广播进行注册,这样当注册的广播发出时,应用程序就会接受到。这些广播可能来自系统,也可能来自其他应用程序。
https://source.android.google.cn/devices/tech/connect/wifi-rtt Android 9 中的 WLAN 往返时间 (RTT) 功能允许设备测量与其他支持设备的距离:无论它们是接入点 (AP) 还是 WLAN 感知对等设备(如果设备支持 WLAN 感知功能)。此功能基于 IEEE 802.11mc 协议,使应用能够使用准确性更高的定位功能和增强的感知功能。 在位于 device// 的 device.mk 中,修改 PRODUCT_COPY_FILES 环境变量,以便支持 WLAN RTT 功能:
这时候启动两个程序,都可以接收到按钮发出的消息,这时候还是标准广播,如果要改为有序广播需要在BroadcastTest项目点击事件中更改:
New - > Other ->Broadcast Reciver 新建一个BootCompleteReceiver:
在Activity生命周期管理 以及 插件加载机制 中我们详细讲述了插件化过程中对于Activity组件的处理方式,为了实现Activity的插件化我们付出了相当多的努力;那么Android系统的其他组件,比如BroadcastReceiver,Service还有ContentProvider,它们又该如何处理呢?
frameworks/base/core/java/android/content/ContextWrapper.java
BroadcastReceiver,本质上是一个全局的监听器,属于Android四大组件之一。
小伙伴们,在上文中我们介绍了Android组件Service,本文我们继续盘点介绍Android开发中另一个非常重要的组件BroadcastReceiver。
由对Androidsetting的源码分析之WiFi模块的界面fragment为WiFisettings.java,关于setting模块的源码分析可以参考
ANR (Application Not Responding) ANR定义:在Android上,如果你的应用程序有一段时间响应不够灵敏,系统会向用户显示一个对话框,这个对话框称作应用程序无响应(ANR:Application Not Responding)对话框。用户可以选择“等待”而让程序继续运行,也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr,而让用户每次都要处理这个对话框。因此,在程序里对响应性能的设计很重要,这样系统不会显示ANR给用户。 默认情况下,在android中Activity的最长执行时间是5秒,BroadcastReceiver的最长执行时间则是10秒。 第一:什么会引发ANR? 在Android里,应用程序的响应性是由Activity Manager和WindowManager系统服务监视的 。当它监测到以下情况中的一个时,Android就会针对特定的应用程序显示ANR: 1.在5秒内没有响应输入的事件(例如,按键按下,屏幕触摸) 2.BroadcastReceiver在10秒内没有执行完毕 造成以上两点的原因有很多,比如在主线程中做了非常耗时的操作,比如说是下载,io异常等。 潜在的耗时操作,例如网络或数据库操作,或者高耗时的计算如改变位图尺寸,应该在子线程里(或者以数据库操作为例,通过异步请求的方式)来完成。然而,不是说你的主线程阻塞在那里等待子线程的完成——也不是调用 Thread.wait()或是Thread.sleep()。替代的方法是,主线程应该为子线程提供一个Handler,以便完成时能够提交给主线程。以这种方式设计你的应用程序,将能保证你的主线程保持对输入的响应性并能避免由于5秒输入事件的超时引发的ANR对话框。 第二:如何避免ANR? 1、运行在主线程里的任何方法都尽可能少做事情。特别是,Activity应该在它的关键生命周期方法(如onCreate()和onResume())里尽可能少的去做创建操作。(可以采用重新开启子线程的方式,然后使用Handler+Message的方式做一些操作,比如更新主线程中的ui等) 2、应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。但不再是在子线程里做这些任务(因为 BroadcastReceiver的生命周期短),替代的是,如果响应Intent广播需要执行一个耗时的动作的话,应用程序应该启动一个 Service。(此处需要注意的是可以在广播接受者中启动Service,但是却不可以在Service中启动broadcasereciver,关于原因后续会有介绍,此处不是本文重点) 3、避免在Intent Receiver里启动一个Activity,因为它会创建一个新的画面,并从当前用户正在运行的程序上抢夺焦点。如果你的应用程序在响应Intent广 播时需要向用户展示什么,你应该使用Notification Manager来实现。 总结:anr异常也是在程序中自己经常遇到的问题,主要的解决办法自己最常用的就是不要在主线程中做耗时的操作,而应放在子线程中来实现,比如采用Handler+mesage的方式,或者是有时候需要做一些和网络相互交互的耗时操作就采用asyntask异步任务的方式(它的底层其实Handler+mesage有所区别的是它是线程池)等,在主线程中更新UI。
ANR定义:在Android上,如果你的应用程序有一段时间响应不够灵敏,系统会向用户显示一个对话框,这个对话框称作应用程序无响应(ANR:Application Not Responding)对话框。用户可以选择“等待”而让程序继续运行,也可以选择“强制关闭”。所以一个流畅的合理的应用程序中不能出现anr,而让用户每次都要处理这个对话框。因此,在程序里对响应性能的设计很重要,这样系统不会显示ANR给用户。
当此 App首次启动时,系统会自动实例化mBroadcastReceiver类,并注册到系统中。
接着来介绍一下设置中某个模块的源码,本文依旧是基于Android4.42源码进行分析,分析一下蓝牙模块的实现。建议大致看一下关于Settings的剖析。
Android ANR(Application Not Responding)的分析
Android 应用程序包含了工程文件、代码和各种资源,主要由 Java 语言编写,每一个应用程序将被编译成Android 的一个 Java 应用程序包(*.apk)。
Android对内存的使用方式同样是“尽最大限度的使用”,这一点继承了Linux的优点。只不过有所不同的是,Linux侧重于尽可能多的缓存磁盘数据以降低磁盘IO进而提高系统的数据访问性能,而 Android侧重于尽可能多的缓存进程以提高应用启动和切换速度。Linux系统在进程活动停止后就结束该进程,而Android系统则会在内存中尽量长时间的保持应用进程,直到系统需要更多内存为止 。这些保留在内存中的进程,通常情况下不会影响系统整体运行速度,反而会在用户再次激活这些进程时,加快进程的启动速度,因为不用重新加载界面资源了,这是Android标榜的特性之一。所以,Android现在不推荐显式的“退出”应用。
Android应用可以通过广播从系统或其他App接收或发送消息。类似于订阅-发布设计模式。当某些事件发生时,可以发出广播。 系统在某些状态改变时会发出广播,例如开机、充电。App也可发送自定义广播。广播可用于应用间的通讯,是IPC的一种方式。
BroadcastReceiver 用于接收程序(包含用户开放的程序和系统内建程序)所发出的Broadcast intent
Subject(抽象被观察者):抽象主题角色把所有观察者对象的引用保存在一个集合里,并提供可以增加和删除观察者的接口。
通常来讲,这个广播会被所有注册这个action的receiver接收到。即便是在Android O版本,还有两类receiver仍然会接收这个广播:
例如,HTTP 请求、下载文件、访问REST API等。网络操作通常需要较长的时间,尤其在网络条件不好的情况下。
只需要实现下面2段代码即可实现对网络连接状态的监听,千万别忘了在Manifest.xml里面添加网络访问权限哦。
Service是android 系统中的四大组件之中的一个(Activity、Service、BroadcastReceiver、ContentProvider),它跟Activity的级别差点儿相同,但不能自己执行仅仅能后台执行,而且能够和其它组件进行交互。service能够在非常多场合的应用中使用,比方播放多媒体的时候用户启动了其它Activity这个时候程序要在后台继续播放,比方检測SD卡上文件的变化,再或者在后台记录你地理信息位置的改变等等,总之服务总是藏在后台的。
一、Broadcast(广播) 在Android中,有一些操作完成以后,会发送广播,比如说发出一条短信,或打出一个电话,如果某个程序接收了这个广播,就会做相应的处理。这个广播跟我们传统意义中的电台广播有些相似之处。之所以叫做广播,就是因为它只负责“说”而不管你“听不听”,也就是不管你接收方如何处理。另外,广播可以被不只一个应用程序所接收,当然也可能不被任何应用程序所接收。 (百度百科) 二、BroadcastReceiver(广播接收器) 1、自定义BroadcastReceiver 自定义广播接收器继承基
Activity 是Android应用程序中最基本的组件,表示一个屏幕用户界面。每个Activity通常对应一个UI,用来与用户交互。Activity是用户和应用的直接交互窗口,它负责管理和处理应用的UI部分。
本文源自:http://blog.csdn.net/liuhe688/article/details/6955668
Service是android 系统中的四大组件之一(Activity、Service、BroadcastReceiver、ContentProvider),它跟Activity的级别差不多,但不能自己运行只能后台运行,并且可以和其他组件进行交互。service可以在很多场合的应用中使用,比如播放多媒体的时候用户启动了其他Activity这个时候程序要在后台继续播放,比如检测SD卡上文件的变化,再或者在后台记录你地理信息位置的改变等等,总之服务总是藏在后台的。
1.添加jar包,在app目录下新建libs文件夹,拷入jar文件并Add As Library
Broadcast 在Android中 Broadcast是一种 广泛运用在引用程序之间传输信息的机制。 而BroadcastReceiver 是对发送出来的Broadcaset进行过滤接受并响应的一类组件。 如果不需发送广播到别的应用 使用 LocalBroadcastManger就可以了。 发送和接收流程 发送和接受的过程: 发送 首先在需要发送信息的地方 ,把要发送的信息和用于过滤的信息(如action 和 category)封装进intent对象,然后调用 Context.sendBroadcast
蓝牙是一种短距离无线通信技术,它由爱立信公司于1994年创制,原本想替代连接电信设备的数据线,但是后来发现它也能用于移动设备之间的数据传输,所以蓝牙技术在手机上获得了长足发展。 因为手机内部的通讯芯片一般同时集成了2G/3G/4G、WIFI和蓝牙,所以蓝牙功能已经是智能手机的标配了。若想进行蓝牙方面的开发,需要在App工程的AndroidManifest.xml中补充下面的权限配置:
几乎每个安卓应用都无可避免的使用到广播。例如监听WIFI的开启状态、时间的获取,甚至是我们最常用的闹钟功能,都是结合着AlarmManager与广播来实现的。理解广播的注册、发送与接收实现源码将使我们更加懂安卓系统,同时,基于对广播的理解,我们也能很快的掌握AMS中其它组件的实现原理。
桌面控件是通过BroadcastReceiver的形式进行控制的,因此每个桌面控件都对应于一个BroadcastReceiver。开发桌面控件时,只需继承BroadcastReceiver的子类APPWidgetProvider,并重写APPWidgetProvider不同状态的生命周期方法即可。
广播(Broadcast)用于Android组件之间的灵活通信,它与Activity和Service的区别在于: 1、Activity和Service都只能一对一地通信,而Broadcast可以一对多,一人发送广播,多人接收处理; 2、对于发送者来说,广播不需要考虑接收者有没有在工作,接收者有在工作则接收广播,不在工作则丢弃广播; 3、对于接收者来说,会收到各式各样的广播,所以接收者首先要自行过滤符合条件的,然后才能进行解包处理; 4、通常情况下,Activity和Service都是在线程内部通信,而Broadcast既可用于线程内通信,也可用于线程间通信,还能用于进程间通信;
1 关于sendBroadcast()方法说法正确的是( A ) A、该方法是发送一条无序广播 B、该方法是发送一条有序广播 C、该方法即是发送有序广播也可以发送无序广播 D、以上说法都不正确
《移动互联网技术》课程是软件工程、电子信息等专业的专业课,主要介绍移动互联网系统及应用开发技术。课程内容主要包括移动互联网概述、无线网络技术、无线定位技术、Android应用开发和移动应用项目实践等五个部分。移动互联网概述主要介绍移动互联网的概况和发展,以及移动计算的特点。无线网络技术部分主要介绍移动通信网络(包括2G/3G/4G/5G技术)、无线传感器网络、Ad hoc网络、各种移动通信协议,以及移动IP技术。无线定位技术部分主要介绍无线定位的基本原理、定位方法、定位业务、数据采集等相关技术。Android应用开发部分主要介绍移动应用的开发环境、应用开发框架和各种功能组件以及常用的开发工具。移动应用项目实践部分主要介绍移动应用开发过程、移动应用客户端开发、以及应用开发实例。 课程的教学培养目标如下: 1.培养学生综合运用多门课程知识以解决工程领域问题的能力,能够理解各种移动通信方法,完成移动定位算法的设计。 2.培养学生移动应用编程能力,能够编写Andorid应用的主要功能模块,并掌握移动应用的开发流程。 3. 培养工程实践能力和创新能力。 通过本课程的学习应达到以下目的: 1.掌握移动互联网的基本概念和原理; 2.掌握移动应用系统的设计原则; 3.掌握Android应用软件的基本编程方法; 4.能正确使用常用的移动应用开发工具和测试工具。
当此App首次启动时,系统会自动实例化mBroadcastReceiver类,并注册到系统中。
BroadcastReceiver用于接收程序(开发者开发的程序和系统程序)发出的Broadcast Intent,程序启动BroadcastReceiver需要两步:
继上一期浅谈了Android的前世今生,这一期一起来大致回顾一下Android 系统架构和应用组件。 Android 系统架构 Android系统的底层建立在Linux系统之上,该平台由操作系统、中间件、用户界面和应用软件4层组成,它采用一种被称为软件叠层(Software Stack)的方式进行构建。这种软件叠层结构使得层与层之间相互分离,明确各层的分工。这种分工保证了层与层之间的低耦合,当下层的层内或层下发生改变时,上层应用程序无须任何改变。 Android的系统架构和其他操作系
从registerReceiver(BroadcastReceiver receiver,IntentFilter filter)出发
我们在工作的过程中,经常会使用到 BroadcastReceiver 机制,用来向活动发送消息,更新服务内的数据信息。但是我在这一过
领取专属 10元无门槛券
手把手带您无忧上云