Jetpack—LiveData元件的缺陷以及應對策略 轉至後設資料結尾

vivo網際網路技術發表於2022-01-18
JetpackLiveData元件

一、前言

為了解決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";
 
    @Override
    protected 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>() {
                @Override
                public 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的數量打出來看看，看看到底是哪裡出了問題。看下原始碼，如下圖所示：我們的觀察者實際上都是存在這個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 = 3
        Thread{
            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: Selector
 
   
    private 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() = _navigateToDetails
 
    fun 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 fragment
        return 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() = _navigateToDetails
 
 
    fun userClicksOnButton() {
        _navigateToDetails.value = Event(true)
    }
}
 
 
open class Event<out T>(private val content: T) {
 
    var hasBeenHandled = false
        private set // 只允許外部讀 不允許外部寫這個值
 
    /**
     * 通過這個函式取的value 只能被消費一次
     */
    fun getContentIfNotHandled(): T? {
        return if (hasBeenHandled) {
            null
        } else {
            hasBeenHandled = true
            content
        }
    }
 
    /**
     * 如果想消費之前的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 version
        val livedataVersion = javaClass.superclass.superclass.getDeclaredField("mVersion")
        livedataVersion.isAccessible = true
        // 獲取livedata version的值
        val livedataVerionValue = livedataVersion.get(this)
        // 取 mObservers Filed
        val mObserversFiled = javaClass.superclass.superclass.getDeclaredField("mObservers")
        mObserversFiled.isAccessible = true
        // 取 mObservers 物件
        val objectObservers = mObserversFiled.get(this)
        // 取 mObservers 物件 所屬的class SafeIterableMap
        val objectObserversClass = objectObservers.javaClass
        val methodGet = objectObserversClass.getDeclaredMethod("get", Any::class.java)
        methodGet.isAccessible = true
        //LifecycleBoundObserver
        val objectWrapper = (methodGet.invoke(objectObservers, observer) as Map.Entry<*, *>).value
        //ObserverWrapper
        val 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

相關文章