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