十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
最近做项目时,遇到一个对新人我来说稍微有点麻烦的事情!
创新互联公司主营揭阳网站建设的网络公司,主营网站建设方案,app开发定制,揭阳h5成都小程序开发搭建,揭阳网站营销推广欢迎揭阳等地区企业咨询
那就是使用udp协议发送广播获取服务器地址!
http都好说,github开源项目不知道有多少。
可是再难的问题也要去解决!
发送广播需要权限!
AndroidManifest.xml 中添加:
最少这三个是必须的,多的也忘了!
原因后面会讲到
使用到RxJava:
udp发送与接受都需指定端口号
广播地址是255.255.255.255
在之前添加权限的时候CHANGE_WIFI_MULTICAST_STATE有添加这个
往下面看
接下来我们开启接收udp信息
发送消息?
谢谢该作者的文章让我学会udp发送
对于Activity的启动流程,我们已经有了几个版本的分析了。这里我们分析一个更容易一些的,四大组件中最简单的Broadcast Receiver。
关于Broadcast,有几点需要了解。首先是广播的类型,然后是广播的发送方法,最后是广播是如何被接收的。这三者相辅相承的,比如普通广播和有序广播只有在详细了解了广播的接收过程了之后,才能真正明白它的含义。
普通的广播是不在意顺序的,最简单的理解是同时可以收到这个广播。如果应用是动态注册这个广播的,且广播发送时这个进程还活着,那么当然可以并发的把广播尽快地传送出去是最好的。
但是,如果是通过AndroidManifest.xml静态注册的情况,也就是说这个广播首先要把一个进程启动起来,这时并发启动很多进程就是个问题了。Android目前的做法是,对这种静态的广播接收者,自动按有序广播的方式来串行处理。但是这对应用是透明的,应用不能假设系统已经把静态的无序广播当成有序广播来处理。
这个时候讲粘性广播有福了,因为从Android 5.0(API 21)开始,因为安全性的问题,官方已经正式废弃了粘性广播。
Context类提供两个方法可以用于发送普通广播:
差别是第二个设置权限。
发给特定的用户:
有序广播因为要处理消息的处理结果,所以要复杂一些。
如果只是想让广播可以按优先级来收取,并不在意处理的结果,可以用下面的版本:
同样,在多用户环境下,也可以选择给哪个用户发广播:
不管是普通的还是有序的广播都对应有粘性的版本:
以上的API都是定义于Context类中:
首先我们先看看发送端是如何发送的。
我们首先先放一个大图,让大家先有一个直观的印象,不管普通广播、有序广播、粘性广播如何组合,最终都汇集到一个大方法中。
我们先看应用发送普通广播的一个简单的例子:
非常简单,调用ContentWrapper的sendBroadcast方法就可以了。
然后我们顺藤摸瓜就好了。
Activity中的sendBroadcast,实际上调用的是:
我们来看frameworks/base/core/java/android/content/ContextWrapper.java中对sendBroadcast的定义:
ContextWrapper只是一个包装,真正的实现在ContextImpl中
我们来看/frameworks/base/core/java/android/app/ContextImpl.java中真正实现sendBroadcast的功能:
它会通过IPC去调用AMS的broadcastIntent。由于我们这个普通的广播的方法参数最少,所以好多都是传null。
加锁,定参数,然后调用真正的逻辑的实现。
我们先把broadcastIntentLocked的真正逻辑放一下,先看看有序广播是如何发送的。
ContextWrapper.sendOrderedBroadcast
Context是abstract方法,调用的是ContextWrapper的实现:
跟普通广播一样,还是会调用到ContextImpl.sendOrderedBroadcast
有序广播调用broadcastIntent的区别在于serialized参数,普通广播为false,有序广播为true.
原型为:
前面讲过带有回调的版本,我们看看它是如何实现的:
当然还是调用ContextImpl.sendOrderedBroadcast
这次变成只是一个封装了,它会调用一个更多参数的版本:
这次是一个全参数调用broadcastIntent的版本了,除了sticky就齐了
我们也不绕圈子了,直接看ContextImpl.sendStickyBroadcast.
以下广播简称Broadcast
是Android四大组件之一,在四大组件的另外两个组件 和 拥有发送和接收广播的能力。Android 是在 进程间通信机制的基础上实现的,内部基于消息发布和订阅的事件驱动模型,广播发送者负责发送消息,广播接收者需要先订阅消息,然后才能收到消息。 进程间通信与 的区别在于:
有三种类型
存在一个注册中心,也可以说是一个调度中心,即 。广播接收者将自己注册到 中,并指定要接收的广播类型;广播发送者发送广播时,发送的广播首先会发送到 , 根据广播的类型找到对应的 ,找到后边将广播发送给其处理。
这里以普通广播为例子, 接收者有两种注册方式,一种是 ,一种是 :
(广播的发送分为 两种,这里针对有序的广播) 中的android:priority=""和 中的IntentFilter.setPriority(int)可以用来设置广播接收者的优先级,默认都是0 , 范围是[-1000, 1000],值越大优先级越高,优先级越高越早收到。
在相同优先级接收同个类型广播时, 的广播接收器比 的广播接收者更快的接收到对应的广播,这个之后会进行分析。
注:以下源码基于rk3399_industry Android7.1.2
的流程可分为 , 和 三个部分,这里依次分析下
在Android系统的 机制中,前面提到, 作为一个注册和调度中心负责注册和转发 。所以 的注册过程就是把它注册到 的过程。
这里我们分析 广播的过程, 和 有一个共同的父类 ,所以它们对应的注册过程其实是调用 ,接下来我们按照流程逐步分析调用流程的源码。
frameworks/base/core/java/android/content/ContextWrapper.java
在之前的 Android应用程序启动入口ActivityThread.main流程分析 分析过,在我们启动 Activity 时会创建一个 对象,然后通过 传给我们启动的 ,其内部就会将该对象赋值给 ; 的 方法也是类似的赋值流程,这里放个简易的源码应该更好理解
可以看到最后都会将生成的 对象赋值给对应的
对象。接下来继续分析 , 即 函数。
/frameworks/base/core/java/android/app/ContextImpl.java
这里我们首先看下如何将广播接收者 封装成一个 接口的 本地对象
/frameworks/base/core/java/android/app/LoadedApk.java
每一个注册过广播接收者的 或 组件在font color='Crimson' LoadedApk /font类中都有个对应的 对象,该对象负责将 与 组件关联起来。这些对象,以关联的 作为关键字保存在一个 中。之后对应的 又以 的 作为关键字保存在 的成员变量 对象中。最后通过 对应的 方法获得其 接口的 本地对象。之后再回到 注册方法内,将 对象发给 进行注册。
/frameworks/base/core/java/android/app/ActivityManagerNative.java
/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
在的 或 注册一个 时,并不是将其注册到font color='OrangeRed'AMS/font中,而是将与它关联的font color='OrangeRed'InnerReceiver/font对象注册到font color='OrangeRed'AMS/font中,当font color='OrangeRed'AMS/font接收到广播时,会根据 在内部找到对应的font color='OrangeRed'InnerReceiver/font对象,然后在通过这个对象将这个广播发送给对应的 处理。
注册过程这边画了一个简单的流程图:
font color='OrangeRed'Broadcast/font的发送过程可简单描述为以下几个过程:
frameworks/base/core/java/android/content/ContextWrapper.java
/frameworks/base/core/java/android/app/ContextImpl.java
/frameworks/base/core/java/android/app/ActivityManagerNative.java
/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java
为了解决广播的安全性问题,Android引入了本地广播机制,使用该机制发出的广播只能在应用程序的内部进行传递,并且广播接收器也只能接收来自本应用程序发出的广播。
本地广播是无法通过静态注册的方式来接收的。我们知道静态注册主要是为了在程序未启动的情况下能接收广播,而当我们发送本地广播的时候,程序肯定是已经启动的了,所以我们需要动态注册方式创建接收器。
在这里我们创建一个继承于BroadcastReceiver的类LocalReceiver。onReceive()处理你接收到的广播内容,在这里我用Toast来创建一个提示接收到消息的弹窗
在activity_main.xml文件创建一个用于发送广播的按钮
首先通过本地广播管理器LocalBroadcastManager的getInstance()方法获取一个实例,并分别创建过滤器IntentFilter和自定义接收器LocalReceiver的实例。给IntentFilter的实例添加一个action:localbroadcast(接收的广播的名称),然后调用LocalBroadcastManager的registerReceiver()方法进行注册,并将LocalReceiver的实例和IntentFilter的实例都传进去。这样本地监听器就创建完成了。
调用LocalBroadcastManager的sendBroadcast()发送本地广播。运行程序,点击Send Button按钮,我们可以看到弹窗显示“This is in LocalReceiver”,说明本地广播发送和接收成功了。
当然,我们最后一定不要忘了取消注册。我们可以通过调用unregisterReceiver()方法来实现。至此,Android的标准广播发送就完成了。
1.发送的广播只能在本程序内传递,不必担心数据泄露
2.其它程序广播无法发送到本程序的内部,不必担心安全漏洞隐患
3.本地广播比系统全局广播更加高效
BroadcastReceiver(广播接收器)是Android四大组件之一,顾名思义,通过广播的方式进行消息传递,其本质是一个全局的监听器,可以监听到各种广播,可以用来实现不同组件之间的通信。广播最大的特点就是发送方并不关心接收方是否接到数据,也不关心接收方是如何处理数据的,通过这样的形式来达到接、收双方的完全解耦合。
又称无序广播,这种广播完全是异步的,所有与广播Intent匹配的BroadcastReceiver,都可以收到这条广播,并且不分先后顺序,视为同时收到,通过Context.sendBroadcast()方法发送。这种广播的效率比较高,但缺点是接收器不能将处理结果传递给下一个接收器,并且无法在中途终止广播。
这是一种同步执行的广播,通过Context.sendOrderedBroadcast()方法发送,这种广播发出后,通过receiver的intent-filter中的android:priority属性来设置优先级,优先级从-1000~1000,数越大,优先级越高,使用setResult()方法把结果传递给下一个接收者,通过getResult()方法获取上一个接收者传递过来的结果,并可以通过abortBroadcast()方法丢弃该广播,使该广播不再传递给下一个接收者。
粘性广播通过Context.sendStickBroadcast()方法来发送,用此方法发送的广播会一直滞留,当有匹配此广播的接收器被注册后,该广播接收器就会收到此广播。使用此广播时,需要获得BROADCAST_STICKY权限。(在 android 5.0/api 21后不再推荐使用)
Android系统中内置了多个系统广播,只要涉及到手机的基本操作,基本上都会发出相应的系统广播。如:开启启动,网络状态改变,拍照,屏幕关闭与开启,点亮不足等等。每个系统广播都具有特定的intent-filter,其中主要包括具体的action,系统广播发出后,将被相应的BroadcastReceiver接收。系统广播在系统内部当特定事件发生时,有系统自动发出。
以上广播都属于全局广播,发出去的广播,只要有匹配的接收者,就可以收到广播。这样一来会造成一些问题,一是消耗性能,二是容易引起安全性的问题,为了能够简单的解决这方面的问题,Android引入了一套广播本地广播机制,使用该机制发出的广播只能够在本应用内部进行传递,并且广播接收器也只能接收来自本应用发出的广播。
使用方法
1.注册本地广播接收器
2.发送本地广播
3.注销本地广播接收器
本文用到的BroadcastReceiver
Android 8.0(API级别26)取消大部分静态注册广播,建议使用动态广播