Android開發(fā)Viewbinding委托實(shí)例詳解
背景
前一陣子我們在使用viewbinding的委托的時(shí)候碰到了點(diǎn)crash問題,然后發(fā)現(xiàn)了一個(gè)比較有意思的解決方案,就和大家展開聊聊。
另外一點(diǎn)就是我后面打算將kotlin extensions這個(gè)插件統(tǒng)一移除掉。
估計(jì)大家應(yīng)該對Viewbinding的委托應(yīng)該都有一定的了解,好幾個(gè)大佬分享過類似的文章,但是大佬們的代碼貌似也有一陣子都沒有維護(hù)了,所以我找到了一個(gè)外國大佬寫的倉庫,其實(shí)應(yīng)該算是一個(gè)相對來說比較穩(wěn)定的庫了,而且也一直處于一個(gè)持續(xù)更新迭代的狀態(tài)。
倉庫地址 ViewBindingPropertyDelegate
從Crash到有意思的源碼
委托模式是軟件設(shè)計(jì)模式中的一項(xiàng)基本技巧。在委托模式中,有兩個(gè)對象參與處理同一個(gè)請求,接受請求的對象將請求委托給另一個(gè)對象來處理。
Kotlin 直接支持委托模式,更加優(yōu)雅,簡潔。Kotlin 通過關(guān)鍵字 by 實(shí)現(xiàn)委托。
上述是kotlin對于委托的釋義,Viewbinding委托就是把生成Viewbinding實(shí)例的過程交給委托類去完成,然后讓使用方可以忽略掉其中的細(xì)節(jié),是一種非常好玩的模式了。
但是由于Viewbinding的特殊性,它其實(shí)就會(huì)和當(dāng)前的lifecycle綁定在一起。因?yàn)槲覀円阡N毀的情況下把實(shí)例重置為空。否則當(dāng)我們頁面重新生成的情況下,就會(huì)出現(xiàn)view并不是當(dāng)前的頁面的困擾。
作者在定義的時(shí)候就將Viewbinding委托獲取的實(shí)例定義為了非空,這里我和我的同事其實(shí)是存在一些分歧的,我認(rèn)為非空其實(shí)挺合理的,但是對方并不認(rèn)為。
恰巧這種空非空的問題,在實(shí)際的使用中就出現(xiàn)了很多不可預(yù)期的crash問題。比如說在一個(gè)異步操作中獲取viewbinding實(shí)例然后進(jìn)行賦值操作,就會(huì)出現(xiàn)空指針異常。另外由于使用的是lifecycle的頁面銷毀方法,如果我們復(fù)寫了銷毀方法之后在設(shè)置這個(gè)值,也會(huì)出現(xiàn)崩潰問題。
上述問題我在幾個(gè)我之前參考的庫中其實(shí)都發(fā)現(xiàn)了對應(yīng)的問題。我參考了Binding,還有之前彭旭說的那個(gè)也有類似的情況。
另外在fragment中,其實(shí)問題尤其的明顯。因?yàn)槲覀兒芏鄷r(shí)候使用的fragment相關(guān)的LifecycleOwner是fragment本身,但是Android官方其實(shí)推薦我們使用的是fragment內(nèi)部的view相關(guān)的LifecycleOwner。因?yàn)閒ragment相比較于activity,存在的問題就是多了幾個(gè)生命周期,比如createView,和onDestroyView。其中出現(xiàn)最多問題的也就是onDestroyView和onDestroy。
有趣的代碼
接下來我們看下這個(gè)作者是如何解決這些奇奇怪怪的問題的哦。
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。這個(gè)就其實(shí)已經(jīng)非常精彩了。
另外我們可以看下他在內(nèi)部定義了ClearOnDestroy這個(gè)類,然后當(dāng)onFragmentDestroyed觸發(fā)的時(shí)候調(diào)用postClear方法。而這個(gè)方法就是解決當(dāng)我們在Destroyed中還執(zhí)行了ViewBinding內(nèi)的對象的操作的空指針問題。
經(jīng)典面試題的真實(shí)使用場景,Handler.post執(zhí)行。很多人覺得Handler相關(guān)的面試題都是八股文,這次我們就通過這個(gè)真是場景來給大家說說這個(gè)有意思的問題。
首先從onFragmentDestroyed方法會(huì)執(zhí)行在Fragment本身的onDestroyView之前,原來我們會(huì)在這個(gè)方法下執(zhí)行引用清空的操作。然后當(dāng)onDestroyView執(zhí)行的時(shí)候就會(huì)出現(xiàn)空指針異常了。那么Lifecycle有沒有提供一個(gè)在onDestroyView之后的方法呢?我們是不是可以考慮自己造一個(gè)呢?面試中,我們知道所有生命周期方法都是有主線程Handler來負(fù)責(zé)調(diào)度的,這也就是說活我么可以把生命周期方法認(rèn)為就是一個(gè)Message,當(dāng)onFragmentDestroyed執(zhí)行的時(shí)候,onDestroyView也已經(jīng)被添加到主線程的MessageQueue中,這個(gè)時(shí)候我們在post一個(gè)runnable,那么他的排序規(guī)則上來說,就必然在onDestroyView之后了。
另外一些有意思的地方
這個(gè)庫另外一個(gè)優(yōu)點(diǎn)就是他同時(shí)支持反射和非反射的寫法。同時(shí)也支持了Activity,F(xiàn)ragment,View,F(xiàn)ragmentDialog,ViewHolder等等。反射寫法是基于非反射寫法的,所以也保證了底層庫的一致性。
//非反射寫法 private val viewBinding by viewBinding(ViewProfileBinding::bind) //反射寫法 private val viewBinding: ItemProfileBinding by viewBinding()
同時(shí)他的反射相關(guān)的混淆配置文件也非常有意思。
allowoptimization 指定對象可能會(huì)被優(yōu)化,即使他們被keep選項(xiàng)保留。所指定對象可能會(huì)被改變(優(yōu)化步驟),但可能不會(huì)被混淆或者刪除。該修飾符只對實(shí)現(xiàn)異常要求有用。
-keep,allowoptimization class * implements androidx.viewbinding.ViewBinding { public static *** bind(android.view.View); public static *** inflate(...); }
它只會(huì)keep實(shí)現(xiàn)了ViewBinding的類的bind和inflate方法。因?yàn)閂iewBinding會(huì)將所有的xml轉(zhuǎn)化成一個(gè)類實(shí)例,如果不刪除掉沒有實(shí)際被調(diào)用的類的情況下就會(huì)導(dǎo)致dex包變大,大家對于包體積優(yōu)化都是有追求的嗎。然后用了-keep,allowoptimization,這樣在混淆的代碼優(yōu)化過程中就可以刪除掉沒有被調(diào)用的ViewBinding類了。
結(jié)尾
本次內(nèi)卷到此結(jié)束。但是又是一個(gè)老生常談的話題,一個(gè)開源庫還是要持續(xù)的進(jìn)行迭代和解決問題才能持續(xù)變好,而不是一次性的工作。擁抱變化的代碼世界,解決一些奇奇怪怪的問題,都是挺好玩的,更多關(guān)于Android開發(fā)Viewbinding委托的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Android編程實(shí)現(xiàn)ListView內(nèi)容無限循環(huán)顯示的方法
這篇文章主要介紹了Android編程實(shí)現(xiàn)ListView內(nèi)容無限循環(huán)顯示的方法,通過繼承Adapter類實(shí)現(xiàn)ListView中的數(shù)據(jù)無限循環(huán)顯示功能,需要的朋友可以參考下2017-06-06Android 使用mediaplayer播放res/raw文件夾中的音樂的實(shí)例
這篇文章主要介紹了Android 使用mediaplayer播放res/raw文件夾中的音樂的實(shí)例的相關(guān)資料,需要的朋友可以參考下2017-04-04Android Button點(diǎn)擊事件的四種實(shí)現(xiàn)方法
這篇文章主要為大家詳細(xì)介紹了Android Button點(diǎn)擊事件的四種實(shí)現(xiàn)方法,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-07-07Android中l(wèi)istview嵌套scrollveiw沖突的解決方法
這篇文章主要為大家詳細(xì)介紹了Android中l(wèi)istview嵌套scrollveiw沖突的解決方法,具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-01-01基于Android實(shí)現(xiàn)一個(gè)常用的布局吸頂效果
這篇文章給大家介紹一個(gè)布局吸頂效果,一般出現(xiàn)在內(nèi)容較長頁面還嵌套著分類頁面的情況,比如電商的詳情頁嵌套分類,在頁面滑動(dòng)到tab的時(shí)候我們希望tab還能保留在頁面頂部而不被頂上去,文中有詳細(xì)的代碼示例,需要的朋友可以參考下2023-09-09