android 注册动态广播 注销_Android中对于广播接受者 为什么动态注册优先级高于静态注册?...

因为广播机制就是狗屎。

不管你是不是有序，它从PMS拿一个列表，从自己维护的动态注册里拿一个列表，动态的可以有序无序，静态的不管你是不是有序他都按顺序发。

代码里就是先发动态的，再发静态的，所以你把静态的优先级弄到比动态高，那也不好使。

我当年看源码的时候心里就骂开了，什么狗屁。。。一个三方应用的接收器不好好写就能导致手机拨不出去电话，状态栏时间也不更新了，亮灭屏也不好使了；什么鬼！！

如果你想要你的OS性能变好，第一时间就是去广播那大砍大杀一番。从权限上禁止一些敏感广播，从系统，特殊应用，普通应用上区分广播队列。个人建议能开辟单独线程分流专门走那些辣鸡三方应用发的广播比较好。另外对辣鸡三方应用注册的接收器也应该降格一等来妥善处理，分割接收器队列。这个要做的话要好好想想方案，必须考虑到保证有序广播的逻辑顺序。

广播接收器注册必须限制，它是一个binder node。注册多了可是会导致驱动层出问题的，明白binder体系里用户空间分配和binder引用的自然知道，不细说。是fwk级的零敲碎打做资源池的算法，还是更底层去系统把控，基本上会选择前者，不过如能在binder机制加入针对不同进程注册和调用的资源限制，应该也可以考虑一下。见过太多普通应用通过某个三流选手毫无节制的binder调用或者binder注册就把系统搞挂的情景。

广播派发和系统休眠产生矛盾，建议采取手段，划分优先级，低优先级的必须等系统醒来再延时派发。重做一下原生系统睡眠的算法，包括相关的alarm的算法，按自己的机子配置去优化下。休眠之后后台挂起的广播也可以像alarm那样隔段时间集体派发。

有序广播太绝对了，大多数接收器没有逻辑先后顺序。如果能把这些按优先梯级归并，每个梯级并发派发，会好很多，这个我们三方定制OS很难去做，重构太大，影响源码太大，但是我没有细细评估，也许有优雅的实现方式。

包括有序广播，个人认为，在优先级相同的情况下，只有folk进程这个阶段应该串行，比如接收器A和B优先级一样，虽然是有序而且静态注册的，但是A在folk进程，我就可以去继续派发B，而不是干等着，除非它也要folk进程，这样它即使发生了ANR，但是其他和它优先级一样的接收器已经继续派发了。当然这需要更优雅的调用链，和现在的实现从逻辑上就有冲突。

说了这么多，对Android方方面面缺陷的怨念算是抒发了九牛一毛。我现在也不做性能功耗，说这些也是白搭。