我的应用程序有一个用于 UI 的 Activity 和一个用于后台轮询乐趣的 Service。好像是标准票价。
AlarmManager 可以在不调用 Activity OnCreate 的情况下触发 Service Intent 吗？
将活动和服务放入不同的应用程序有什么好处吗？这会创建 2 个 apk 并使其无法作为一个应用程序放入 Market 吗？你能以某种方式将 2 个应用程序放入一个清单吗？
关于两人的交流：
- 如果活动和服务是同一个应用程序的一部分 - 我不能只在应用程序范围内存储公共对象（如用户对象）以供 2 共享吗？
- 似乎我什至不需要为 AIDL 操心——两者也可能在应用程序范围内相互之间存在弱引用——他们可以这样相互调用方法吗？或者他们应该使用某种观察者模式或广播监听器相互发布/订阅？
AlarmManager 可以在不调用 Activity OnCreate 的情况下触发 Service Intent 吗？
是的。
将活动和服务放入不同的应用程序有什么好处吗？
恕我直言，不。
这会创建 2 个 apk 并使其无法作为一个应用程序放入 Market 吗？
是的。
你能以某种方式将 2 个应用程序放入一个清单吗？
从纯 XML 的角度来看，清单中有多个<application>元素的空间。但是，AFAIK，只支持一个。
If Activity & Service are part of the same Application - can't I just store common objects (like User object) at the Application scope for the 2 to share?
For very quick things, yes. However, bear in mind that your service may get shut down (by Android, by user, etc.), after which your process may get terminated, and your Application object goes poof. I'd use this for light caching only.
It seems like I don't even need to bother with AIDL
Correct -- that is only needed for inter-process service binding.
the two could just have weak references to each other at the Application scope as well
I wouldn't do that in a million years. Please use the platform responsibly. There are plenty of ways for activities and services to communicate yet remain loosely coupled (or, in the case of the local binding pattern, tightly-coupled in an Android-aware fashion).
Or should they pub/sub each other with some kind of Observer Pattern or BroadcastListener thing?
Something along those lines would be preferable. While the activity and the service may be co-resident in the same process at the same time, they are not designed to be directly linked to one another.