欢迎访问移动开发之家(rcyd.net),关注移动开发教程。移动开发之家  移动开发问答|  每日更新
页面位置 : > > > 内容正文

Android开发Viewbinding委托实例详解,

来源: 开发者 投稿于  被查看 30124 次 评论:214

Android开发Viewbinding委托实例详解,


目录
  • 背景
  • 从Crash到有意思的源码
    • 有趣的代码
    • 另外一些有意思的地方
  • 结尾

    背景

    前一阵子我们在使用viewbinding的委托的时候碰到了点crash问题,然后发现了一个比较有意思的解决方案,就和大家展开聊聊。

    另外一点就是我后面打算将kotlin extensions这个插件统一移除掉。

    估计大家应该对Viewbinding的委托应该都有一定的了解,好几个大佬分享过类似的文章,但是大佬们的代码貌似也有一阵子都没有维护了,所以我找到了一个外国大佬写的仓库,其实应该算是一个相对来说比较稳定的库了,而且也一直处于一个持续更新迭代的状态。

    仓库地址 ViewBindingPropertyDelegate

    从Crash到有意思的源码

    委托模式是软件设计模式中的一项基本技巧。在委托模式中,有两个对象参与处理同一个请求,接受请求的对象将请求委托给另一个对象来处理。

    Kotlin 直接支持委托模式,更加优雅,简洁。Kotlin 通过关键字 by 实现委托。

    上述是kotlin对于委托的释义,Viewbinding委托就是把生成Viewbinding实例的过程交给委托类去完成,然后让使用方可以忽略掉其中的细节,是一种非常好玩的模式了。

    但是由于Viewbinding的特殊性,它其实就会和当前的lifecycle绑定在一起。因为我们要在销毁的情况下把实例重置为空。否则当我们页面重新生成的情况下,就会出现view并不是当前的页面的困扰。

    作者在定义的时候就将Viewbinding委托获取的实例定义为了非空,这里我和我的同事其实是存在一些分歧的,我认为非空其实挺合理的,但是对方并不认为。

    恰巧这种空非空的问题,在实际的使用中就出现了很多不可预期的crash问题。比如说在一个异步操作中获取viewbinding实例然后进行赋值操作,就会出现空指针异常。另外由于使用的是lifecycle的页面销毁方法,如果我们复写了销毁方法之后在设置这个值,也会出现崩溃问题。

    上述问题我在几个我之前参考的库中其实都发现了对应的问题。我参考了Binding,还有之前彭旭说的那个也有类似的情况。

    另外在fragment中,其实问题尤其的明显。因为我们很多时候使用的fragment相关的LifecycleOwner是fragment本身,但是Android官方其实推荐我们使用的是fragment内部的view相关的LifecycleOwner。因为fragment相比较于activity,存在的问题就是多了几个生命周期,比如createView,和onDestroyView。其中出现最多问题的也就是onDestroyView和onDestroy。

    有趣的代码

    接下来我们看下这个作者是如何解决这些奇奇怪怪的问题的哦。

    private class FragmentViewBindingProperty<in F : Fragment, out T : ViewBinding>(
        private val viewNeedInitialization: Boolean,
        viewBinder: (F) -> T,
        onViewDestroyed: (T) -> Unit,
    ) : LifecycleViewBindingProperty<F, T>(viewBinder, onViewDestroyed) {
        private var fragmentLifecycleCallbacks: FragmentManager.FragmentLifecycleCallbacks? = null
        private var fragmentManager: Reference<FragmentManager>? = null
        // 赋值操作
        override fun getValue(thisRef: F, property: KProperty<*>): T {
            val viewBinding = super.getValue(thisRef, property)
            registerFragmentLifecycleCallbacksIfNeeded(thisRef)
            return viewBinding
        }
        private fun registerFragmentLifecycleCallbacksIfNeeded(fragment: Fragment) {
            if (fragmentLifecycleCallbacks != null) return
            val fragmentManager = fragment.parentFragmentManager.also { fm ->
                this.fragmentManager = WeakReference(fm)
            }
            fragmentLifecycleCallbacks = ClearOnDestroy(fragment).also { callbacks ->
                fragmentManager.registerFragmentLifecycleCallbacks(callbacks, false)
            }
        }
        override fun isViewInitialized(thisRef: F): Boolean {
            if (!viewNeedInitialization) return true
            if (thisRef !is DialogFragment) {
                return thisRef.view != null
            } else {
                return super.isViewInitialized(thisRef)
            }
        }
        override fun clear() {
            super.clear()
            fragmentManager?.get()?.let { fragmentManager ->
                fragmentLifecycleCallbacks?.let(fragmentManager::unregisterFragmentLifecycleCallbacks)
            }
            fragmentManager = null
            fragmentLifecycleCallbacks = null
        }
        override fun getLifecycleOwner(thisRef: F): LifecycleOwner {
            try {
                return thisRef.viewLifecycleOwner
            } catch (ignored: IllegalStateException) {
                error("Fragment doesn't have view associated with it or the view has been destroyed")
            }
        }
        // 有意思的代码
        private inner class ClearOnDestroy(
            fragment: Fragment
        ) : FragmentManager.FragmentLifecycleCallbacks() {
            private var fragment: Reference<Fragment> = WeakReference(fragment)
            override fun onFragmentDestroyed(fm: FragmentManager, f: Fragment) {
                // Fix for destroying view for case with issue of navigation
                if (fragment.get() === f) {
                    postClear()
                }
            }
        }
    }
    

    从上述代码上我们可以看出来,其中获取的LifecycleOwner就是我上文说的viewLifecycleOwner。这个就其实已经非常精彩了。

    另外我们可以看下他在内部定义了ClearOnDestroy这个类,然后当onFragmentDestroyed触发的时候调用postClear方法。而这个方法就是解决当我们在Destroyed中还执行了ViewBinding内的对象的操作的空指针问题。

    经典面试题的真实使用场景,Handler.post执行。很多人觉得Handler相关的面试题都是八股文,这次我们就通过这个真是场景来给大家说说这个有意思的问题。

    首先从onFragmentDestroyed方法会执行在Fragment本身的onDestroyView之前,原来我们会在这个方法下执行引用清空的操作。然后当onDestroyView执行的时候就会出现空指针异常了。那么Lifecycle有没有提供一个在onDestroyView之后的方法呢?我们是不是可以考虑自己造一个呢?面试中,我们知道所有生命周期方法都是有主线程Handler来负责调度的,这也就是说活我么可以把生命周期方法认为就是一个Message,当onFragmentDestroyed执行的时候,onDestroyView也已经被添加到主线程的MessageQueue中,这个时候我们在post一个runnable,那么他的排序规则上来说,就必然在onDestroyView之后了。

    另外一些有意思的地方

    这个库另外一个优点就是他同时支持反射和非反射的写法。同时也支持了Activity,Fragment,View,FragmentDialog,ViewHolder等等。反射写法是基于非反射写法的,所以也保证了底层库的一致性。

        //非反射写法
        private val viewBinding by viewBinding(ViewProfileBinding::bind)
        //反射写法
        private val viewBinding: ItemProfileBinding by viewBinding()
    

    同时他的反射相关的混淆配置文件也非常有意思。

    allowoptimization 指定对象可能会被优化,即使他们被keep选项保留。所指定对象可能会被改变(优化步骤),但可能不会被混淆或者删除。该修饰符只对实现异常要求有用。

    -keep,allowoptimization class * implements androidx.viewbinding.ViewBinding {
        public static *** bind(android.view.View);
        public static *** inflate(...);
    }
    

    它只会keep实现了ViewBinding的类的bind和inflate方法。因为ViewBinding会将所有的xml转化成一个类实例,如果不删除掉没有实际被调用的类的情况下就会导致dex包变大,大家对于包体积优化都是有追求的吗。然后用了-keep,allowoptimization,这样在混淆的代码优化过程中就可以删除掉没有被调用的ViewBinding类了。

    结尾

    本次内卷到此结束。但是又是一个老生常谈的话题,一个开源库还是要持续的进行迭代和解决问题才能持续变好,而不是一次性的工作。拥抱变化的代码世界,解决一些奇奇怪怪的问题,都是挺好玩的,更多关于Android开发Viewbinding委托的资料请关注3672js教程其它相关文章!

    您可能感兴趣的文章:
    • Android使用ViewBinding的详细步骤(Kotlin简易版)
    • Android ViewBinding的使用详解
    • Android Studio 3.6中新的视图绑定工具ViewBinding 用法详解
    • Android Studio3.6新特性之视图绑定ViewBinding使用指南

    用户评论