Android开发Viewbinding委托实例详解.docx

《Android开发Viewbinding委托实例详解.docx》由会员分享，可在线阅读，更多相关《Android开发Viewbinding委托实例详解.docx（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、I朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪I目录1 .背景2 .从Crash到有意思的源码1 .有趣的代码2 .另外一些有意思的地方3 .结尾二匕旦目乐前一阵子我们在使用viewbinding的委托的时候碰到了点crash问题，然后发现 了一个比拟有意思的解决方案，就和大家展开聊聊。另外一点就是我后面打算将kotlin extensions这个插件统一移除掉。估计大家应该对Viewbinding的委托应该都有一定的了解，好几个大佬提供过类 似的文章，但是大佬们的代码貌似也有一阵子都没有维护了，所以我找到了一个 外国大佬写的仓库，其实应该算是一个相对来说比拟稳定的库了，

2、而且也一直处 于一个持续更新迭代的状态。仓库地址 ViewBindingPropertyDelegate从Crash到有意思的源码委托模式是软件设计模式中的一项基本技巧。在委托模式中，有两个对象参与处 理同一个请求，接受请求的对象将请求委托给另一个对象来处理。Kotlin直接支持委托模式，更加优雅，简洁。Kotlin通过关键字by实现委托。 上述是kotlin对于委托的释义，Viewbinding委托就是把生成Viewbinding实例 的过程交给委托类去完成，然后让使用方可以忽略掉其中的细节，是一种非常好 玩的模式了。但是由于Viewbinding的特殊性，它其实就会和当前的lifecycl

3、e绑定在一起。因 为我们要在销毁的情况下把实例重置为空。否那么当我们页面重新生成的情况下， 就会出现view并不是当前的页面的困扰。作者在定义的时候就将Viewbinding委托获取的实例定义为了非空，这里我和我 的同事其实是存在一些分歧的，我认为非空其实挺合理的，但是对方并不认为。 恰巧这种空非空的问题，在实际的使用中就出现了很多不可预期的crash问题。比方说在一个异步操作中获取viewbinding实例然后进行赋值操作，就会出现空 指针异常。另外由于使用的是lifecycle的页面销毁方法，如果我们复写了销毁方 法之后在设置这个值，也会出现崩溃问题。上述问题我在几个我之前参考的库中其实都

4、发现了对应的问题。我参考了 Binding,还有之前彭旭说的那个也有类似的情况。另外在fragment中，其实问题尤其的明显。因为我们很多时候使用的fragment 相关的LifecycleOwner是fragment本身，但是Android官方其实推荐我们使用 的是fragment内部的view相关的LifecycleOwner。因为fragment相比拟于 activity,存在的问题就是多了几个生命周期，比方createView,和 onDestroyVieWo其中出现最多问题的也就是onDestroyView和on Destroy o有趣的代码接下来我们看下这个作者是如何解决这些奇奇怪

5、怪的问题的哦。12 private class FragmentViewBindingProperty(45private val viewNeedlnitialization: Boolean,6viewBinder: (F) - T,8onViewDestroyed: (T) - Unit,9):LifecycleViewBindingProperty(viewBinder onViewDestroyed) 0private var fragmentLifecycleCallbacks:1FragmentManager.FragmentLifecycleCallbacks? = null1

6、private var fragmentManager: Reference? = null 21 /赋值操作3override fun getValue(thisRef: F, property: KProperty): T val viewBinding = super.getValue(thisRefJ property) registerFragmentLifecycleCallbacksIfNeeded(thisRef)16171819202122232425262728293031323334353637return viewBindingprivate fun registerF

7、ragmentLifecycleCallbacksIfNeeded(fragment: Fragment) if (fragmentLifecycleCallbacks != null) returnval fragmentManager = fragment.parentFragmentManager.also fm -this.fragmentManager = WeakReference(fm) )fragmentLifecycleCallbacks = ClearOnDestroy(fragment).also callbacks -fragmentManager.registerFr

