Android開發(fā)Viewbinding委托實例詳解
背景
前一陣子我們在使用viewbinding的委托的時候碰到了點crash問題,然后發(fā)現(xiàn)了一個比較有意思的解決方案,就和大家展開聊聊。
另外一點就是我后面打算將kotlin extensions這個插件統(tǒng)一移除掉。
估計大家應該對Viewbinding的委托應該都有一定的了解,好幾個大佬分享過類似的文章,但是大佬們的代碼貌似也有一陣子都沒有維護了,所以我找到了一個外國大佬寫的倉庫,其實應該算是一個相對來說比較穩(wěn)定的庫了,而且也一直處于一個持續(xù)更新迭代的狀態(tài)。
倉庫地址 ViewBindingPropertyDelegate
從Crash到有意思的源碼
委托模式是軟件設計模式中的一項基本技巧。在委托模式中,有兩個對象參與處理同一個請求,接受請求的對象將請求委托給另一個對象來處理。
Kotlin 直接支持委托模式,更加優(yōu)雅,簡潔。Kotlin 通過關鍵字 by 實現(xiàn)委托。
上述是kotlin對于委托的釋義,Viewbinding委托就是把生成Viewbinding實例的過程交給委托類去完成,然后讓使用方可以忽略掉其中的細節(jié),是一種非常好玩的模式了。
但是由于Viewbinding的特殊性,它其實就會和當前的lifecycle綁定在一起。因為我們要在銷毀的情況下把實例重置為空。否則當我們頁面重新生成的情況下,就會出現(xiàn)view并不是當前的頁面的困擾。
作者在定義的時候就將Viewbinding委托獲取的實例定義為了非空,這里我和我的同事其實是存在一些分歧的,我認為非空其實挺合理的,但是對方并不認為。
恰巧這種空非空的問題,在實際的使用中就出現(xiàn)了很多不可預期的crash問題。比如說在一個異步操作中獲取viewbinding實例然后進行賦值操作,就會出現(xiàn)空指針異常。另外由于使用的是lifecycle的頁面銷毀方法,如果我們復寫了銷毀方法之后在設置這個值,也會出現(xiàn)崩潰問題。
上述問題我在幾個我之前參考的庫中其實都發(fā)現(xiàn)了對應的問題。我參考了Binding,還有之前彭旭說的那個也有類似的情況。
另外在fragment中,其實問題尤其的明顯。因為我們很多時候使用的fragment相關的LifecycleOwner是fragment本身,但是Android官方其實推薦我們使用的是fragment內部的view相關的LifecycleOwner。因為fragment相比較于activity,存在的問題就是多了幾個生命周期,比如createView,和onDestroyView。其中出現(xiàn)最多問題的也就是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觸發(fā)的時候調用postClear方法。而這個方法就是解決當我們在Destroyed中還執(zhí)行了ViewBinding內的對象的操作的空指針問題。
經典面試題的真實使用場景,Handler.post執(zhí)行。很多人覺得Handler相關的面試題都是八股文,這次我們就通過這個真是場景來給大家說說這個有意思的問題。
首先從onFragmentDestroyed方法會執(zhí)行在Fragment本身的onDestroyView之前,原來我們會在這個方法下執(zhí)行引用清空的操作。然后當onDestroyView執(zhí)行的時候就會出現(xiàn)空指針異常了。那么Lifecycle有沒有提供一個在onDestroyView之后的方法呢?我們是不是可以考慮自己造一個呢?面試中,我們知道所有生命周期方法都是有主線程Handler來負責調度的,這也就是說活我么可以把生命周期方法認為就是一個Message,當onFragmentDestroyed執(zhí)行的時候,onDestroyView也已經被添加到主線程的MessageQueue中,這個時候我們在post一個runnable,那么他的排序規(guī)則上來說,就必然在onDestroyView之后了。
另外一些有意思的地方
這個庫另外一個優(yōu)點就是他同時支持反射和非反射的寫法。同時也支持了Activity,F(xiàn)ragment,View,F(xiàn)ragmentDialog,ViewHolder等等。反射寫法是基于非反射寫法的,所以也保證了底層庫的一致性。
//非反射寫法
private val viewBinding by viewBinding(ViewProfileBinding::bind)
//反射寫法
private val viewBinding: ItemProfileBinding by viewBinding()
同時他的反射相關的混淆配置文件也非常有意思。
allowoptimization 指定對象可能會被優(yōu)化,即使他們被keep選項保留。所指定對象可能會被改變(優(yōu)化步驟),但可能不會被混淆或者刪除。該修飾符只對實現(xiàn)異常要求有用。
-keep,allowoptimization class * implements androidx.viewbinding.ViewBinding {
public static *** bind(android.view.View);
public static *** inflate(...);
}
它只會keep實現(xiàn)了ViewBinding的類的bind和inflate方法。因為ViewBinding會將所有的xml轉化成一個類實例,如果不刪除掉沒有實際被調用的類的情況下就會導致dex包變大,大家對于包體積優(yōu)化都是有追求的嗎。然后用了-keep,allowoptimization,這樣在混淆的代碼優(yōu)化過程中就可以刪除掉沒有被調用的ViewBinding類了。
結尾
本次內卷到此結束。但是又是一個老生常談的話題,一個開源庫還是要持續(xù)的進行迭代和解決問題才能持續(xù)變好,而不是一次性的工作。擁抱變化的代碼世界,解決一些奇奇怪怪的問題,都是挺好玩的,更多關于Android開發(fā)Viewbinding委托的資料請關注腳本之家其它相關文章!
相關文章
android 如何設置開機后屏幕亮度默認值為自動調節(jié)
在第一次開機后,設置>顯示>自動亮度調節(jié) 默認是勾選上的,具體修改方法如下,感興趣的朋友可以嘗試操作下2013-06-06
Android開發(fā)中Listview動態(tài)加載數(shù)據(jù)的方法示例
這篇文章主要介紹了Android開發(fā)中Listview動態(tài)加載數(shù)據(jù)的方法,結合實例形式較為詳細的分析了Android操作ListView界面布局與數(shù)據(jù)動態(tài)更新相關操作技巧,需要的朋友可以參考下2017-10-10
Android開發(fā)中如何解決Fragment +Viewpager滑動頁面重復加載的問題
這篇文章主要介紹了Android開發(fā)中如何解決Fragment +Viewpager滑動頁面重復加載的問題 ,需要的朋友可以參考下2017-07-07
解決Android自定義view獲取attr中自定義顏色的問題
這篇文章主要介紹了Android自定義view獲取attr中自定義顏色的問題解決方法,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-12-12
Android 圖片保存到相冊不顯示的解決方案(兼容Android 10及更高版本)
這篇文章主要介紹了Android 圖片保存到系統(tǒng)相冊不顯示的解決方案,幫助大家更好的理解和學習使用Android開發(fā),感興趣的朋友可以了解下2021-04-04
Android itemDecoration接口實現(xiàn)吸頂懸浮標題
這篇文章主要介紹了Android中使用itemdecoration實現(xiàn)吸頂懸浮標題,本文通過實例代碼給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-11-11

