关于kotlin中的by lazy初始化view的一些探究

项目场景：

开发完需求，及时来一波CR。第一次接触kotlin写代码，在很多代码中都看到过关于使用 by lazy去初始化一个view的写法。

private val mView: View? by lazy { view?.findViewById<View>(R.id.my_view) }

乍一看 好像没什么不对：使用了懒加载，在需要用到mView的时候再去findView从当前的view中获取mView实例，同时使用by lazy创建的变量仅仅初始化一次并且全局共享。

让我们再来看看fragment的生命周期图

---

问题描述：

我们来看这样一个场景
构建出一个fragment，它有自己的数据和UI对象实例，然后我们构建出第二个fragment，通过fragmentManager的replace替换掉第一个fragment，但同时我们还要将第一个fragment放进返回栈中（构造出上图-fragment生命周期中的返回路线- onDestroyView -> onCreateView)
我们使用这样的写法

看起来好像没什么问题 在fragment交换时对应的生命周期回调也能正常触发
第一次进入

按下按钮后 进入第二个fragment 再返回到第一个fragment f1执行如下的生命周期

再来看看界面显示

文本内容消失，按钮也不再响应点击事件；但程序并没有抛出异常

---

原因分析：

通过将 页面上的 textView的hashCode打印出来我们可以看到，虽然fragment1重建了 但textView并没有一起更新

可以看到，在一个activity的生命周期中，fragment可以经历多次的createView和destroyView。而当我们在by lazy中使用 view.findById时，这个view所对应的fragment可能已经被销毁，由于by lazy只初始化一次，因此我们是有可能拿到旧的fragment所对应的view实例的，那么此时我们再在这个view对象身上对各控件进行操作自然是不会映射到当前的fragment上的。

---

解决方案：

使用lateInit进行懒加载 或使用holder进行管理，在更新view时也将各控件同步更新，而by lazy更适合用于对final类型的数据进行初始化

虽然这样的问题场景并不多见，合理的编码设计也能帮助我们规避这一问题，但是通过这一次的探究加深了我们对fragment生命周期的理解以及对kotlin的认识。