Android - 将事件通知传递给可能不活动的活动的有效方法？
我有一个复杂的应用程序，它有后台线程（可能在服务中），当它们从互联网接收数据时，需要通知我的主显示活动（更新几个状态指示器）。所有这些都在同一个进程中运行（我认为没有理由这样做）。
然而，在某些情况下，这些事件很频繁 - 每秒 5 次。此外，当 Activity 不可见甚至被破坏时，也可能会发生这些事件。我认为这个问题唯一新颖的是效率问题。例如，我仍然以 G1 为目标。
这个线程中提到了很多方法，但我不知道是哪一个其中的一些足够有效，并且如果活动被破坏也会起作用。这些方法是我更愿意遵循的“Android 方式”。
我有三种丑陋的反Android方法，但它们也有缺点：
- 在活动中有一个线程等待信号量，当释放时，进行更新。缺点：额外的线程，如何处理多种事件类型
- 像#1，但使用并发阻塞队列对象。缺点：额外的线程，相同类型的事件可能会多次出现在队列中（不好）
- 在活动上保留对处理程序的静态引用，并使用它来运行更新程序。缺点：(a) 可能会泄漏对活动的引用？ (b) 当活动改变状态时会发生什么？ (c) 当只需要一个时，多个可运行程序可能会在那里结束。
I have a complex app that has background threads (that could be in a service) which, when they receive data from the internet, need to notify my main display activity (to update on of several status indicators). All run in the same process (I see no reason to do otherwise).
However, in some circumstances, these events are frequent - 5 per second. Also, the events may occur when the activity is not-visible or even destroyed. I think the only thing novel about this question is the issue of efficiency. I still target the G1, for example.
There are a number of methods mentioned in this thread, but I don't know which of these are efficient enough, and will work if the activity is destroyed. Those methods are the "Android way" which I would prefer to follow.
I have three ugly anti-Android ways that work, but they also have drawbacks:
- Have a thread in the activity that is waits on a semaphore, and when released, does the update. Disadvantages: extra thread, how to handle several event types
- Like #1, but use a concurrent blocking queue object. Disadvantages: extra thread, same type of event may end up in the queue multiple times (not good)
- Keep a static reference to a handler on the activity, and use that to run an updater. Disadvantages: (a) may leak a reference to the activity? (b) what happens when the activity changes state? (c) multiple runnables could end up there when only one is needed.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的 Activity 被破坏，则没有任何内容可以更新。如果用户选择重新访问该 Activity，该 Activity 可以在
onResume()中获取当前信息以供显示。如果您的活动位于后台，则也不需要更新任何内容。同样，如果用户选择重新访问该 Activity，该 Activity 可以在 onResume() 中获取当前信息以供显示。
唯一您需要实时通知活动的事件是该活动位于前台时。在这种情况下，我在您链接的答案 可以工作。绑定选项或
Messenger可能是最轻量级的解决方案。如果它们要超出任何给定活动实例的范围，则不是“可能” - “必须是”。
这些方法都没有潜在的内存泄漏。
If your activity is destroyed, there is nothing to update. If and when the user elects to re-visit that activity, the activity can get the current information in
onResume()for display.If your activity is in the background, there is nothing that needs to be updated, either. Again, if and when the user elects to re-visit that activity, the activity can get the current information in
onResume()for display.The ONLY time you need an activity to be notified of events in real time is if that activity is in the foreground. In that case, any of the solutions I outlined in the answer you linked to could work. The binding option or
Messengerare probably the lightest-weight solutions.Not "could be" -- "must be", if they are to live beyond the scope of any given activity instance.
None of those work without potential memory leaks.