整理ViewPager和fragment使用过程中遇到的坑，并封装懒加载fragment

前沿：在使用ViewPager和fragment的时候，如果不了解其运行机制，就会造成网络请求滥用和界面的过度绘制，使界面出现卡顿的现象，所以今天开篇文章来记录这一类的问题，并推荐一种好的解决方案出来

• 先介绍一波加载的时候会调用哪些方法吧

      //对用户可见发生改变时候调用
      setUserVisibleHint(isVisibleToUser: Boolean)
      onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View?
      onViewCreated(view: View?, savedInstanceState: Bundle?)
      onDestroyView()
  

根据我们使用viewpager的常识知道默认情况下他会加载选中页的两边，这是因为他的

   getOffscreenPageLimit() 默认等于1

先上传一张图片，来模拟一下场景

TIM截图20180717105040.png

如图，头顶是一个tablayout，下边是我们的viewpager和fragment，首次加载的时候我们会加载1，2两个fragment，这看上去好像是没有问题的
fragment 1 ， 2所走的生命周期包括

      setUserVisibleHint(isVisibleToUser: Boolean)
      onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View?
      onViewCreated(view: View?, savedInstanceState: Bundle?)

我们接下来滑动到第三个fragment，会保存下来的fragment包括2 ，3 ，4，而第一个会销毁掉
fragment 1 的生命周期会发生如下变化

onDestroyView()

那当我们再次回到fragment 1 的时候 因为我们的视图已经销毁掉了 ，所以我们会再次创建我们的视图，生命周期如下

   onCreateView(inflater: LayoutInflater?, container: ViewGroup?, savedInstanceState: Bundle?): View? 
   onViewCreated(view: View?, savedInstanceState: Bundle?)

现在，我们可以思考一下，这中间是否有一些不必要的过程，我们可以避免掉，前边我们讲过，加载选中视图的两边和一个值有关的offscreenPageLimit，那我们依照着这个思路来处理一下，将offscreenPageLimit的值设置为fragments的size - 1，不就可以完全不会走onDestroyView()了吗，能够避免视图的销毁和重新创建。
这么一想好像蛮对的哈，但是我们的一进来就创建6个View，发送6个网络请求，这真的合理吗？如果你的代码也不怎么规范，或者后端的哥们不给力，你要做的操作将会更多，这显然不是很合理的。
细心的你们肯定已经发现了最上面还有一个方法我们没有用到

    setUserVisibleHint(isVisibleToUser: Boolean)

这个方法的意思的对用户可见的时候进行提示，当对用户可见的时候isVisibleToUser为true，反之false，这个方法在初始化的时候是在onCreate()之前调用的

语言是苍白的，先上代码再说

   override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
    if (rootView == null) {
        rootView = inflater.inflate(layoutId, container, false)
    }
    return rootView
}
  override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    if (!isInitUi) {
        isInitUi = true
        initUiAndListener()
        if (!isRequest) {
            isRequest = true
            net()
        }
    }
}
override fun setUserVisibleHint(isVisibleToUser: Boolean) {
    super.setUserVisibleHint(isVisibleToUser)
    if (isVisibleToUser && !isRequest && isInitUi) {
        isRequest = true
        net()
    }
}

分析如下：

• onCreateView：首先我们在创建View的时候提取了成员变量，判断他是否为null，为null在创建View，这样就解决了重复创建View的问题。
• onViewCreated：然后在 initUiAndListener()里面初始化一些控件的操作，因为涉及到布局被销毁的情况，所以在布局被重新创建的时候 onViewCreated()会被重新创建调用一次，这个在普通情况下是没有感知的，如果是你在里面做了添加头布局的操作就会出现很明显的bug，和当前fragment超出了offscreenPageLimit的限制过后，再返回当前fragment就会多出一个头布局，所以，我们这里用布尔值做了一个控制，这就解决了重复初始化的问题。
• setUserVisibleHint：这个方法主要是针对我们的网络请求，做的一个简单封装，只要界面对用户可见，并且没有请求过网络的，才去做网络请求，这样就解决了重复请求网络的问题。

最后附上完整的懒加载代码：

 abstract class LazyFragment : Fragment() {

        var mContext: Context? = null
        private var rootView: View? = null
        var isRequest = false
        var isInitUi = false

        @get:LayoutRes
        abstract val layoutId: Int

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?,  savedInstanceState: Bundle?): View? {
        if (rootView == null) {
            rootView = inflater.inflate(layoutId, container, false)
        }
        return rootView
    }

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        if (!isInitUi) {
            isInitUi = true
            initUiAndListener()
            if (!isRequest&& userVisibleHint) {
                isRequest = true
                net()
            }
        }
    }

    override fun onAttach(context: Context?) {
        super.onAttach(context)
        mContext = context
    }

    abstract fun initUiAndListener()


    abstract fun net()

    override fun setUserVisibleHint(isVisibleToUser: Boolean) {
        super.setUserVisibleHint(isVisibleToUser)
        if (isVisibleToUser && !isRequest && isInitUi) {
            isRequest = true
            net()
        }
    }
 }

感谢大雨的指正，相关代码已修改，这个算是一个完整版吧
全剧终