8、agmentLifecycleCallbacks (callbacks false)override fun isViewInitialized(thisRef: F): Boolean if (!viewNeedlnitialization) return trueif (thisRef !is DialogFragment) return thisRef.view != null else return super.isViewInitialized(thisRef)override fun clear() super.clear()fragmentManager?.get()?.let

9、fragmentManager -fragmentLifecycleCallbacks?.let(fragmentManager:u nregisterFragmentLifecycleCallbacks)383940414243444546474849505152535455565758fragmentManager = nullfragmentLifecycleCallbacks = null ) override fun getLifecycleOwner(thisRef: F): LifecycleOwner try return thisRef.viewLifecycleOwner

10、catch (ignored: IllegalStateException) error(Fragment doesn11 have view associated with it or the view has been destroyed)/有意思的代码private inner class ClearOnDestroy( fragment: Fragment):FragmentManager.FragmentLifecycleCallbacks() private var fragment: Reference = WeakReference(fragment)override fun

11、onFragmentDestroyed(fm: FragmentManagerf: Fragment) / Fix for destroying view for case with issue of navigationif (fragment.get() = f) postClear()从上述代码上我们可以看出来，其中获取的LifecycleOwner就是我上文说的 viewLifecycle0wnero这个就其实已经非常精彩了。另外我们可以看下他在内部定义了 ClearOnDestroy这个类，然后当 onFragmentDestroyed触发的时候调用postClear方法。而这个方法

12、就是解决当 我们在Destroyed中还执行了 ViewBinding内的对象的操作的空指针问题。经典面试题的真实使用场景，Handler.post执行。很多人觉得Handler相关的面 试题都是八股文，这次我们就通过这个真是场景来给大家说说这个有意思的问 题。首先从 onFragmentDestroyed 方法会执行在 Fragment 本身的 on Destroy View 前，原来我们会在这个方法下执行引用清空的操作。然后当onDestroyView执行 的时候就会出现空指针异常了。那么Lifecycle有没有提供一个在onDestroyView 之后的方法呢？我们是不是可以考虑自己造一

13、个呢？面试中，我们知道所有生命 周期方法都是有主线程Handler来负责调度的，这也就是说活我么可以把生命周 期方法认为就是一个Message,当onFragmentDestroyed执行的时候， onDestroyView也已经被添加到主线程的MessageQueue中，这个时候我们在 post 一个runnable,那么他的排序规那么上来说，就必然在onDestroyView之后了。另外一些有意思的地方这个库另外一个优点就是他同时支持反射和非反射的写法。同时也支持了 Activity, Fragment, View, FragmentDialog,ViewHolder 等等。反射写法是基于

14、 非反射写法的，所以也保证了底层库的一致性。,/非反射写法12 private val viewBinding by viewBinding(ViewProfileBinding:bind)3/反射写法private val viewBinding: ItemProfileBinding by viewBinding() 同时他的反射相关的混淆配置文件也非常有意思。allowoptimization指定对象可能会被优化，即使他们被keep选项保存。所指定 对象可能会被改变(优化步骤)，但可能不会被混淆或者删除。该修饰符只对实 现异常要求有用。-keep.,allowoptimization c

15、lass * implements12androidx.viewbinding.ViewBinding 4public static * bind(android.view.View);public static * inflate(.);它只会keep实现了 ViewBinding的类的bind和inflate方法。因为ViewBinding会将所有的 xml转化成一个类实例，如果不删除掉没有实际被调用的类的情况下就会导致dex包变大， 大家对于包体积优化都是有追求的吗。然后用了-keep,allowoptimization,这样在混淆的代码 优化过程中就可以删除掉没有被调用的ViewBinding类了。结尾本次内卷到此结束。但是又是一个老生常谈的话题，一个开源库还是要持续的进 行迭代和解决问题才能持续变好，而不是一次性的工作。拥抱变化的代码世界, 解决一些奇奇怪怪的问题，都是挺好玩的，