我有一个复杂的应用程序,它有后台线程(可能在服务中),当它们从Internet接收数据时,需要通知我的主显示活动(更新几个状态指示器)。所有的程序都在同一个进程中运行(我看没有其他的理由)。
然而,在某些情况下,这些事件是频繁的-每秒5次。此外,当活动不可见或甚至被破坏时,可能会发生这些事件。我认为这个问题唯一新奇的地方就是效率问题。例如,我仍然瞄准g1。
有很多方法在this thread中提到,但我不知道哪种方法足够有效,如果活动被破坏,它们将起作用。这些方法是我更愿意遵循的“android方式”。
我有三种丑陋的反安卓方式,但它们也有缺点:
在活动中有一个等待信号量的线程,当释放时,执行更新。缺点:额外的线程,如何处理几种事件类型
与1类似,但使用并发阻塞队列对象。缺点:额外的线程,相同类型的事件可能会多次出现在队列中(不好)
在活动上保留对处理程序的静态引用,并使用该引用运行更新程序。缺点:(a)可能泄露对活动的引用?(b)当活动改变状态时会发生什么?(c)当只需要一个runnable时,可能会有多个runnable结束。
最佳答案
此外,当活动不可见或甚至被破坏时,可能会发生这些事件。
如果您的活动已被破坏,则无需更新。如果用户选择重新访问该活动,则该活动可以在onResume()
中获取当前信息以供显示。
如果您的活动是在后台进行的,则也无需更新任何内容。同样,如果用户选择重新访问该活动,则该活动可以在onResume()
中获取当前信息以供显示。
唯一需要实时通知事件的活动是该活动是否在前台。在这种情况下,我在the answer you linked中概述的任何解决方案都可以工作。绑定选项或Messenger
可能是最轻的重量解决方案。
我有一个复杂的应用程序,它有后台线程(可能在服务中)
如果要超出任何给定活动实例的范围,则不能是“could be”--“must be”。
我有三种丑陋的反安卓方法
如果没有潜在的内存泄漏,这些都不起作用。