一、前言

為了解決Android-App開發以來一直存在的架構設計混亂的問題，谷歌推出了Jetpack-MVVM的全家桶解決方案。作為整個解決方案的核心-LiveData，以其生命周期安全，內存安全等優點，甚至有逐步取代EventBus，RxJava作為Android端狀態分發組件的趨勢。

官網商城app團隊在深度使用LiveData的過程中，也遇到了一些困難，尤其是在LiveData的觀察者使用上踩到了不少坑，我們把這些經驗在這里做一次總結與分享。

二、Observer到底可以接收多少次回調

2.1 為什么最多收到2個通知

這是一個典型的案例，在調試消息總線的場景時，我們通常會在消息的接收者那里打印一些log日志方便我們定位問題，然而日志的打印有時候也會給我們的問題定位帶來一定的迷惑性，可以看下面的例子。

我們首先定義一個極簡的ViewModel:

public class TestViewModel extends ViewModel {private MutableLiveData<String> currentName;public MutableLiveData<String> getCurrentName() {if (currentName == null) {currentName = new MutableLiveData<String>();}return currentName;} }

然后看下我們的activity代碼；

public class JavaTestLiveDataActivity extends AppCompatActivity {private TestViewModel model;private String test="12345";@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_java_test_live_data);model = new ViewModelProvider(this).get(TestViewModel.class);test3(); model.getCurrentName().setValue("3");}private void test3() {for (int i = 0; i < 10; i++) {model.getCurrentName().observe(this, new Observer<String>() {@Overridepublic void onChanged(String s) {Log.v("ttt", "s:" + s);}});}} }

大家可以想一下，這段程序運行的結果會是多少？我們創建了一個Livedata，然后對這個Livedata Observe了10次，每次都是new出不同的Observer對象，看上去我們對一個數據源做了10個觀察者的綁定。當我們修改這個數據源的時候，我們理應有10條通知。運行一下看看執行結果：

2021-11-21 15:20:07.662 27500-27500/com.smart.myapplication V/ttt: s:3 2021-11-21 15:20:07.662 27500-27500/com.smart.myapplication V/ttt: s:3

奇怪，為什么我明明注冊了10個觀察者，但是只收到了2個回調通知？換種寫法試試？

我們在Log的代碼里增加一部分內容比如打印下hashCode再看下執行結果：

2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:217112568 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:144514257 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:72557366 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:233087543 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:22021028 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:84260109 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:94780610 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:240593619 2021-11-21 15:22:59.377 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:207336976 2021-11-21 15:22:59.378 27912-27912/com.smart.myapplication V/ttt: s:3 hashCode:82154761

這次結果就正常了,其實對于很多消息總線的調試都有類似的問題。

實際上對于Log系統來說，如果他判定時間戳一致的情況下，后面的Log內容也一致，那么他就不會重復打印內容了。這里一定要注意這個細節，否則在很多時候，會影響我們對問題的判斷。再回到我們之前沒有添加hashCode的代碼，再仔細看看也就明白了：只是Log打印了兩條而已，但是通知是收到了10次的，為啥打印兩條？因為你的時間戳一致，后續的內容也一致。

2.2 奇怪的編譯優化

事情到這還沒結束，看下圖：

上述的代碼跑在android studio里面會變灰，相信很多有代碼潔癖的人一看就知道為啥，這不就是Java8的lambda嘛，ide自動給提示給我們讓我們優化一下寫法唄，而且鼠標一點就自動優化了，賊方便。

灰色沒有了，代碼變的簡潔了，kpi在向我招手了，運行一下試試：

2021-11-21 15:31:50.386 29136-29136/com.smart.myapplication V/ttt: s:3

奇怪，為啥這次只有一個日志了？難道還是Log日志系統的原因？那我加個時間戳試試：

再看下執行結果：

2021-11-21 15:34:33.559 29509-29509/com.smart.myapplication V/ttt: s:3 time:1637480073559

奇怪，為什么還是只打印了一條log？我這里for循環add了10次觀察者呀。難道是lambda導致的問題？嗯，我們可以把Observer的數量打出來看看，看看到底是哪里出了問題?？聪略创a，如下圖所示：我們的觀察者實際上都是存在這個map里面的，我們取出來這個map的size就可以知道原因了。

反射取一下這個size，注意我們平常使用的LiveData是MutableLiveData，而這個值是在LiveData里，所以是getSuperclass()。

