翻译官方文档LiveData

官方文档链接：https://developer.android.google.cn/topic/libraries/architecture/livedata.html

1.前言

---

前面讲到了AAC框架对于生命周期的支持，这一篇来看看框架自己提供的可感知生命周期的类。除了学会怎么使用它，还能增加对框架的核心Lifecycle的认识。

2.使用案例

---

LiveData这个类持有数据并允许数据被观察。不同于普通的被观察者，它可以被指定组件的Lifecycle，按照该生命周期提供观察的通知。LiveData认为，只有当观察者绑定的Lifecycle.State处于STARTED或者RESUMED时，观察者才是活跃的（可以发送通知）。

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有一个活跃的观察者时就会被调用。可以在这里开始观察设备位置的更新。
• onInactive()，当LiveData连一个活跃的观察者都没有时就会被调用。此时没有必要与位置服务保持连接，因为保持连接会消耗大量的电量而且没任何作用。
• setValue()，调用此方法更新LiveData中的数据，并通知活跃的观察者发生的改变。

LocationLiveData可以按照以下方式使用：

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

observe()方法传入LifecycleOwner对象作为第一个参数，意味着之后传入的观察者将绑定到Lifecycle上：

• 如果Lifecycle不在活跃状态（STARTED或RESUMED），当值发生改变后，观察者并不会收到通知。
• 如果Lifecycle被销毁了，观察者将自动从观察队列中移除。

3.生命周期感知

---

实际上，LiveData的生命周期感知特性提供了新的选择：在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);
    }
}

现对上面的Fragment进行如下改写：

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

即使有多个Activity和Fragment在观察LocationLiveData对象，但仍能做到规范地管理，比如，至少有一个观察者是活跃的，才会连接到系统服务。所以，使用LiveData有以下好处：

• 不会内存泄漏：既然观察者绑定到了自己的Lifecycle对象上，那么当生命周期结束时，会被自动清理。
• 不会因为Activity停止而崩溃：如果观察者的Lifecycle不是活跃状态（比如在回退栈中），将不会收到改变的事件。
• 始终保持数据最新：如果Lifecycle重新启动（比如，Activity从回退栈中恢复到STARTED状态），观察者将接收到最新的位置信息（除非还没有）。
• 正确处理配置更改：如果Activity或Fragment由于配置更改（比如，旋转屏幕）而重建，观察者立刻接收到最新有效的位置信息。
• 共享资源：可以保持单个LocationLiveData实例，只连接到系统服务一次，并且正确支持应用中所有的观察者。
• 不需要手动处理生命周期：也许会注意到，例子中的Fragment仅在想要时观察数据，不用担心生命周期结束后，仍在观察或才开始观察。Lifecycle会自动管理所有的一切，只要Fragment在观察时提供了自己的Lifecycle。

4.LiveData转换

---

有时候，希望在给观察者分发数据之前改变LiveData的值，或者根据不同的值返回不同的LiveData对象。Lifecycle包提供了Transformations类，包含有助于执行这些操作的方法。

• Transformations.map()

  适用于传入改变LiveData值的方法，并将结果向下游传递。

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

• Transformations.switchMap()

  与map()方法类似，适用于传入改变LiveData的值再封装起来的方法，并将结果向下游传递。注意，传入的方法返回的LiveData对象必须包含Lifecycle。

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

这些转换操作允许在调用链上携带传递观察者绑定的Lifecycle信息，当有观察者观察转换后的LiveData时，才真正开始执行这些转换（类似响应式编程）。这种方式允许隐式传递生命周期相关的行为，不需要添加显式的调用和依赖。任何时候，在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()方法时，先从之前的LiveData对象中注销观察者，再注册到新的LiveData对象中。此外，当界面重建时，将会重新调用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修饰。定义了基于addressInput对象的转换，当它发生改变且有活跃的观察者时，将会调用getPostalCode()方法。若当时没有活跃的观察者，不会执行任何转换直到加入一个观察者。

这种机制允许在应用底层创建LiveData对象，并满足响应式地运行。而ViewModel能容易地获取它们，并基于它们定义转换规则。

5.创建新的转换

---

应用可能需要十几种不同类型地特定转换，但是默认没有提供。可以使用MediatorLiveData类来实现自己所需的转换，因为它是为了正确监听其它LiveData实例，并处理它们发出的事件而专门创建的类。MediatorLiveData关注于正确传递活跃/非活跃状态给原始的LiveData。

6.总结

---

LiveData目的就是为了控制反转（IOC），实时地反馈数据的变化来驱动界面的更新。因为数据变化的发生不受界面控制，若不加入对界面生命周期的监听，容易出现操作的发生与界面的生命周期不符。