广播传输和性能
我猜测广播消息被发布到消息中 接收线程的队列并通过循环器传递。广播是在消息队列中的其他消息之前传递的还是只是附加到队列的末尾？我没有具体的需求或类似的东西，只是出于好奇而想知道。
在服务和 Activity 之间使用 IPC 广播的性能开销（CPU 和内存）是多少？
GL
I am guessing that the broadcast messages are posted to the message
queue of the receiving thread and delivered through the looper. Are the broadcasts delivered before other messages in the message queue or just appended to the end of the queue? I have no specific need or anything like that, just wanted to know out of curiosity.
What is the performance overhead (CPU and memory) for using broadcasts for IPC between a service and an Activity?
GL
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为他们只是排在队列的最后。测试这一点的简单方法是
post()将几个Runnables发送到队列，每个队列休眠一段时间，然后向自己发送广播。如果Runnables在广播之前全部处理完毕，则广播结束。如果广播在后面的 Runnables 之前处理，那么它会在前面注入。正如@jlindenbaum 所说，适度。我不建议尝试启动数千个东西，并且对于进程内工作有更轻量级的解决方案（例如，
Messenger）。I think they just go on the end of the queue. The easy way to test this is to
post()a couple ofRunnablesto the queue that each sleep for a bit, then send yourself a broadcast. If theRunnablesare all processed before the broadcast, it went to the end. If the broadcast is processed before laterRunnables, then it got injected at the front.Modest, as @jlindenbaum suggests. I wouldn't suggest trying to fire off thousands of the things, and there are lighter-weight solutions for in-process work (e.g.,
Messenger).我从未注意到使用此功能的设备会承受很大的压力。
这是我发现的唯一“理智”的方式，可以在服务和活动之间进行通信，而不会导致 UI 线程出现问题。
I've never noticed a considerable strain on devices using this.
It's the only "sane" way, that I've found, to communicate between a Service and an Activity without causing issues on UI threads.