private void hook(LiveData liveData) throws Exception {Field map = liveData.getClass().getSuperclass().getDeclaredField("mObservers");map.setAccessible(true);SafeIterableMap safeIterableMap = (SafeIterableMap) map.get(liveData);Log.v("ttt", "safeIterableMap size:" + safeIterableMap.size());}

再看下執行結果：

2021-11-21 15:40:37.010 30043-30043/com.smart.myapplication V/ttt: safeIterableMap size:1 2021-11-21 15:40:37.013 30043-30043/com.smart.myapplication V/ttt: s:3 time:1637480437013

果然這里的map size是1，并不是10，那肯定只能收到1條通知了。那么問題來了，我明明是for循環添加了10個觀察者啊，為啥一改成lambda的寫法，我的觀察者就變成1個了？遇事不決我們反編譯(用jadx直接反編譯我們的debug app)一下看看。

private void test3() {for (int i = 0; i < 10; i++) {this.model.getCurrentName().observe(this, $$Lambda$JavaTestLiveDataActivity$zcrCJYfWItRTy4AC_xWfANwZkzE.INSTANCE);} }public final /* synthetic */ class $$Lambda$JavaTestLiveDataActivity$zcrCJYfWItRTy4AC_xWfANwZkzE implements Observer {public static final /* synthetic */ $$Lambda$JavaTestLiveDataActivity$zcrCJYfWItRTy4AC_xWfANwZkzE INSTANCE = new $$Lambda$JavaTestLiveDataActivity$zcrCJYfWItRTy4AC_xWfANwZkzE();private /* synthetic */ $$Lambda$JavaTestLiveDataActivity$zcrCJYfWItRTy4AC_xWfANwZkzE() {}public final void onChanged(Object obj) {Log.v("ttt", "s:" + ((String) obj));} }

已經很清晰的看出來，這里因為使用了Java8 lambda的寫法，所以編譯器在編譯的過程中自作聰明了一下，自動幫我們優化成都是添加的同一個靜態的觀察者，并不是10個，這就解釋了為什么會出現map size為1的情況了。我們可以再把lambda的寫法刪除掉，再看看反編譯的結果就正常了。

還剩最后一個問題，這個lamda的優化是不分任何場景一直生效的嘛？我們換個寫法試試：

private String outer = "123456";private void test3() {for (int i = 0; i < 10; i++) {model.getCurrentName().observe(this, s -> Log.v("ttt", "s:" + s + outer));} }

注意看，我們這種寫法雖然也是用了lambda，但是我們引入了外部變量，和之前的lambda的寫法是不一樣的，看下這種寫法反編譯的結果；

private void test3() {for (int i = 0; i < 10; i++) {this.model.getCurrentName().observe(this, new Observer() {public final void onChanged(Object obj) {JavaTestLiveDataActivity.this.lambda$test33$0$JavaTestLiveDataActivity((String) obj);}});} }

看到new關鍵字就放心了，這種寫法就可以繞過Java8 lambda編譯的優化了。

1.3 Kotlin的lambda寫法會有坑嗎

考慮到現在大多數人都會使用Kotlin語言，我們也試試看Kotlin的lamda寫法會不會也和Java8的lambda一樣會有這種坑？

看下Kotlin中 lambda的寫法：

fun test2() {val liveData = MutableLiveData<Int>()for (i in 0..9) {liveData.observe(this,{ t -> Log.v("ttt", "t:$t") })}liveData.value = 3}

再看下反編譯的結果：

public final void test2() {MutableLiveData liveData = new MutableLiveData();int i = 0;do {int i2 = i;i++;liveData.observe(this, $$Lambda$KotlinTest$6ZY8yysFE1G_4okj2E0STUBMfmc.INSTANCE);} while (i <= 9);liveData.setValue(3);}public final /* synthetic */ class $$Lambda$KotlinTest$6ZY8yysFE1G_4okj2E0STUBMfmc implements Observer {public static final /* synthetic */ $$Lambda$KotlinTest$6ZY8yysFE1G_4okj2E0STUBMfmc INSTANCE = new $$Lambda$KotlinTest$6ZY8yysFE1G_4okj2E0STUBMfmc();private /* synthetic */ $$Lambda$KotlinTest$6ZY8yysFE1G_4okj2E0STUBMfmc() {}public final void onChanged(Object obj) {KotlinTest.m1490test2$lambda3((Integer) obj);} }

