一、前言

為了解決Android-App開發(fā)以來一直存在的架構(gòu)設(shè)計(jì)混亂的問題，谷歌推出了Jetpack-MVVM的全家桶解決方案。作為整個(gè)解決方案的核心-LiveData，以其生命周期安全，內(nèi)存安全等優(yōu)點(diǎn)，甚至有逐步取代EventBus，RxJava作為Android端狀態(tài)分發(fā)組件的趨勢(shì)。

官網(wǎng)商城app團(tuán)隊(duì)在深度使用LiveData的過程中，也遇到了一些困難，尤其是在LiveData的觀察者使用上踩到了不少坑，我們把這些經(jīng)驗(yàn)在這里做一次總結(jié)與分享。

二、Observer到底可以接收多少次回調(diào)

2.1 為什么最多收到2個(gè)通知

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

我們首先定義一個(gè)極簡的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);}});}} }

大家可以想一下，這段程序運(yùn)行的結(jié)果會(huì)是多少？我們創(chuàng)建了一個(gè)Livedata，然后對(duì)這個(gè)Livedata Observe了10次，每次都是new出不同的Observer對(duì)象，看上去我們對(duì)一個(gè)數(shù)據(jù)源做了10個(gè)觀察者的綁定。當(dāng)我們修改這個(gè)數(shù)據(jù)源的時(shí)候，我們理應(yīng)有10條通知。運(yùn)行一下看看執(zhí)行結(jié)果：

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

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

我們?cè)贚og的代碼里增加一部分內(nèi)容比如打印下hashCode再看下執(zhí)行結(jié)果：

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

這次結(jié)果就正常了,其實(shí)對(duì)于很多消息總線的調(diào)試都有類似的問題。

實(shí)際上對(duì)于Log系統(tǒng)來說，如果他判定時(shí)間戳一致的情況下，后面的Log內(nèi)容也一致，那么他就不會(huì)重復(fù)打印內(nèi)容了。這里一定要注意這個(gè)細(xì)節(jié)，否則在很多時(shí)候，會(huì)影響我們對(duì)問題的判斷。再回到我們之前沒有添加hashCode的代碼，再仔細(xì)看看也就明白了：只是Log打印了兩條而已，但是通知是收到了10次的，為啥打印兩條？因?yàn)槟愕臅r(shí)間戳一致，后續(xù)的內(nèi)容也一致。

2.2 奇怪的編譯優(yōu)化

事情到這還沒結(jié)束，看下圖：

上述的代碼跑在android studio里面會(huì)變灰，相信很多有代碼潔癖的人一看就知道為啥，這不就是Java8的lambda嘛，ide自動(dòng)給提示給我們讓我們優(yōu)化一下寫法唄，而且鼠標(biāo)一點(diǎn)就自動(dòng)優(yōu)化了，賊方便。

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

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

奇怪，為啥這次只有一個(gè)日志了？難道還是Log日志系統(tǒng)的原因？那我加個(gè)時(shí)間戳試試：

再看下執(zhí)行結(jié)果：

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

奇怪，為什么還是只打印了一條log？我這里for循環(huán)add了10次觀察者呀。難道是lambda導(dǎo)致的問題？嗯，我們可以把Observer的數(shù)量打出來看看，看看到底是哪里出了問題。看下源碼，如下圖所示：我們的觀察者實(shí)際上都是存在這個(gè)map里面的，我們?nèi)〕鰜磉@個(gè)map的size就可以知道原因了。

反射取一下這個(gè)size，注意我們平常使用的LiveData是MutableLiveData，而這個(gè)值是在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());}

再看下執(zhí)行結(jié)果：

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循環(huán)添加了10個(gè)觀察者啊，為啥一改成lambda的寫法，我的觀察者就變成1個(gè)了？遇事不決我們反編譯(用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));} }

