活动在 finish() 之后不调用 onDestroy()

Question

我有三项活动，我们称它们为“一”、“二”和“三”。从活动一开始，按下按钮即可启动活动二。从活动二开始，按下按钮即可启动活动三。

够简单的。

现在，活动三需要从应用程序访问一些数据（可能存在也可能不存在）。在 THREE 的 onResume() 方法中，会检查数据，如果数据不存在，则活动结束，如下所示：

@Override
protected void onResume() {
    super.onResume();

    /* ... get data from app ... */

    if (data == null) {
        Toast.makeText(this, "Data not found", Toast.LENGTH_SHORT).show();
        finish();
        return;
    }

    /* ... other logic ... */
}

When data == null, THREE完成、销毁并返回到“二”。一切都很好。 现在，在 TWO 中，按后退按钮会在 TWO 上调用 finish()，但 TWO 永远不会调用 onDestroy()。用户可以很好地返回到 ONE，但是任何后续返回到 2 的意图都不起作用，并且不会引发任何错误。 TWO 处于已完成（并暂停）但从未被破坏的状态，因此无法恢复。

那么，为什么“三”在这种情况下很重要呢？如果我删除上面代码块中的 finish() 调用，并依赖于“自然”完成“三”（通过使用后退按钮），那么当用户返回“一”时，“二”已完成正确销毁。

好吧，这就是真正令人困惑的地方......

保留 finish() 调用，我可以通过直接从 ONE 启动 3 个来缓解挂起，然后“自然”完成它（后退按钮）。在三个被摧毁（第二次）后，两个按预期打开。

我读到的所有内容都表明我应该可以在活动的 onResume() 中调用 finish() 。但在这种情况下，它会使某些东西处于不良状态，并阻止我破坏调用活动。

有想法吗？还是我把你的脑子翻了个底朝天？

编辑：

进一步的探索发现了这个宝石...

围绕三个中的 finish() 调用，使用大约 500 毫秒的 postDelay() 处理程序将让两个按预期关闭。就像这样：

@Override
protected void onResume() {
    super.onResume();

    /* ... get data from app ... */

    if (data == null) {
        Toast.makeText(this, "Data not found", Toast.LENGTH_SHORT).show();
        Handler h = new Handler();
        h.postDelayed(new Runnable() {
            @Override
            public void run() {
                finish();
            }
        }, 500);
        return;
    }

    /* ... other logic ... */
}

不完全是我的修复想法......

Answer 1

按下后退时活动未完成/销毁。

使用

 @Override
    public void onBackPressed()
    {
        finish();
    }

Answer 2

由于我无法发表评论，所以我会写在这里。

我不是 100% 确定我是否关注了你，但在接近尾声时你提到了这一点

三个被摧毁（第二次）后，两个按预期打开。

你这是什么意思，因为如果我没听错的话，你说你用“一”中的按钮打开“二”，用“二”中的按钮打开“三”。那么 TWO 如何按预期打开，或者你的意思是当你退出它时它会转到 onDestroy() ？

我的目标是，也许您打开同一活动的更多实例，如 这里（如果您查看图 3）。

Answer 3

由于此问题仅在 onResume() 中发生[请参阅评论]，我认为这听起来像是状态持久性的问题，而不是修补堆栈的问题。

看看这个 Stack Over Flow 问题 使用 Save Instance 保存 Android Activity 状态State

如果 onPause() 你将“数据”（我不知道它的对象类型，因为你没有说过）保存到 Bundle 然后 onResume() 去获取它。

Google 在此处找到的另一个示例，使用SharedPreferences 而不是 Bundle 来实现相同的结果。

总的来说，这意味着您可以处理/防止“数据”为空，因为您可以恢复它，因此节省了销毁三个数据并尝试摆弄堆栈的工作，只需用您的术语来保持工作流程“自然”即可。