該應用程序需要一個基礎功能，可以拾取位置並將它們發送到服務器。這必須定期發生（大約每隔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開始的短期服務可能因內存不足而死亡，這讓我大吃一驚。
這就是說，你想要的行爲似乎可能會消耗更多的電池壽命比用戶可能想要的。請允許用戶控制投票時間，包括「從不投票，我會手動更新」選項。