Testing 测试Android应用程序流程生命周期&；达到空进程状态时还原状态

我最近一直在努力完善我的知识和技能，以便在应用程序流程生命周期的各个阶段管理Android应用程序状态。具体来说，我一直在测试各种方法。在我的测试应用程序中，为了测试全局应用程序数据和/或单例数据的重新创建，我需要等待几个小时或更长时间，以便我的手机确定其他进程更重要，并将我的测试应用程序置于中定义的空进程状态。此时，应用程序的数据被释放，需要在应用程序再次被带到前台后重新创建。如果操作不正确，重新初始化应用程序的最后一个已知状态可能会由于各种原因导致强制关闭

---

所以，我的问题是，除了等待这一切有机地发生之外，还有没有一种真实的方法来测试这一现象。例如，一个QA用例是什么样子的，它测试应用程序进入后台一段（非常）长的时间，然后在应用程序达到空进程状态后再次被带到前台

我对此做了一些尝试，并提出了一个很好的解决方案：

最终，这归结为每个活动都能够独立地恢复其状态。这同样适用于应用程序。“空进程”状态是操作系统将应用程序置于不再重要状态后的最终状态

以下是我测试我的应用程序的空流程场景的方法：

打开您的应用程序到有问题的页面

推动“回家” 按你手机上的按钮

打开不少于3个高资源利用率 具有长滚动列表视图的应用程序（我使用Facebook、Youtube和 谷歌游戏商店）

在每个应用程序中，将listview向下滚动一段时间 使用系统资源的数量

完成所有3个应用程序后， 重新打开你的应用程序

对每个活动和片段运行上述测试不仅可以测试活动和/或片段的完整再现，还可以测试整个应用程序

---

这有点像p.I.T.a.，但它是有效的。

我假设在设置中强制关闭应用程序，或将应用程序滑出活动应用程序（长按home）不起作用？这样做只会杀死应用程序，不会模仿操作系统如何管理文档中描述的流程生命周期。例如，如果您正在应用程序的活动2中，它会进入后台。两天后，当你再次打开应用程序时，操作系统已经破坏了实际的应用程序进程。但保留的空进程状态将尝试以与您离开应用程序时相同的状态打开应用程序。在这种情况下，活动#2。如果未正确保留状态数据，则可能会发生不好的事情。这些类型的场景是我感兴趣的测试。