看來Kotlin的lambda編譯和Java8 lambda的編譯是一樣激進的，都是在for循環的基礎上 默認幫你優化成一個對象了。同樣的，我們也看看讓這個lambda訪問外部的變量，看看還有沒有這個“負優化”了。

val test="12345" fun test2() {val liveData = MutableLiveData<Int>()for (i in 0..9) {liveData.observe(this,{ t -> Log.v("ttt", "t:$t $test") })}liveData.value = 3 }

看下反編譯的結果：

public final void test2() {MutableLiveData liveData = new MutableLiveData();int i = 0;do {int i2 = i;i++;liveData.observe(this, new Observer() {public final void onChanged(Object obj) {KotlinTest.m1490test2$lambda3(KotlinTest.this, (Integer) obj);}});} while (i <= 9);liveData.setValue(3);}

一切正常了。最后我們再看看 普通Kotlin的非lambda寫法 是不是和Java的非lambda寫法一樣呢？

fun test1() {val liveData = MutableLiveData<Int>()for (i in 0..9) {liveData.observe(this, object : Observer<Int> {override fun onChanged(t: Int?) {Log.v("ttt", "t:$t")}})}liveData.value = 3 }

看下反編譯的結果：

public final void test11() {MutableLiveData liveData = new MutableLiveData();int i = 0;do {int i2 = i;i++;liveData.observe(this, new KotlinTest$test11$1());} while (i <= 9);liveData.setValue(3); }

一切正常，到這里我們就可以下一個結論了。

對于for循環中間使用lambda的場景，當你的lambda中沒有使用外部的變量或者函數的時候，那么不管是Java8的編譯器還是Kotlin的編譯器都會默認幫你優化成使用同一個lambda。

編譯器的出發點是好的，for循環中new不同的對象，當然會導致一定程度的性能下降(畢竟new出來的東西最后都是要gc的)，但這種優化往往可能不符合我們的預期，甚至有可能在某種場景下造成我們的誤判，所以使用的時候一定要小心。

二、LiveData為何會收到Observe之前的消息

2.1 分析源碼找原因

我們來看一個例子：

fun test1() {val liveData = MutableLiveData<Int>()Log.v("ttt","set live data value")liveData.value = 3Thread{Log.v("ttt","wait start")Thread.sleep(3000)runOnUiThread {Log.v("ttt","wait end start observe")liveData.observe(this,{ t -> Log.v("ttt", "t:$t") })}}.start()}

這段代碼的意思是我先更新了一個livedata的值為3，然后3s之后我livedata 注冊了一個觀察者。這里要注意了，我是先更新的livedata的值，過了一段時間以后才注冊的觀察者，那么此時，理論上我應該是收不到livedata消息的。因為你是先發的消息，我后面才觀察的，但程序的執行結果卻是：

2021-11-21 16:27:22.306 32275-32275/com.smart.myapplication V/ttt: set live data value 2021-11-21 16:27:22.306 32275-32388/com.smart.myapplication V/ttt: wait start 2021-11-21 16:27:25.311 32275-32275/com.smart.myapplication V/ttt: wait end start observe 2021-11-21 16:27:25.313 32275-32275/com.smart.myapplication V/ttt: t:3

這個就很詭異了，而且不符合一個我們常見的消息總線框架的設計。來看看源碼到底是咋回事？

每次observe的時候我們會創建一個wrapper，看下這個wrapper是干啥的。

注意這個wrapper有一個onStateChanged方法，這是整個事件分發的核心，我們暫且記住這個入口，再回到我們之前的observe方法，最后一行是調用了addObserver方法，我們看看這個方法里做了啥。

最終流程會走到這個dispatchEvent方法里，繼續跟。

這個mLifeCycleObserver其實就是我們一開始observe那個方法里new出來的LifecycleBoundObserver對象了，也就是那個wrapper的變量。這個onStateChanged方法經過一系列的調用最終會走到如下圖所示的considerNotify方法。

而整個considerNotify方法的作用只有一個。

就是判斷mLastVersion和mVersion的值，如果mLastVersion的值<mversion的值，那么就會觸發observer的onchaged方法了，也就是會回調到我們的觀察者方法里面<strong="">。

我們來看看這2個值咋變化的。首先看這個mVersion；

可以看出來這個值默認值就是start_version也就是-1。但是每次setValue的時候這個值都會加1。

而我們observer里面的mLastVersion 它的初始值就是-1。

