在 Android 中，我如何检测我的活动恢复的原因？
我正在开发一个活动，它可以进行一些自己的状态管理。我试图区分以下 onResume 情况：
- 新启动
- 任务开关（主页按钮长按）
- 在同一应用程序中的其他活动
- 后唤醒后恢复
- 在睡眠方向更改
活动的意图或其他地方是否有某些内容可以帮我区分这些？
为了好奇和一些背景......我想在 4 和 4 上保留我的内部历史堆栈。 5.关于案例2& 3，我会保留相同的当前页面，但删除历史记录（允许正常的后退按钮功能在此时接管）。情况 1 将初始化到活动的内部起始页（并且可以在 onCreate 的帮助下轻松检测到）。
I'm developing an Activity that does some of its own state management. I'm trying to differentiate the following onResume cases:
- New launch
- task switch (home button long-click)
- resume after other activity in the same application
- wake-up after sleep
- orientation change
Is there something in the Activity's intent, or elsewhere, that can help me differentiate these?
For the curious and some context... I'd like to preserve my internal history stack on 4 & 5. On cases 2 & 3, I would preserve the same current page, but erase the history (allow the normal back button functionality to take over at that point). Case 1 would initialize to the activity's internal start page (and can be detected easily enough with some help from onCreate).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
AFAIK，项目 #4 与 onResume() 无关。
通过
android:configChanges和onConfigurationChange()可以更好地处理第 5 项，尽管您可以通过从onRetainNonConfigurationInstance()返回某些内容来“检测”它并通过getLastNonConfigurationInstance()查看它是否存在于onResume()中。其他情况不仅仅是三种情况，而且可能是两倍，一旦您开始考虑“被踢出内存以释放 RAM”之类的可能性。
即兴地，感觉就像您做出了一些不幸的架构决策（“内部历史堆栈...擦除历史记录...允许正常的后退按钮功能在此时接管”）。 Android 是围绕许多廉价活动而设计的，而您似乎违反了这一规则。欢迎您这样做，但请记住，Android 对您选择的模式的支持可能是有限的。
Item #4 has nothing to do with
onResume(), AFAIK.Item #5 would be better handled via
android:configChangesandonConfigurationChange()though you could "detect" it by returning something fromonRetainNonConfigurationInstance()and seeing if it is there inonResume()viagetLastNonConfigurationInstance().The others aren't just three cases, but probably twice that, once you start taking into account things like "being kicked out of memory to free up RAM" as a possibility.
Off the cuff, it feels like you made some unfortunate architectural decisions ("internal history stack...erase the history...allow the normal back button functionality to take over at that point"). Android is designed around lots of cheap activities, and you appear to be violating that precept. You are welcome to do so, but bear in mind that Android support for your chosen pattern may be limited.