Coming from someone who actually tried to build a phone/tablet app using custom views, I don't think the accepted answer really explains the limitations of fragments and custom views.
Before I learned how fragments worked and about the compatibility jar, I attempted to create a phone/tablet app using custom views. Everything appeared to
work across phones AND tablets, even switching from single panel to split panel. Where I ran into trouble was with the back button and life cycle. Since I was simply updating views manually...there was nothing keeping track of the history of views and their
states. Therefore, the back button did not work as expected and it was difficult to recreate even the latest state during life cycle events, such as when rotating the app. To fix that, I had to wrap my custom views in fragments and use the FragmentManager
so that the previous states would be saved and recreated.
Now, Fragments are not a silver bullet or always "better" than a custom view. For example, a huge drawback of fragments is that they cannot be nested. So if you've created a wonderful fragment that you now want to re-use it inside of a dialog, you will not
be able to simply put it inside of a DialogFragment. Or if you've already created an app using 2 side-by-side panels and want to reuse a 3rd fragment inside one of the panels...it won't work either. You would have to switch to a 3-panel layout.
So, the main reason to use Fragments are for the backstack and lifecycle features. Otherwise, custom views are more light
weight, simpler to implement, and have the advantage that they can be nested.
原文地址：http://stackoverflow.com/questions/9827072/why-use-fragments/14912608#14912608
The main reason is that fragments are more reusable than custom views.
Sometimes you can't create a fully encapsulated UI component relying on views alone. This is because there are things you would want to put into your view but can't because only an Activity can handle them, thus forcing tight coupling between an Activity and
a View.
Here is one such example. Lets say you want to create a reusable UI component that, among many things, want to capture a photo and do something with it. Traditionally you would fire an intent that starts the camera and returns with the captured image.
Notice that your custom UI component can't fully encapsulate this functionality because it will have to rely on hosting Activity's startActivityForResult because
views don't accept activity results (they can indirectly fire an intent through context).
Now if you wanted to reuse your custom UI component in different activities you would be repeating the code for Activity.startActivityForResult.
Fragment on the other hand cleanly solve this problem.
Similarly your fragment can contribute items to your options menu, something traditionally only an Activity could do. Again this could be important if the state of your custom view dictates what goes in the menu.