最后總結一下：

• Livedata的mVersion初始值是-1。

• 經過一次setValue以后她的值就變成了0。

• 后續每次observe的時候會創建一個ObserverWrapper。

• Wrapper她里面有一個mLastVersion 這個值是-1，observe的函數調用最終會經過一系列的流程走到considerNotify方法中此時 LiveData的mVersion是0。

• 0顯然是大于observer的mLastVersion-1的，所以此時就一定會觸發observer的監聽函數了。

2.2 配合ActivityViewModels要小心

Livedata的這種特性，在某些場景下會引發災難性的后果，比如說，單Activity多Fragment的場景下，在沒有Jetpack-mvvm組件之前，要讓Activity-Fragment 實現數據同步是很不方便的 ，但是有了Jetpack-mvvm組件之后，要實現這套機制會變的非常容易。可以看下官網上的例子：

class SharedViewModel : ViewModel() {val selected = MutableLiveData<Item>()fun select(item: Item) {selected.value = item} }class MasterFragment : Fragment() {private lateinit var itemSelector: Selectorprivate val model: SharedViewModel by activityViewModels()override fun onViewCreated(view: View, savedInstanceState: Bundle?) {super.onViewCreated(view, savedInstanceState)itemSelector.setOnClickListener { item ->// Update the UI}} }class DetailFragment : Fragment() {private val model: SharedViewModel by activityViewModels()override fun onViewCreated(view: View, savedInstanceState: Bundle?) {super.onViewCreated(view, savedInstanceState)model.selected.observe(viewLifecycleOwner, Observer<Item> { item ->// Update the UI})} }

只要讓2個fragment之間共享這套 ActivityViewModel 即可。使用起來很方便，但是某些場景下卻會導致一些嚴重問題。來看這個場景，我們有一個activity默認顯ListFragment，點擊了ListFragment以后我們會跳轉到DetailFragment，來看下代碼：

class ListViewModel : ViewModel() {private val _navigateToDetails = MutableLiveData<Boolean>()val navigateToDetails : LiveData<Boolean>get() = _navigateToDetailsfun userClicksOnButton() {_navigateToDetails.value = true} }

再看下核心的ListFragment；

class ListFragment : Fragment() {private val model: ListViewModel by activityViewModels()override fun onCreate(savedInstanceState: Bundle?) {super.onCreate(savedInstanceState)}override fun onViewCreated(view: View, savedInstanceState: Bundle?) {super.onViewCreated(view, savedInstanceState)model.navigateToDetails.observe(viewLifecycleOwner, { t ->if (t) {parentFragmentManager.commit {replace<DetailFragment>(R.id.fragment_container_view)addToBackStack("name")}}})}override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?,savedInstanceState: Bundle?): View? {// Inflate the layout for this fragmentreturn inflater.inflate(R.layout.fragment_list, container, false).apply {findViewById<View>(R.id.to_detail).setOnClickListener {model.userClicksOnButton()}}} }

可以看出來我們的實現機制就是點擊了按鈕以后我們調用viewModel的userClicksOnButton方法將navigateToDetails這個livedata的值改成true，然后監聽這個LiveData值，如果是true的話就跳轉到Detail 這個詳情的fragment。

這個流程初看是沒問題的，點擊以后確實能跳轉到DetailFragment，但是當我們在DetailFragment頁面點擊了返回鍵以后，理論上會回到ListFragment，但實際的執行結果是回到ListFragment以后馬上又跳到DetailFragment了。

這是為啥？問題其實就出現在Fragment生命周期這里，當你按了返回鍵以后，ListFragment的onViewCreated又一次會被執行，然后這次你observe了，Livedata之前的值是true，于是又會觸發跳轉到DetailFragment的流程。導致你的頁面再也回不到列表頁了。

2.3 解決方案一：引入中間層

俗話說的好，計算機領域中的所有問題都可以通過引入一個中間層來解決。這里也一樣，我們可以嘗試“一個消息只被消費一次”的思路來解決上述的問題。例如我們將LiveData的值包一層：

class ListViewModel : ViewModel() {private val _navigateToDetails = MutableLiveData<Event<Boolean>>()val navigateToDetails : LiveData<Event<Boolean>>get() = _navigateToDetailsfun userClicksOnButton() {_navigateToDetails.value = Event(true)} }open class Event<out T>(private val content: T) {var hasBeenHandled = falseprivate set // 只允許外部讀 不允許外部寫這個值/*** 通過這個函數取的value 只能被消費一次*/fun getContentIfNotHandled(): T? {return if (hasBeenHandled) {null} else {hasBeenHandled = truecontent}}/*** 如果想消費之前的value 那就直接調用這個方法即可*/fun peekContent(): T = content }

這樣我們在做監聽的時候只要調用getContentIfNotHandled()這個方法即可:

model.navigateToDetails.observe(viewLifecycleOwner, { t ->t.getContentIfNotHandled()?.let {if (it){parentFragmentManager.commit {replace<DetailFragment>(R.id.fragment_container_view)addToBackStack("name")}}}})

2.4 解決方案二：Hook LiveData的observe方法

前文我們分析過，每次observe的時候，mLastVersion的值小于 mVersion的值 是問題產生的根源，那我們利用反射，每次observer的時候將mLastVersion的值設置成與version相等不就行了么。

class SmartLiveData<T> : MutableLiveData<T>() {override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {super.observe(owner, observer)//get livedata versionval livedataVersion = javaClass.superclass.superclass.getDeclaredField("mVersion")livedataVersion.isAccessible = true// 獲取livedata version的值val livedataVerionValue = livedataVersion.get(this)// 取 mObservers Filedval mObserversFiled = javaClass.superclass.superclass.getDeclaredField("mObservers")mObserversFiled.isAccessible = true// 取 mObservers 對象val objectObservers = mObserversFiled.get(this)// 取 mObservers 對象 所屬的class SafeIterableMapval objectObserversClass = objectObservers.javaClassval methodGet = objectObserversClass.getDeclaredMethod("get", Any::class.java)methodGet.isAccessible = true//LifecycleBoundObserverval objectWrapper = (methodGet.invoke(objectObservers, observer) as Map.Entry<*, *>).value//ObserverWrapperval mLastVersionField = objectWrapper!!.javaClass.superclass.getDeclaredField("mLastVersion")mLastVersionField.isAccessible = true//將 mVersion的值 賦值給 mLastVersion 使其相等mLastVersionField.set(objectWrapper, livedataVerionValue)} }

2.5 解決方案三：使用Kotlin-Flow

如果你還在使用Kotlin，那么此問題的解決方案則更加簡單，甚至連過程都變的可控。在今年的谷歌I/O大會中，Yigit 在Jetpack的 AMA 中明確指出了 Livedata的存在就是為了照顧Java的使用者，短期內會繼續維護（含義是什么大家自己品品），作為Livedata的替代品Flow會在今后漸漸成為主流(畢竟現在Kotlin漸漸成為主流)，那如果使用了Flow，上述的情況則可以迎刃而解。

改寫viewModel

class ListViewModel : ViewModel() {val _navigateToDetails = MutableSharedFlow<Boolean>()fun userClicksOnButton() {viewModelScope.launch {_navigateToDetails.emit(true)}} }

然后改寫下監聽的方式即可；

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {super.onViewCreated(view, savedInstanceState)lifecycleScope.launch {model._navigateToDetails.collect {if (it) {parentFragmentManager.commit {replace<DetailFragment>(R.id.fragment_container_view)addToBackStack("name")}}}}}

我們重點看SharedFlow這個熱流的構造函數；

他的實際作用就是：當有新的訂閱者collect的時候（可以理解為collect就是Livedata中的observe），發送幾個(replay)collect之前已經發送過的數據給它,默認值是0。所以我們上述的代碼是不會收到之前的消息的。大家在這里可以試一下 把這個replay改成1，即可復現之前Livedata的問題。相比于前面兩種解決方案，這個方案更加優秀，唯一的缺點就是Flow不支持Java，僅支持Kotlin。

三、總結

整體上來說，即使現在有了Kotlin Flow，LiveData也依舊是目前Android客戶端架構組件中不可缺少的一環，畢竟它的生命周期安全和內存安全實在是太香，可以有效降低我們平常業務開發中的負擔，在使用他的時候我們只要關注3個方面即可避坑：

• 謹慎使用Android Studio給出的lambda智能提示

• 多關注是否真的需要Observe 在注冊監聽之前的消息

• Activity與Fragment之間使用ActivityViewModel時要小心處理。

作者：vivo互聯網前端團隊-Wu Yue

總結

以上是生活随笔為你收集整理的Jetpack—LiveData组件的缺陷以及应对策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。