我正在启动一个 Honeycomb 应用程序，该应用程序将具有基本的两个面板布局，左侧面板用于菜单，右侧面板用于每个部分的主要功能。
与 Fragments API 的可用示例相反，右侧面板上显示的内容由每个菜单选项的完全不同的 UI 组成。
根据所选部分替换正确的片段是很诱人的，但这意味着在整个应用程序中只使用一个活动，这听起来不太好。此外，fragment 的生命周期与 Activity 相关联，因此在 Activity 被杀死之前不会杀死任何 Fragment，从而导致很多 Fragment “活着”。
然而，对于每个菜单选项有两个面板的不同活动意味着用于菜单的片段必须添加到每个活动中，并且将受到所有应该有菜单的部分的布局不一致的影响。
这里有哪些最佳实践？
这篇博文总结了选择片段而不是活动的原因：
通过 ActivityGroup 嵌入 Activity 是一个好主意，但一直很难处理，因为 Activity 被设计为独立的自包含组件，而不是与其他 Activity 密切交互。Fragment API 是一个更好的解决方案，应该被视为嵌入式活动的替代品。
跨 Activity 实例保留数据可以通过 Activity.onRetainNonConfigurationInstance() 来完成，但这是相当笨拙且不明显的。Fragment 通过允许您仅通过设置标志来保留整个 Fragment 实例来替换该机制。
Fragment 的一种特殊化称为 DialogFragment 可以轻松显示作为 Activity 生命周期的一部分进行管理的 Dialog。这取代了 Activity 的“托管对话”API。
Fragment 的另一种特殊化称为 ListFragment 可以很容易地显示数据列表。这类似于现有的 ListActivity（具有更多功能），但应该减少有关如何显示带有其他一些数据的列表的常见问题。
有关当前附加到活动的所有片段的信息由框架以活动的已保存实例状态为您保存，并在重新启动时为您恢复。这可以大大减少您需要自己编写的状态保存和恢复代码量。
该框架内置了对管理 Fragment 对象的后退堆栈的支持，从而可以轻松地提供集成现有活动后退堆栈的活动内后退按钮行为。此状态也会自动为您保存和恢复。
片段是相当新的，所以除了那篇文章，我不确定你会找到很多最佳实践。我认为您需要做出的决定是我的交互紧密耦合并旨在共享数据，或者它们是没有太多交互的独立组件。
编辑，澄清：我认为为应用程序使用单个活动不一定是一个错误的决定。这确实是您应该根据应用程序的功能做出的决定。根据这篇文章，一个 Activity 是独立的，而一个片段通常只有在与 Activity 范围内的其他片段组合时才相关。你描述的情况，不同活动的组合是他们设计 Fragments 来解决的痛点之一。