这两个月经历了萌发离职念头到开始复习、投简历、面试、走流程，终于在这周入职了新公司。所以现在又可以开始写写博客，不用分太多精力在找工作上面了。
这两天我接到一个新的需求，是关于排行榜模块的，界面的实现和网易新闻的TabBarLayout + ViewPager是一样的，为了方便快速构造多个Fragment和对其进行管理，我们使用了FragmentPagerAdapte作为ViewPager的适配器。
在做的过程中遇到一些很有意思的问题，比如榜单总共有4页，每页又是一个ViewPager，里面包含3个Fragment，具体如下图：
当我从第一个榜单滑动到最后一个榜单，再滑动到前面的榜单的时候，发现TabBarLayout底部的的那行标题文字不会随着页面的滚动而滚动了，比如现在页面停留在"周榜"，而顶部的标题显示的是"总榜"。
初步猜想是和ViewPager的离屏缓存策略有关。
什么是ViewPager离屏缓存策略？
其实和我们使用RecyclerView会对Item进行回收、重新使用类似，不过ViewPager(FragmentPagerAdapter)重点不在于对Fragment进行回收利用，而是将其界面上的控件进行销毁，以确保不会占用过多的内容，默认的缓存是缓存前一屏和后一屏的Fragment。
那么被清理的Fragment会发生什么事？我们先来看一下它被清理时候的生命周期
11-15 21:32:35.926 TestFragmentA: onPause54398751
11-15 21:32:35.927 TestFragmentA: onStop54398751
11-15 21:32:35.928 TestFragmentA: onDestroyView54398751
通过上面的log可以发现onDestroyView会被调用，然后view就会被标记为脏view。
当Fragment重新进入到缓存限制范围内之后，它的生命周期为：
11-15 21:32:34.447 TestFragmentA: onCreateView54398751
11-15 21:32:34.455 TestFragmentA: onActivityCreated54398751
11-15 21:32:34.458 TestFragmentA: onStart54398751
11-15 21:32:34.459 TestFragmentA: onResume54398751
通过上面的两段log，我们可以得出这样一个结论：当Fragment超出限制范围之后，它的view会被销毁，但是它本身不会被销毁(hashCode相同)。
这就是第一个有趣的点：
- ViewPager搭配FragmentPagerAdapter使用的时候会有离屏缓存策略。
- 被清理的Fragment的生命周期不是完整的生命周期(可以作为考点)。
如果我们的Fragment个数少、内容简单，也就是说不做清理也对内存不会有太大的影响，那么我们应该如何处理？
有两种方案
- 通过设置
viewPager.setOffscreenPageLimit(count)来更改离屏缓存策略。 - 参考ListView，在onCreateView中保存view。
这里我们讨论第二点，下面先贴一段代码：
@Override
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
mInflater = inflater;
if (mRootView == null) {
mRootView = inflater.inflate(getLayoutRes(), container, false);
unbinder = ButterKnife.bind(this, mRootView);
initMembers(); // 初始化成员变量
initWidgets(); // 初始化控件
setEventsListeners(); // 设置事件处理器
initData(getArguments());
} else {
ViewGroup parent = (ViewGroup) mRootView.getParent();
if (parent != null) {
parent.removeView(mRootView);
}
}
return mRootView;
}
@Override
public void onDestroyView() {
super.onDestroyView();
EvtLog.d(TAG, "onDestoryView");
try {
unbinder.unbind();
} catch (Exception e) {
// ignore
}
}
逻辑很简单，就是如果rootView为空，则inflater，并且进行一些数据填充，否则就将rootView从其父容器中移除。最后将rootView返回。
不知道大家有没有发现上面代码中的问题，那就是ButterKnife，在onDestoryView的时候，我们进行了解绑操作，所以rootView里面的所有通过@BindView绑定的属性都会被置为空，而当Fragment下次再调用onCreateView的时候是不会进入if分支里面，从而会导致找不到标题控件，所以因此无法对其进行文本设置(已做非空判断，所以没有空指针)。
这算不算另外一点有趣的东西？ 哈哈。
所以如果想要这种缓存rootView策略的话，建议不要用ButterKnife。
其实把内容拆开，每一个点看上去都没什么问题，都是一些比较常用的写法，但是当这些小东西组合起来之后，就可能会产生一些不一样的效果。
回到文章开头提到的问题，我最后是通过设置viewPager.setOffscreenPageLimit(3)，让ViewPager不对Fragment视图做回收处理。
之所以不取消ButterKnife，是因为通过ButterKnife，我们不需要专门抽一个、两个方法来进行find操作。我将这四个界面抽了一个基类，其中有一个界面会多了一些控件，通过使用ButterKnife，使代码逻辑上更加清晰，不用为了满足这个特别的子类，特意去抽一个抽象方法，符合开放-封闭原则。
