Android开发应该重视一下Fragment

为什么要提倡用Fragment开发APP呢？不使用Fragment也能开大Android的应用，为什么要绕这个弯子呢？Fragment有什么优点？希望大家读完本篇文章能有个新的认识。

作为Android开发者可以使用两个主要的Class来搞定一个APP，使用Activity和Fragment。Activity是先入为主，和我一样的老程序员都习惯于使用Activity来构建项目，可以说它统治了开发很长时间。用户使用你的 App 时所看到的、与之交互的界面，是被某个 activity 托管和控制的。大部分代码存在于这些 Activity 类内，某个时刻通常会有一个 activity 处于可见状态。

举个栗子，一个简单的 activity 看起来像这样：

public class MainActivity extends Activity {
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
    }
}

Fragment 类是在 Honeycomb（注：蜂巢 3.0 API level 11）发布时被介绍的。它允许我们把应用组件分解成可重用的部件。Fragment必须被一个 activity 托管，而一个 activity 可以一次托管一个或多个 fragment。

一个简单的 fragment 看起来和 activity 很像，但是具有不同的生命周期回调方法。下面的 fragment 代码段和上面的 activity 代码段完成了相同的事情：建立视图。

public class MainFragment extends Fragment {
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        return inflater.inflate(R.layout.fragment_main, container, false);
    }
}

如你所见，activities 和 fragments 看起来非常像，同样被用于构建app。所以，使用 fragments 可以带来什么优势呢？且听我一一道来

Device Optimization 设备优化

我刚刚讲过，Honeycomb 发布时引入了 fragments。Honeycomb 版本首次对平板设备提供了正式支持。fragment 理念的最初目标之一是帮助开发者在构建手机和平板应用时提供不同的用户体验。

邮件客户端是用到 fragment 的典型例子，比如 Gmail App。手机版展示了用户的邮件列表，点击其中一个就跳转到展示邮件内容的详情界面。这个过程包含了两个界面，各自独占屏幕。

当用户在平板上使用 Gmail App 时，可以在一个屏幕上同时看到列表界面和详情界面。显然我们可以在平板上一次显示更多的信息。

Fragments 很容易实现这个功能。列表界面是一个 fragment，详情界面也是一个 fragment。activity 根据屏幕大小决定显示其中一个或全部。

Fragments 的优雅之处在于，不需要修改 fragment 类的代码就可以完成上述事情。作为 app 的可重用组件，fragments 可以以任意多种方式呈现给用户。

这非常棒，但如果你开发的应用不需要兼容手机和平板，还需要使用 fragments 吗？

答案是“yes”。如果将来你改变了主意（注：结合上下文，应该理解为需要大刀阔斧地改代码），你会庆幸当初使用了 fragments。从一开始并没有特别的理由不使用 fragments，但是为了使用 fragments 而重构已有的代码，将是耗时且容易出错的。除了构成UI外，Fragments 还提供了一些其它优秀特性。

ViewPager

比如，使用 fragments 可以很方便地实现 ViewPager。如果你不熟悉 ViewPager，那我就简单说说，它作为一个应用组件，允许用户滑动屏幕以切换界面。很多 app 用到了它，包括 Google Play Store app 和 Gmail app。滑动屏幕就置换了当前的 fragment。

ViewPager 瞄准了 fragments 的一个核心理念。一旦你的特定的应用代码存在于 fragments，这些 fragments 就可以以多种方式被托管。Fragment 不需关心如何被托管，它只需知道如何展示你的应用的特定部分。托管 fragments 的 activity 类，可以显示一个 fragment；或者多个 fragment；或者像 ViewPager 那样通过某种方式显示 fragments。不需要修改应用的核心代码就可以支持这些不同的显示方式。

Other Features 其它特性

所以 fragments 可以帮助我们优化应用以适应不同的屏幕尺寸，可以帮助我们为用户提供有趣的体验。除此之外，它的其它特性也可以帮到我们。

你可以把 fragment 当作一个“设计更合理”的 activity。Fragments 的生命周期允许它做一些 activity 做不到的事情：它分开了实例的创建和视图的创建。

注：作者是指 Fragment 具有 onCreate(...), onCreateView(...), onDestroyView() 等生命周期方法，这些方法使得 fragment 拥有了分开创建实例和视图、以及保存实例而仅销毁视图的能力。而 Activity 的 onCreateView(...) 并不是生命周期回调方法。

这种“分离”允许我们保存 fragment 实例。你知道的，旋转 android 设备屏幕被认为是设备配置发生了变化（配置变化还包括其它几种）。系统会寻找更合适的资源以匹配配置，这个过程中 activities 和 fragments 实例会被系统销毁，然后新的实例会被创建。android 开发者必须考虑这种销毁的情形，因为保存在 activity 和 fragment 中的所有实例变量也同样被销毁了。

“Retained fragments”在设备旋转时实例不会被销毁，仅仅是视图被销毁了，其它所有状态都会被保存下来。尽管有一些情形并不适用，retained fragment 仍是十分有用的（注：调用 setRetainInstance(true) 使 fragment 成为 retained fragment）。举个栗子，如果你从网络服务器或者数据库下载大量数据，retained fragment 在设备旋转时仍持有已下载的数据。

Additional Code 额外的代码

与不使用 fragments 相比，当你使用 fragments 构建 android app 时，你的项目会包含更多的 Java 类和略多的代码。多出来的部分代码用于把 fragment 添加给 activity，如果你不熟悉其中的机制，会相当棘手。

一些 android 开发者，特别是那些在 Honeycomb 发布前就已经在开发 android app 的，选择放弃使用 fragments。使用 fragments 带来的复杂度和需要写更多的代码是这些开发者的理由。但正如我之前所讲，使用 fragments 需要付出的这点儿努力是值得的。

Embracing Fragments 涌抱它

对于 Android 开发者而言，fragments 是一个拐点。基于 fragment 构建的应用带来显著的优势，包括基于屏幕尺寸来优化体验、结构良好和可重用的代码。并非所有的开发者涌抱了 fragments，不过现在，时候到溜。我强烈建议 android 开发者大量使用 fragments。