3

我有一个复杂的应用程序，它具有后台线程（可能在服务中），当它们从互联网接收数据时，需要通知我的主要显示活动（以更新几个状态指示器）。所有都在同一个进程中运行（我认为没有理由不这样做）。

但是，在某些情况下，这些事件很频繁 - 每秒 5 个。此外，当活动不可见甚至被破坏时，可能会发生这些事件。我认为关于这个问题的唯一新颖之处在于效率问题。例如，我仍然以 G1 为目标。

该线程中提到了许多方法，但我不知道其中哪些方法足够有效，并且在活动被破坏时会起作用。这些方法是我更愿意遵循的“Android 方式”。

我有三种丑陋的反 Android 方法，但它们也有缺点：

  1. 在等待信号量的活动中有一个线程，并在释放时进行更新。缺点：多线程，如何处理几种事件类型
  2. 与 #1 类似，但使用并发阻塞队列对象。缺点：额外的线程，相同类型的事件可能会多次进入队列（不好）
  3. 保持对活动处理程序的静态引用，并使用它来运行更新程序。缺点：（a）可能会泄露对activity的引用？(b) 当活动改变状态时会发生什么？(c) 当只需要一个时，可能会出现多个可运行文件。
4

1 回答 1

3

此外，当活动不可见甚至被破坏时，可能会发生这些事件。

如果您的活动被破坏，则没有什么可更新的。如果并且当用户选择重新访问该活动时，该活动可以获取当前信息以onResume()供显示。

如果您的活动在后台，则也没有什么需要更新的。同样，如果当用户选择重新访问该活动时，该活动可以获取当前信息以onResume()供显示。

您需要实时通知活动事件的唯一时间是该活动是否在前台。在这种情况下，我在您链接到的答案中概述的任何解决方案都可以工作。绑定选项或Messenger可能是最轻量级的解决方案。

我有一个具有后台线程的复杂应用程序（可能在服务中）

如果它们要超出任何给定活动实例的范围，则不是“可能”-“必须”。

我有三种丑陋的反 Android 方式有效

如果没有潜在的内存泄漏，这些都不起作用。

于 2011-07-09T11:06:40.813 回答