Android如何限制返回栈的大小?
How to limit the size of the back stack in Android?
我们正在开发一个 Android 包含大量视图的应用程序(用于展示公司目录)。
该应用程序的设计存在一些缺陷,主要是因为我们 "forced" 尽可能模仿现有的 iOS 版本的应用程序(我知道,这是错误的)。现在我们面临一些内存问题(=OOM 异常),主要是因为导航不是非常结构化,我们不能强制导航的 "finite" 深度:目前用户可以使后台堆栈增长尽可能多他想要。
让我试着用更好的方式解释。在我们的应用程序中,我们有 4 个部分 A
、B
、C
和 D
。用户可以输入部分 A
,打开子部分 A2
,然后打开子部分 A3
。他可以在 B
和 B2
和 B3
中做同样的事情。但他也可以这样做:
A -> A2 -> A3 -> B2 -> A3 -> B2 -> A3 -> ... !OOM Exception!
很遗憾,我们不允许更改应用程序的设计。
如何防止应用程序创建许多活动并使堆栈大小增长过多?当 activity 停止时,我们会 尽可能多地清理 (释放资源,回收位图)但这只是限制了问题的规模,并没有消除它。
我们现在正在考虑将所有活动标记为 singleInstance。你怎么看这个(是的,它很丑)?或者我们可以通过其他更智能的方式以某种方式限制堆栈大小吗?
这是我们选择的解决方案,似乎以令人满意的方式工作:
- 打开主要部分
A
、B
、C
或 D
时,我们使用 FLAG_ACTIVITY_NEW_TASK
和 FLAG_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
它不完美但合理,至少在我们的用例中是这样。
我们正在开发一个 Android 包含大量视图的应用程序(用于展示公司目录)。
该应用程序的设计存在一些缺陷,主要是因为我们 "forced" 尽可能模仿现有的 iOS 版本的应用程序(我知道,这是错误的)。现在我们面临一些内存问题(=OOM 异常),主要是因为导航不是非常结构化,我们不能强制导航的 "finite" 深度:目前用户可以使后台堆栈增长尽可能多他想要。
让我试着用更好的方式解释。在我们的应用程序中,我们有 4 个部分 A
、B
、C
和 D
。用户可以输入部分 A
,打开子部分 A2
,然后打开子部分 A3
。他可以在 B
和 B2
和 B3
中做同样的事情。但他也可以这样做:
A -> A2 -> A3 -> B2 -> A3 -> B2 -> A3 -> ... !OOM Exception!
很遗憾,我们不允许更改应用程序的设计。
如何防止应用程序创建许多活动并使堆栈大小增长过多?当 activity 停止时,我们会 尽可能多地清理 (释放资源,回收位图)但这只是限制了问题的规模,并没有消除它。
我们现在正在考虑将所有活动标记为 singleInstance。你怎么看这个(是的,它很丑)?或者我们可以通过其他更智能的方式以某种方式限制堆栈大小吗?
这是我们选择的解决方案,似乎以令人满意的方式工作:
- 打开主要部分
A
、B
、C
或D
时,我们使用FLAG_ACTIVITY_NEW_TASK
和FLAG_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
它不完美但合理,至少在我们的用例中是这样。