已經(jīng)很清晰的看出來，這里因?yàn)槭褂昧薐ava8 lambda的寫法，所以編譯器在編譯的過程中自作聰明了一下，自動(dòng)幫我們優(yōu)化成都是添加的同一個(gè)靜態(tài)的觀察者，并不是10個(gè)，這就解釋了為什么會(huì)出現(xiàn)map size為1的情況了。我們可以再把lambda的寫法刪除掉，再看看反編譯的結(jié)果就正常了。

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

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的寫法是不一樣的，看下這種寫法反編譯的結(jié)果；

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關(guān)鍵字就放心了，這種寫法就可以繞過Java8 lambda編譯的優(yōu)化了。

1.3 Kotlin的lambda寫法會(huì)有坑嗎

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

看下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}

再看下反編譯的結(jié)果：

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的編譯是一樣激進(jìn)的，都是在for循環(huán)的基礎(chǔ)上 默認(rèn)幫你優(yōu)化成一個(gè)對(duì)象了。同樣的，我們也看看讓這個(gè)lambda訪問外部的變量，看看還有沒有這個(gè)“負(fù)優(yōu)化”了。

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 }

看下反編譯的結(jié)果：

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);}

一切正常了。最后我們?cè)倏纯?普通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 }

看下反編譯的結(jié)果：

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); }

一切正常，到這里我們就可以下一個(gè)結(jié)論了。

對(duì)于for循環(huán)中間使用lambda的場景，當(dāng)你的lambda中沒有使用外部的變量或者函數(shù)的時(shí)候，那么不管是Java8的編譯器還是Kotlin的編譯器都會(huì)默認(rèn)幫你優(yōu)化成使用同一個(gè)lambda。

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

二、LiveData為何會(huì)收到Observe之前的消息

2.1 分析源碼找原因

我們來看一個(gè)例子：

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()}

這段代碼的意思是我先更新了一個(gè)livedata的值為3，然后3s之后我livedata 注冊(cè)了一個(gè)觀察者。這里要注意了，我是先更新的livedata的值，過了一段時(shí)間以后才注冊(cè)的觀察者，那么此時(shí)，理論上我應(yīng)該是收不到livedata消息的。因?yàn)槟闶窍劝l(fā)的消息，我后面才觀察的，但程序的執(zhí)行結(jié)果卻是：

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

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

每次observe的時(shí)候我們會(huì)創(chuàng)建一個(gè)wrapper，看下這個(gè)wrapper是干啥的。

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

最終流程會(huì)走到這個(gè)dispatchEvent方法里，繼續(xù)跟。

這個(gè)mLifeCycleObserver其實(shí)就是我們一開始o(jì)bserve那個(gè)方法里new出來的LifecycleBoundObserver對(duì)象了，也就是那個(gè)wrapper的變量。這個(gè)onStateChanged方法經(jīng)過一系列的調(diào)用最終會(huì)走到如下圖所示的considerNotify方法。

而整個(gè)considerNotify方法的作用只有一個(gè)。

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

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

可以看出來這個(gè)值默認(rèn)值就是start_version也就是-1。但是每次setValue的時(shí)候這個(gè)值都會(huì)加1。

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

最后總結(jié)一下：

• Livedata的mVersion初始值是-1。

• 經(jīng)過一次setValue以后她的值就變成了0。

• 后續(xù)每次observe的時(shí)候會(huì)創(chuàng)建一個(gè)ObserverWrapper。

• Wrapper她里面有一個(gè)mLastVersion 這個(gè)值是-1，observe的函數(shù)調(diào)用最終會(huì)經(jīng)過一系列的流程走到considerNotify方法中此時(shí) LiveData的mVersion是0。

• 0顯然是大于observer的mLastVersion-1的，所以此時(shí)就一定會(huì)觸發(fā)observer的監(jiān)聽函數(shù)了。

2.2 配合ActivityViewModels要小心

Livedata的這種特性，在某些場景下會(huì)引發(fā)災(zāi)難性的后果，比如說，單Activity多Fragment的場景下，在沒有Jetpack-mvvm組件之前，要讓Activity-Fragment 實(shí)現(xiàn)數(shù)據(jù)同步是很不方便的 ，但是有了Jetpack-mvvm組件之后，要實(shí)現(xiàn)這套機(jī)制會(huì)變的非常容易。可以看下官網(wǎng)上的例子：

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個(gè)fragment之間共享這套 ActivityViewModel 即可。使用起來很方便，但是某些場景下卻會(huì)導(dǎo)致一些嚴(yán)重問題。來看這個(gè)場景，我們有一個(gè)activity默認(rèn)顯ListFragment，點(diǎn)擊了ListFragment以后我們會(huì)跳轉(zhuǎn)到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()}}} }

