LiveData

LiveData是一個用於持有資料並支援資料可被監聽（觀察）。和傳統的觀察者模式中的被觀察者不一樣，LiveData是一個生命週期感知元件，因此觀察者可以指定某一個LifeCycle給LiveData，並對資料進行監聽。

如果觀察者指定LifeCycle處於Started或者RESUMED狀態，LiveData會將觀察者視為活動狀態，並通知其資料的變化。

我們看一段程式碼：

public class LocationLiveData extends LiveData<Location> {
    private LocationManager locationManager;

    private SimpleLocationListener listener = new SimpleLocationListener() {
        @Override
        public void onLocationChanged(Location location) {
            setValue(location);
        }
    };

    public LocationLiveData(Context context) {
        locationManager = (LocationManager) context.getSystemService(
                Context.LOCATION_SERVICE);
    }

    @Override
    protected void onActive() {
        locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener);
    }

    @Override
    protected void onInactive() {
        locationManager.removeUpdates(listener);
    }
}
 

上面有三個值得注意的地方：

• onActive()

當這個方法被呼叫時，表示LiveData的觀察者數量從0變為了1，這時就我們的位置監聽來說，就應該註冊我們的時間監聽了。

• onInactive()

這個方法被呼叫時，表示LiveData的觀察者數量變為了0，既然沒有了觀察者，也就沒有理由再做監聽，此時我們就應該將位置監聽移除。

• setValue()

通過呼叫這個方法來更新LiveData的資料，並通知處於活動狀態的觀察者。

接著我們就能像下面這樣使用LocationLiveData了。

public class MyFragment extends LifecycleFragment {
    public void onActivityCreated (Bundle savedInstanceState) {
        LiveData<Location> myLocationListener = ...;
        Util.checkUserStatus(result -> {
            if (result) {
                myLocationListener.addObserver(this, location -> {
                    // update UI
                });
            }
        });
    }
}
 

注意上面的addObserver方法，我們將LifeCycleOwner作為第一個引數傳遞了進去，這表示我們的LocationLiveData將遵照這個Fragment所持有的LifeCycle辦事。

• 如果LifeCycle不在Started或者RESUMED這兩個狀態，那麼觀察者將無法接受到資料更新的回撥，即使資料發生了變化。
• 如果LifeCycle銷燬了，即生命週期結束，觀察者將被自動從LiveData中移除。

既然LocationLiveData是生命週期感知的，那麼我們就可以稍微改動一下它的程式碼，讓它可以被多個Activity或者Fragment公用：

public class LocationLiveData extends LiveData<Location> {
    private static LocationLiveData sInstance;
    private LocationManager locationManager;

    @MainThread
    public static LocationLiveData get(Context context) {
        if (sInstance == null) {
            sInstance = new LocationLiveData(context.getApplicationContext());
        }
        return sInstance;
    }

    private SimpleLocationListener listener = new SimpleLocationListener() {
        @Override
        public void onLocationChanged(Location location) {
            setValue(location);
        }
    };

    private LocationLiveData(Context context) {
        locationManager = (LocationManager) context.getSystemService(
                Context.LOCATION_SERVICE);
    }

    @Override
    protected void onActive() {
        locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener);
    }

    @Override
    protected void onInactive() {
        locationManager.removeUpdates(listener);
    }
}
 

這裡使用單例的原因就是讓多個Activity或者Fragment共享一個LocationLiveData例項。
然後我們可以這麼使用：

public class MyFragment extends LifecycleFragment {
    public void onActivityCreated (Bundle savedInstanceState) {
        Util.checkUserStatus(result -> {
            if (result) {
                MyLocationListener.get(getActivity()).addObserver(this, location -> {
                   // update UI
                });
            }
        });
  }
}

通過這麼一改，現在即使有多個Activity或者Fragment在使用LocationLiveData，它也能對其進行優雅的管理。不必理會頁面銷燬帶來的諸多麻煩。

總結幾點LiveData的有點：

• 沒有記憶體溢位

