Android support v4中的Fragment和app包中的Fragment

Fragment是Android3.0之后加入的新特性，需要API11以上的SDK版本才能兼容，然而市面上有很多手机依然是3.0以下的系统，谷歌为了兼容低版本，于是开发了Android support v4包，里面的Fragment能够在最低API4的版本下运行,而且v4里面的Fragment还能嵌在一个名叫ViewPager的控件中，形成多页侧滑的效果。

我们一般的APP中，主要的界面有很多都是底部多标签切换的形式，这种形式我们很自然的想到通过ViewPager来构建一个多页面侧滑的效果，并可以和底部的RadioGroup实现联动。我的确一直都是这么做的，当时也并未想到有什么不妥，直到今天在一个包含五个Fragment的Activity上做操作时，发现视图的加载很不流畅，尤其是我加入了一个下拉刷新的功能之后，发现下拉刷新的下拉动作变得非常困难。如何解释这种困难，大约就是当我费尽心思用手指在屏幕上滑动时，根本看不到下拉的效果，或者是手指滑过整个屏幕，但是却仅仅把视图下拉了非常微小和距离，而且在下拉动画一点都不流畅，有明显的掉帧和卡顿现象。

我百思不得其解，最初认为是在主线程中执行了太多的操作导致的，于是将所有加载数据的动作全部禁用，仅保留基本视图的加载，经过这样处理，结果收效甚微，几乎看不到明显的改善。我越发疑惑，仅仅是加载几个空的布局而已，况且布局并不复杂，为什么视觉效果上还是这么卡顿？于是换一种方式来检测原因，保留所有的数据加载，但是不使用Fragment，全部在Activity中执行，将这5个Fragment中的内容全部迁移到Activity中来。先不说结果，估且设想一下，没有了Fragment分摊Activity的工作，视图的加载理应变得更慢才是。

结果自然出乎我的意料，Activity的加载虽然没有变得十分之快，但较之5个Fragment时期却反而流畅了一些。我想可能是Activity主线程加载布局太多，毕竟我之前的5个Fragment每个都有整屏幕的内容，5合1,各种重叠，我几乎看不清它们之中的任何一个，慢也是正常的，但比5个Fragment的时候快，我于是想到可能是ViewPager的原因了。

ViewPager下的Fragment是v4包中的Fragment，为了兼容低版本而存在，则必然要牺牲某些性能以实现兼容，另外我认为自己并不是很需要ViewPager的侧滑效果，甚至是需要取消这种效果，基于这些原因，我删除了项目中的ViewPager，并使用普通的app包中的Fragment，其他和之前完全一样，仅仅是v4中的Fragment换成了API11以上才能使用的普通app包中的Fragment，令人振奋的是，下拉的动画变得流畅许多，从叫人完全不能接受的卡顿变成了完全可以接受的流畅度。

具体原因暂时没有仔细研究源码，猜想原因大约有以下几点：

1.普通的Fragment比v4包中的Fragment性能要好，毕竟按常理来说，兼容性必然是以牺牲某些性能作为代价的。

2.ViewPager有页面缓存，在使用ViewPager管理Fragment的时候往往容易忽略对Fragment本身的管理，而且ViewPager管理下的Fragment生命周期和普通的Fragment的生命周期有区别。

3.ViewPager+Fragment，如果每个Fragment都占一屏的话，根据ViewPager的缓存，它实际上会同时加载左右两边缓存的页面，除了数据，视图也会同时加载，等于是一个Activity承担几个Activity面积的视图加载任务，这种缓存不可取消，最少也得有左右相邻各一个同时加载，或许这一点才是视图卡顿的真正原因。

使用普通的Fragment之后再对其生命周期进行管控，适当的销毁和重用某些视图，就能实现较为流畅的视觉效果了。