在这里，我想问一个基本问题，即我在做代码时无法找到答案。
据我所知，在应用程序onCreate（）中创建一个单例实例比android服务更容易受到攻击。在我的应用程序中，我想听取位置更新，这应该不太可能被销毁。如果我保持服务，它可能会在低内存中被杀死，但是，应用程序仍然可以在后台运行，这将保留实例。所以我想使用单例实例而不是服务。
这是一种正确的方法吗？
答案 0 :(得分：3)
Android可以（并且会）在低资源情况下杀死后台进程，有时也只是因为它想要（特别是在低端设备上以节省电池和内存资源）。它通过杀死托管您的应用程序的操作系统进程来实现此目的。在这种情况下，您的应用将不再在后台运行，因此您在Application.onCreate()中创建的任何单例也将消失。
Android对你的单身人士一无所知，因此没有理由恢复它。
但是，如果您从Service创建Service且START_STICKY返回onStartCommand()，则会告诉Android您的Service想要继续运行所有时间（如果可能的话）。在这种情况下，如果Android杀死托管您Service的操作系统进程（由于资源限制，或者只是因为它想要），Android会自动重新启动您的Service（因为Android知道您的Service 1}}并且知道它想要一直运行）。这是执行此操作的正确方法。
注意：有些设备（特别是小米，华为，LG，联想等中国设备）不会自动重启STICKY服务。这些设备维护一个允许在后台运行的“受保护应用程序”或“特权应用程序”列表，Android将仅为此列表中的应用程序重新启动STICKY服务。您需要让用户将您的应用添加到此列表手动。无法在这些设备上以编程方式将您的应用添加到此列表中。
见https://stackoverflow.com/a/42120277/769265和 https://stackoverflow.com/a/41369032/769265
答案 1 :(得分：0)
如果你问我的意见，我也不会推荐。因为两者都在后台吮吸用户的电池。
我要做的是 - 仅在主要活动的前台获取位置更新。也开始使用Google Play服务FusedLocationProvider而不是实现android默认值。
当您的应用程序变为后台时删除位置更新。所有指南都在Android开发者网站上。
https://developer.android.com/training/location/receive-location-updates.html
答案 2 :(得分：0)
最佳做法是在Application类中创建Singleton实例。
因此，当Service 或 Activity存在时，它将可用。
此外，您可以使用Foreground Service，如果检测到内存不足，则不会被杀死。
此外，您还可以处理Application类中的低内存事件或服务中的onDestroy，并将数据序列化为SharedPreferences。使用START_STICKY服务将尽快重启。
答案 3 :(得分：0)
我认为您的问题在于将组件24维持7乘以365以便管理位置。
您可以通过管理来自onStartCommand的返回标志来维护您的服务以便再次启动它。 START_STICKY等..
在这里阅读更多内容： https://developer.android.com/reference/android/app/Service.html#START_STICKY
答案 4 :(得分：0)
根据您的描述，我建议采用前台服务。跟踪用户位置使用了很多电池。因此，您的用户应始终了解您的应用仍然正常运行的事实。
你也在阻止系统以这种方式杀死你的应用程序。
前台服务是用户主动了解的服务 并且当内存不足时，它不是系统杀死的候选者 Source