Android如何限制返回栈的大小?

How to limit the size of the back stack in Android?

我们正在开发一个 Android 包含大量视图的应用程序(用于展示公司目录)。

该应用程序的设计存在一些缺陷,主要是因为我们 "forced" 尽可能模仿现有的 iOS 版本的应用程序(我知道,这是错误的)。现在我们面临一些内存问题(=OOM 异常),主要是因为导航不是非常结构化,我们不能强制导航的 "finite" 深度:目前用户可以使后台堆栈增长尽可能多他想要。

让我试着用更好的方式解释。在我们的应用程序中,我们有 4 个部分 ABCD。用户可以输入部分 A,打开子部分 A2,然后打开子部分 A3。他可以在 BB2B3 中做同样的事情。但他也可以这样做:

A -> A2 -> A3 -> B2 -> A3 -> B2 -> A3 -> ... !OOM Exception!

很遗憾,我们不允许更改应用程序的设计。

如何防止应用程序创建许多活动并使堆栈大小增长过多?当 activity 停止时,我们会 尽可能多地清理 (释放资源,回收位图)但这只是限制了问题的规模,并没有消除它。

我们现在正在考虑将所有活动标记为 singleInstance。你怎么看这个(是的,它很丑)?或者我们可以通过其他更智能的方式以某种方式限制堆栈大小吗?

这是我们选择的解决方案,似乎以令人满意的方式工作:

  • 打开主要部分 ABCD 时,我们使用 FLAG_ACTIVITY_NEW_TASKFLAG_ACTIVITY_CLEAR_TASK 的意图。这种方法确保我们在用户进入主要部分时重置堆栈。 In the documentation 事实上,他们在可能与我们面临的情况相关的情况下建议使用这些标志:

    This flag is generally used by activities that want to present a "launcher" style behavior: they give the user a list of separate things that can be done, which otherwise run completely independently of the activity launching them.

  • to deal with the "chains of (d)oom" we are going to use FLAG_ACTIVITY_CLEAR_TOP. This way in a setting like this:

    A -> A2 -> A3 -> B2 ( -> A3 )
    

    当用户打开 A3 activity 时,堆栈是 "collapsed" 到此:

    A -> A2 -> A3
    

它不完美但合理,至少在我们的用例中是这样。