我终于想到你应该编写一个代码ActivityMapper来解析/检查Place其getActivity(Place)方法被传递的子类，并返回适当Activity的呈现给用户。
所以这让我开始思考：在你的应用程序中需要许多不同的子类是有道理Place的，每个子类代表一个不同的可书签 URL/状态。
但是为什么一个应用程序需要超过 1ActivityManager和Activity Mapper？似乎没有 GWT 对哪个Place映射到哪个Activity...
我听说过一些策略，每个显示区域都有自己的ActivityManager. 看起来我也喜欢这样只会让你的项目更复杂而没有提供任何真正的好处。提前致谢！
编写了一个包含 10 个这样的显示区域的应用程序后，我可以向您保证，它使我们的项目比使用单个显示区域要简单得多（我们可以删除几个区域，然后在没有活动的情况下处理，但仍然如此）。
当您的显示区域并非全部同时更改时，它被证明是最有用的（通常，您的主要内容比外围或辅助内容更频繁地更改）：假设您正在编辑一个非常复杂的实体并将其拆分为数十个屏幕和屏幕上的东西总是相同的（例如顶部实体的摘要，为用户提供上下文）。
将您的活动专门化也很棒（关注点分离，每个活动一个关注点）。例如，在 stackoverflow（如果是 GWT 应用程序）上，右侧的侧边栏可能与问题及其答案在同一个活动中，但如果你将事物分成不同的活动，每个活动都会变得更简单，因此更容易维护。
最后，可以更容易地重组专门的活动。例如，一个被分成 2 个活动的主从细节可以很容易地从“同一屏幕上的主/子”（与显示邮件列表和所选消息的大多数邮件客户端相同）更改为“主到子并返回到master”（默认情况下与 GMail 一样，与大多数移动应用程序一样）。而且这种重组并不是要改变您在应用程序中导航的方式，而是要根据外形重用相同的活动来进行不同的导航（并且使用 MVP，您还可以在不更改演示者的情况下调整视图）。
话虽如此，确实有许多应用程序不需要/不需要这样做。这并不意味着它没有用。
查看有关该主题的 Thomas Broyer 文章http://blog.ltgt.net/gwt-21-activities-nesting-yagni/
我试图在一个 github 项目中实现他的想法：https ://github.com/ronanquillevere/GWT-Multi-Activities