ViewPager懒加载极致优化，Android开发还会吃香吗

• 一个非常简单的方式就是使用每页视图作为key来关联它们自己，在方法instantiateItem(ViewGroup, int)中创建和添加它们到ViewGroup之后，返回该页视图。与之相匹配的方法destroyItem(ViewGroup, int, Object)实现从ViewGroup中移除视图。当然必须在isViewFromObject(View, Object)中这样实现：return view == object;.

• PagerAdapter支持数据改变时刷新界面，数据改变必须在主线程中调用，并在数据改变完成后调用方法notifyDataSetChanged(), 和AdapterView中派生自BaseAdapter相似。一次数据的改变可能关联着页面的添加、移除、或改变位置。ViewPager将根据adapter中实现getItemPosition(Object)方法返回的结果，来判断是否保留当前已经构造的活动页面（即重用，而不完全自行构造）。

02.ViewPager弊端分析

普通的viewpager如果你不使用setoffscreenpagelimit(int limit)这个方法去设置默认加载数的话是会默认加载页面的左右两页的，也就是说当你进入viewpager第一页的时候第二页和第一页是会被一起加载的，这样同时加载就会造成一些问题，试想我们如果设置了setoffscreenpagelimit为3的话，那么进入viewpager以后就会同时加载4个fragment，像我们平时的项目中在这些fragment中一般都是会发送网络请求的，也就是说我们有4个fragment同时发送网络请求去获取数据，这样的结果显而易见给用户的体验是不好的（如：浪费用户流量，造成卡顿等等）。

懒加载的实现弊端

• 概念：当需要时才加载，加载之后一直保持该对象。

• 而关于Fragment实现的PagerAdapter都没有完全保存其引用和状态。FragmentPageAdapter需要重建视图，FragmentStatePageAdapter使用状态恢复，View都被销毁，但是恢复的方式不同，而通常我们想得到的结果是，Fragment一旦被加载，其视图也不会被销毁，即不会再重新走一遍生命周期。而且ViewPager为了实现滑动效果，都是预加载左右两侧的页面。

• 我们通常想要实现的两种效果：不提供滑动，需要时才构造，并且只走一遍生命周期，避免在Fragment中做过多的状态保存和恢复。

03.ViewPager预加载

ViewPager的预加载机制。那么，我们可不可以设置ViewPager的预加载为0，不就解决问题了吗？也就是代码这样操作：

vp.setOffscreenPageLimit(0);

然后看一下源码

• 即使你设置为0，那么还是会在里面判断后设为默认值1。所以这个方法是行不通的。

`public void setOffscreenPageLimit(int limit) {

if (limit < 1) {

Log.w(“ViewPager”, "Requested offscreen page limit " + limit + " too small; defaulting to " + 1);

limit = 1;

}

if (limit != this.mOffscreenPageLimit) {

this.mOffscreenPageLimit = limit;

this.populate();

}

}`

ViewPager默认情况下的加载，当切换到当前页面时，会默认预加载左右两侧的布局到ViewPager中，尽管两侧的View并不可见的，我们称这种情况叫预加载；由于ViewPager对offscreenPageLimit设置了限制，页面的预加载是不可避免……

初始化缓存（mOffscreenPageLimit == 1）

• 当初始化时，当前显示页面是第0页&