可能有人请解释一下使用碎片的具体优势？在什么情况下，我们应该使用片段？

有关我个人理解，这个框架：

帮助复用现有的code - 如果我在一个片段实现的功能，那么它比较容易显示此片段在我的应用程序，当需要的功能的多个部分

帮助处理多个屏幕尺寸 - 与一个巨大的屏幕的设备也许能显示多个片段一次，而对于较小的设备，我可以在不同的活动显示片段

有没有更多的这个框架？

编辑：

我一直在使用的片段相当广泛为3.0平板电脑一个较大的项目。对我来说，最大的好处是，使用碎片，我可以打破的逻辑会去在一个单一的，整体的活动为多个较小的片段。大屏幕意味着巨大的活动，难以阅读，理解（尤其是新的团队成员），开发和维护。片段一定帮助在这件事情。

有没有更多的这个框架？

动画时，可以动态地添加和从屏幕上除去碎片效果

自动返回堆栈管理，所以BACK按钮可才最终退出活动中删除动态添加片段

与操作栏中的标签，作为替代集成 TabHost

与清单操作栏集成为基础的导航（一个真正的微调操作栏中，不同片段之间切换）

比较容易处理的配置变化礼貌 setRetainInstance（真）

此外，应对@Jim Blackler：

我分享你的困惑，因为它总是很容易查看这似乎定制（我）来解决所有的同样的问题。

由碎片提供的一切都可以按照定义，可以用做浏览，仅仅是因为碎片是建立在视图框架之上。然而，片段使涉及动态片段更容易一点恕我直言，更复杂的场景。

此外，与动作栏的片段似乎很可能是对谷歌的关注长期的区域，这意味着我期待更多的这方面的工作，在未来2-3个版本了相当数量。

Could somebody please explain the exact advantages of using Fragments? In what cases should we use Fragments?

For what I understand, this framework:

Helps reuse existing code - if I implement functionality in a Fragment, then it's relatively easy to display this fragment in multiple parts of my app, when the functionality is needed.

Helps dealing with multiple screen sizes - a device with a huge screen may be able to display multiple fragments at once, and for smaller devices I can display the fragments in separate Activities.

Is there more to this framework?

Edit:

I've been using Fragments quite extensively in a larger project for 3.0 tablets. To me the greatest advantage was that using fragments I could break up the logic that would go in a single, monolithic Activity into multiple, smaller Fragments. Big screens mean huge Activities, difficult to read, understand (especially to new team members), develop and maintain. Fragments certainly helped in this matter.

Is there more to this framework?

Animated effects available when dynamically adding and removing fragments from the screen

Automatic BACK stack management, so the BACK button can remove dynamically-added fragments before eventually exiting the activity

Integration with the action bar for tabs, as a replacement for TabHost

Integration with the action bar for "list"-based navigation (really a Spinner in the action bar, toggling between different fragments)

Somewhat easier handling of configuration changes courtesy of setRetainInstance(true)

Also, responding to @Jim Blackler:

I share your confusion, since it's always been easy to customize Views which seems (to me) to solve all the same problems.

Everything offered by fragments can, by definition, be done using Views, simply because fragments are built on top of the view framework. However, fragments make more complicated scenarios involving dynamic fragments a bit easier IMHO.

Moreover, fragments in conjunction with the action bar seem quite likely to be a long-term area of attention for Google, meaning I expect a fair amount of additional work in this area over the next 2-3 releases.