在我的应用程序中，我使用的是联系人同步适配器，但它有很多与主应用程序共享的信息。适配器需要一些设置才能正常工作（例如登录信息以及用户是否更改了任何同步设置），因此我目前在同一进程中运行它，并且它使用 getApplicationContext() 与主 ap 通信，然后我在同步适配器在同步过程中使用的Application中有一些共享变量。
但在培训文档和一些在线教程中，示例适配器设置为在其自己的进程中运行 - 它在清单中使用android:process=":sync"。有必要吗？如果它确实在单独的进程中运行，我如何与主应用程序通信？
在我们的上下文中，由于快速搜索需求，我们使用远程服务在内存中保存一个巨大的数据库。
我们使用远程服务而不是本地服务的原因是，我们相信在单独的进程中运行服务将使我们更难达到每个进程的最大内存限制（限制因不同的设备和操作系统版本而异）。
在我们的初始设计中，我们使用 AIDL .稍后，我们切换到 Messenger .我想不起背后的原因。我将查看我们的源代码历史日志以找出原因。但是，我认为主要是，Messenger没有AIDL那么复杂，我们不需要AIDL提供的多线程功能。
在自己的进程中运行Service可能会有所帮助
1）如果您希望您的服务能够承受主应用程序的进程破坏（但START_STICKY对于这种情况来说绰绰有余），
2） 如果您想为应用程序的所有"同步"任务指定此过程（如教程中所述），
3） 如果您希望其他应用程序使用您的服务。
若要与在单独进程中运行的Service进行通信，请使用绑定服务。
但是，在单独的进程中运行服务会增加与其通信的复杂性，因此请考虑上述任何情况是否与应用用途相关。
我认为它应该分开，但这不是必需的。
通常，分离Service进程是非常值得考虑的，如果它可以独立于系统组件或其他应用程序使用。从这个角度来看，进程的生命周期应该独立于其他组件（例如同一应用程序中的Activity）进行管理，因此 Android 可以轻松准确地标记当前使用的进程，以决定在内存不足的情况下要杀死哪个进程。此外，即使前端活动意外崩溃，服务也可以继续运行。
维护在单独的进程之间共享数据。对于登录凭据和首选项，我想您可能会使用 SharedPreferences 和 OnSharedPreferenceChangeListener 的组合。
当应用程序启动时，它可能会缓存不同的东西，特别是对于 UI。通过在不同的进程中拆分同步逻辑，允许在设备内存不足时终止 UI 进程，这将释放这些 UI 缓存。
因此，此技术主要对长时间运行服务的应用程序感兴趣。典型例子：
- 在音乐应用中播放音乐的服务
- 在 Youtube 中上传视频的服务
然而：
- 这增加了应用的复杂性
- 如果操作不正确，它实际上会增加应用程序的整体内存占用