當觀察者被繫結他們對應的LifeCycle以後，當頁面銷燬時他們會自動被溢位，不會導致記憶體溢位。

• 不會因為Activity的不可見導致Crash

當Activity不可見時，即使有資料變化，LiveData也不會通知觀察者。因為此時觀察者的LifeCyele並不處於Started或者RESUMED狀態。

• 配置的改變

噹噹前Activity配置改變（如螢幕方向），導致重新從onCreate走一遍，這是觀察者們會立刻收到配置變化前的最新資料。

• 資源共享

我們只需要一個LocationLivaData,連線系統服務一次，就能支援所有的觀察者。

• 不再有人為生命週期處理

通過上面的程式碼可以知道，我們的Activity或者Fragment只要在需要觀察資料的時候觀察資料即可，不需要理會生命週期變化了。這一切都交給LiveData來自動管理。

LiveData的轉換

有時候有這樣的需求，需要在LiveData將變化的資料通知給觀察者前，改變資料的型別；或者是返回一個不一樣的LiveData。

這裡介紹一個類Transformations,它可以幫助完成上面的這些操作。

• Transformations.map()

在LiveData資料的改變傳遞到觀察者之前，在資料上應用一個方法：

LiveData<User> userLiveData = ...;
LiveData<String> userName = Transformations.map(userLiveData, user -> {
    user.name + " " + user.lastName
});

這裡我們如果只需要知道變化使用者的名字，那麼只要觀察userName這個LiveData物件即可。它會從userLiveData資料中提取使用者名稱並傳遞給它自己的觀察者。

• Transformations.switchMap()

與Transformations.map()類似，只不過這裡傳遞個switchMap()的方法必須返回一個LiveData物件。

private LiveData<User> getUser(String id) {
  ...;
}

LiveData<String> userId = ...;
LiveData<User> user = Transformations.switchMap(userId, id -> getUser(id) );

當你考慮在ViewModel中使用LifeCycle物件時，這種轉換就是一個可選的解決方案。
假如有一下需求，使用者輸入一個地址，我們在螢幕上更新這個地址對應的郵編，簡單的寫法如下：

class MyViewModel extends ViewModel {
    private final PostalCodeRepository repository;
    public MyViewModel(PostalCodeRepository repository) {
       this.repository = repository;
    }

    private LiveData<String> getPostalCode(String address) {
       // DON'T DO THIS
       return repository.getPostCode(address);
    }
}

這樣寫問題顯然很嚴重，當每次呼叫getPostalCode方法後，UI程式碼中都需要對getPostalCode的返回值做註冊觀察者操作，並且還要移除上一個觀察者，這樣顯然是低效率的。此外，如果這時UI因為配置的變化（螢幕旋轉）重建了，那麼它會觸發再次呼叫getPostalCode，而不是使用之前的呼叫結果。

因此我們可以做如下轉換：

class MyViewModel extends ViewModel {
    private final PostalCodeRepository repository;
    private final MutableLiveData<String> addressInput = new MutableLiveData();
    public final LiveData<String> postalCode =
            Transformations.switchMap(addressInput, (address) -> {
                return repository.getPostCode(address);
             });

  public MyViewModel(PostalCodeRepository repository) {
      this.repository = repository
  }

  private void setInput(String address) {
      addressInput.setValue(address);
  }
}

注意，這裡我們將postalCode訪問限制符寫成public final，因為它將始終不變，UI只要在需要用的時候將觀察者註冊到postalCode中就行。這是當用戶呼叫setInput後，如果postalCode上有可活動的觀察者，那麼repository.getPostCode(address)就會被呼叫，如果此時沒有可活動的觀察者，則repository.getPostCode(address)不會被呼叫。

自定義轉換

在你的應用中可能需要除了上面兩種以外更多的LiveData的轉換，為了實現這些轉換，你可以使用MediatorLiveData類，它可以用來正確的處理其他多個LiveData的事件變化，並處理這些事件。MediatorLiveData會將自身的active/inactive狀態變化正確的傳遞給它所處理的LiveData，例如MediatorLiveData沒有觀察者的話，