如何限制Android中后端堆栈的大小？

Question

我们正在开发一个包含非常繁重视图的Android应用程序（用于显示公司的目录）。

该应用程序的设计存在一些缺陷，主要是因为我们“被迫”尽可能多地模仿应用程序的现有iOS版本（我知道，这是错误的）。现在我们面临一些内存问题（= OOM异常），主要是因为导航结构不是很好而且我们无法强制导航的“有限”深度：此时用户可以使后端堆栈增长到他想要的程度

让我试着以更好的方式解释。在我们的应用中，我们有4个部分A，B，C和D。用户可以输入部分A，打开子部分A2，然后输入子部分A3。他可以使用B和B2在B3中执行相同的操作。但他也可以这样做：

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

不幸的是，我们不允许更改应用程序的设计。

如何阻止应用创建许多活动并使堆栈大小增长太多？当活动停止时，我们尽可能多地进行清理（释放资源，回收位图），但这只是限制了问题的大小，它并没有消除它。

我们现在考虑将所有活动标记为 singleInstance 。你怎么看待这个（是的，它很难看）？或者我们能以某种其他更聪明的方式限制堆栈大小吗？

Answer 1

这是我们选择的解决方案，似乎以令人满意的方式运作：

• 在打开主要部分A，B，C或D时，我们会使用FLAG_ACTIVITY_NEW_TASK和FLAG_ACTIVITY_CLEAR_TASK的意图。这种方法确保我们在用户进入主要部分时重置堆栈。 In the documentation实际上他们在可能与我们面临的情况有关的情况下建议这些标志：

    

  此标志通常由想要展示＆＃34;启动器＆＃34;的活动使用。样式行为：它们为用户提供了可以完成的单独事物的列表，否则完全独立于启动它们的活动。

  

• 处理（d）oom＆＃34;的链条。我们将使用FLAG_ACTIVITY_CLEAR_TOP。这种方式在这样的设置中：

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

  当用户打开A3个活动时，该堆栈已经崩溃了＃34;对此：

  A -> A2 -> A3
  

这不完美但合理，至少在我们的使用案例中。