可以看出來我們的實(shí)現(xiàn)機(jī)制就是點(diǎn)擊了按鈕以后我們調(diào)用viewModel的userClicksOnButton方法將navigateToDetails這個(gè)livedata的值改成true，然后監(jiān)聽這個(gè)LiveData值，如果是true的話就跳轉(zhuǎn)到Detail 這個(gè)詳情的fragment。

這個(gè)流程初看是沒問題的，點(diǎn)擊以后確實(shí)能跳轉(zhuǎn)到DetailFragment，但是當(dāng)我們?cè)贒etailFragment頁面點(diǎn)擊了返回鍵以后，理論上會(huì)回到ListFragment，但實(shí)際的執(zhí)行結(jié)果是回到ListFragment以后馬上又跳到DetailFragment了。

這是為啥？問題其實(shí)就出現(xiàn)在Fragment生命周期這里，當(dāng)你按了返回鍵以后，ListFragment的onViewCreated又一次會(huì)被執(zhí)行，然后這次你observe了，Livedata之前的值是true，于是又會(huì)觸發(fā)跳轉(zhuǎn)到DetailFragment的流程。導(dǎo)致你的頁面再也回不到列表頁了。

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

俗話說的好，計(jì)算機(jī)領(lǐng)域中的所有問題都可以通過引入一個(gè)中間層來解決。這里也一樣，我們可以嘗試“一個(gè)消息只被消費(fèi)一次”的思路來解決上述的問題。例如我們將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 // 只允許外部讀 不允許外部寫這個(gè)值/*** 通過這個(gè)函數(shù)取的value 只能被消費(fèi)一次*/fun getContentIfNotHandled(): T? {return if (hasBeenHandled) {null} else {hasBeenHandled = truecontent}}/*** 如果想消費(fèi)之前的value 那就直接調(diào)用這個(gè)方法即可*/fun peekContent(): T = content }

這樣我們?cè)谧霰O(jiān)聽的時(shí)候只要調(diào)用getContentIfNotHandled()這個(gè)方法即可:

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的時(shí)候，mLastVersion的值小于 mVersion的值 是問題產(chǎn)生的根源，那我們利用反射，每次observer的時(shí)候?qū)LastVersion的值設(shè)置成與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 對(duì)象val objectObservers = mObserversFiled.get(this)// 取 mObservers 對(duì)象 所屬的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大會(huì)中，Yigit 在Jetpack的 AMA 中明確指出了 Livedata的存在就是為了照顧Java的使用者，短期內(nèi)會(huì)繼續(xù)維護(hù)（含義是什么大家自己品品），作為Livedata的替代品Flow會(huì)在今后漸漸成為主流(畢竟現(xiàn)在Kotlin漸漸成為主流)，那如果使用了Flow，上述的情況則可以迎刃而解。

改寫viewModel

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

然后改寫下監(jiān)聽的方式即可；

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")}}}}}

我們重點(diǎn)看SharedFlow這個(gè)熱流的構(gòu)造函數(shù)；

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

三、總結(jié)

整體上來說，即使現(xiàn)在有了Kotlin Flow，LiveData也依舊是目前Android客戶端架構(gòu)組件中不可缺少的一環(huán)，畢竟它的生命周期安全和內(nèi)存安全實(shí)在是太香，可以有效降低我們平常業(yè)務(wù)開發(fā)中的負(fù)擔(dān)，在使用他的時(shí)候我們只要關(guān)注3個(gè)方面即可避坑：

• 謹(jǐn)慎使用Android Studio給出的lambda智能提示

• 多關(guān)注是否真的需要Observe 在注冊(cè)監(jiān)聽之前的消息

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

作者：vivo互聯(lián)網(wǎng)前端團(tuán)隊(duì)-Wu Yue

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。