该应用程序需要一个基础功能，可以拾取位置并将它们发送到服务器。这必须定期发生（大约每隔1至5分钟），但最重要的是它必须始终发生，永不停止，防止操作系统关闭进程以回收内存，以及应用程序本身未运行时。如何实现永久的，定期的，后台位置更新？
已经向我提出了以下解决方案。我熟悉处理Android位置，这里的问题是确保它们继续，即使应用程序不在内存中，并通过回收内存来坚持。
SERVICE。使用服务收集位置事件并处理它们。使用引导和屏幕广播来确保服务始终运行（并且可能还会增加服务优先级以防止内存回收）。
ALARMS。我收集这些可以在内存短缺时关闭。我将如何防范呢？这似乎是一个难看的解决方案，因为无论如何这些位置都会按照时间表来到，所以似乎没有必要再设置一个基于时间的组件。
LOCATIONS VIA BROADCAST。通过广播意图传送的位置意味着我可以在广播接收器中处理位置事件。这些位置警报是否会无限期持续？设备关机或应用程序关闭以外的任何其他设备是否会导致它们停止工作？
什么是最耐用的方法？
这必须定期（每1-5mins约）发生，但最重要的是它必须发生的时间，从来没有停止，免受操作系统关闭过程下来回收内存，并且在应用程序本身没有运行。
这不是严格可行的，在各种各样的方面。
让我们带他们一块在一个时间：
这必须定期（每隔大约1-5mins）发生
你可能无法得到的地点，时期，更别说每1-5分钟。用户可能已禁用所有位置提供程序。用户可能使设备处于飞行模式。用户可能位于大型建筑物（阻挡GPS），连接不畅（使网络供应商不可靠）。
从未停止
用户总能经由设置管理服务屏幕或任务的杀手干掉你。如果他们这样做，特别是在Android 3.1+上，您的应用将永远不会以任何理由再次运行，直到用户启动您的活动（例如，通过启动器）。当然，用户也可以卸载你的应用程序。
免受操作系统关闭过程到回收内存
你不能保证在此。你可以减少几率，但就是这样。
现在，让我们看看你的各种解决方案：
使用服务来收集位置的事件和处理它们。
从这句短语（和随后的句子），你的意思是一个永恒的服务，一个旨在运行24x7。根据定义，这意味着你的应用程序正在运行，这违反了你的规则之一。假设你放松这一规则，这种解决方案大规模增加的可能性，用户将摆脱你的服务，并增加了Android将摆脱你的服务的可能性。您可以通过使用startForeground()来最小化后者。
报警。我收集这些可以在内存短缺时关闭。
不是我所知道的。但是，如果用户摆脱了你，你的警报将被删除。
这似乎是一个丑陋的解决方案，地点将按计划进行反正
没有到达，他们不会。 requestLocationUpdates()上的时间参数并不意味着“地点将按照时间表到达”。
通过广播意图传送的位置意味着我可以在广播接收器中处理位置事件。
不，你不能。您已经指出您的部分工作将是将这些数据发送到服务器。您无法在主应用程序线程中可靠地执行此操作，因为它可能需要很长时间。 A getService()PendingIntent，指向IntentService会更可靠。
将这些位置警报继续下去？
否参见下文。
除了设备关机或应用程序关闭以外的任何事情会导致它们停止吗？
用户可以摆脱你的应用程序（卸载，任务杀手，管理服务）。用户可以禁用位置提供程序。用户可以进入无法确定位置的区域。等等
此外，该设备可能会睡着了，AFAIK。在登记的更新请求期间，系统可能会保留WakeLock。系统甚至可能会在内部使用AlarmManager来安排在您提供的时间内唤醒自己，因此它不必保持设备不间断唤醒。但是，您需要彻底测试。
什么是最耐用的方法？
如果我上一段中的问题由操作系统处理，您的第三个选项可能是最强大的。在您的IntentService()中使用startForeground()，并在退出onHandleIntent()之前致电stopForeground() - 即使由AlarmManager开始的短期服务可能因内存不足而死亡，这让我大吃一惊。
这就是说，你想要的行为似乎可能会消耗更多的电池寿命比用户可能想要的。请允许用户控制投票时间，包括“从不投票，我会手动更新”选项。