感觉广播比 Handler 方便多了,直接就 send,不用先传个实例才能回话
1
MaL 2021-01-08 07:45:56 +08:00 via Android
如果是一般广播的话,那就太重了,可以用本地广播或 eventbus
|
2
Helsing 2021-01-08 08:11:06 +08:00 via iPhone
尽量少用吧,要不最后到处都是满天飞的广播,看的头大
|
3
towry 2021-01-08 08:34:20 +08:00
不要只考虑写的时候有多爽,要考虑以后容不容易修改 /调试
|
4
wolegequ 2021-01-08 09:13:43 +08:00
能用就行,产品有人用再说. 某宝的 app 卡成翔也没见他们优化
|
5
kop1989 2021-01-08 09:19:15 +08:00
软件开发层面就是不好维护。
广播相当于是一个低耦合链接。 假设你有需求要修改某个广播的信息格式或者传参数量。 这时候编译器帮不了你,你很难确认你发送端和接收端都改对了 /改全了。只能不断的测试。 而且细节处理不好还会有安全性问题。 |
6
k10ndike 2021-01-08 09:30:44 +08:00 1
可以用 LiveData
|
7
jinhan13789991 2021-01-08 09:44:27 +08:00
我目前是维护很多 LiveData,说白了就是另一种广播。
只不过发送和订阅都抽成了独立的接口。优点就是不会混乱,缺点就是每次有新的需求就要再写一个专门的方法。 后面在考虑抽成一个通用的方法,通过枚举保证唯一。 |
8
BrokenVns 2021-01-08 10:38:47 +08:00 2
广播是基于异步 binder 的,异步 binder 存在以下小问题:
1.能够传递的数据量是同步 binder 的一半( 0.5M-4K ). 2.异步 binder 的消息传递优先级不高,可能会出现广播接收延迟问题,这种现象在 binder 流量大的老机器更明显。 3.你不知道异步 binder 传递是否成功了,碰到过通信失败而引发的 ANR 问题。 广播自身也有些小问题,比如广播要先发送给 AMS 再由 AMS 进行分发,跨了两次进程,广播是透明的等。 少量使用动态广播,可以减少开发量。 大量使用异步通信的话,还是建议使用 Looper-Handler 、开源库或者造轮子 |