Android-电池对周期性唤醒的简单后台线程的影响

我正在尝试在我的应用程序中为用户的登录会话实现超时机制 例如，如果用户在10分钟内没有与我的应用程序进行交互，那么当他下一次使用应用程序时（无论该应用程序之前是在后台还是当前在前台），他应该被带到登录屏幕

我当前的实现使用：
-来自我的“BaseActivity”（除LoginActivity扩展BaseActivity之外的所有活动）的Java线程（称为“TimeoutThread”）的单例实例
-因此，只有在首次启动任何登录后活动时，才会启动单例“TimeoutThread”。
-“TimeoutThread”将简单地跟踪带有线程的while（）循环中的“lastUserInteractionTimeStamp”。wait（）。。。 因此，它每2秒唤醒一次，检查（currentTime lastUserInteractionTimeStamp）是否大于10分钟，如果大于10分钟，那么如果回调对象不为null，它将触发一些回调（每当应用程序进入后台时，回调将设为null，等等）

这个方法现在很好用

我担心的是，即使当应用程序进入后台（例如用户按下Home按钮）时，该线程每隔几秒钟就会唤醒一次（while（true）循环中的thread.wait（）），这将导致电池电量耗尽

我一直无法找到一个好的链接来解释保留这样一条线索的效果。 我确实找到了电源优化、安排重复性任务等链接（粘贴在下面），但无法直接在那里找到我的答案。

---

有人能批评这种方法/提出更好的方法吗

将AlarmManager与服务一起使用。工作线程本身可能最终被系统杀死。另外，我可以问一下为什么你要给用户计时吗？这是安全功能吗？或者一个功能，因为你不想你的服务器被淹没？只是为了基本的安全。我确实读过AlarmManager和服务，但这会唤醒应用程序，即使设备处于睡眠模式，这对我来说似乎有些过分。由于我一直跟踪“lastUserInteraction”的时间戳，所以我的应用程序在后台时是否从未被唤醒并不重要，因为每当它进入前台时，超时线程就会运行，并看到我们已经超过了超时时间并触发回调。如果应用程序被终止并重新启动，超时到期时间无关紧要，不需要工作线程或AlarmManager，当用户尝试重新启动或恢复应用程序的UI线程时，您可以检查用户上次使用应用程序的时间。你不需要线程。啊，这是一个很好的观点，我完全忘了提到另一件事-当应用程序在前台时，这个线程还检查“注销警告”间隔（小于超时间隔），并向用户显示警告对话框。因此，我想我可以保留执行该警告部分的线程，并使用您的建议检查超时并从BaseActivity的onResume（）触发注销流。谢谢不要使用注销警告。使用相同的时间段。不管发生什么，请不要使用模态对话框。如果服务器提供的会话太短，Android系统应该能够在没有用户干预的情况下重新进行身份验证。此外，如果用户已经在其手机上使用安全模式/pin，则应避免向用户显示第二个登录屏幕。一个就足够了。Square和Mint等应用程序获得比大多数其他银行应用程序更好的用户评论是有原因的。大多数银行应用程序都和你做的一模一样。