Android架构组件包括：

• Lifecycles

• LiveData

• ViewModel

• Room

• Paging

• WorkManager

• DataBinding

• Navigation

 

LifeCycles&LiveData&ViewModel

首先，请查看下图，该图显示了设计应用后所有模块应如何相互交互：

每个组件仅依赖于其下一级的组件。例如，Activity 和 Fragment 仅依赖于视图模型。存储区是唯一一个依赖于其他多个类的类；在本例中，存储区依赖于持久性数据模型和远程后端数据源。

 

Lifecycles

背景

Android框架中定义的大多数应用程序组件都附加了生命周期。生命周期由操作系统或流程中运行的框架代码管理。它们是Android工作原理的核心，您的应用程序必须重视它们。不然可能会引发内存泄漏甚至应用程序崩溃。

举个栗子，我们有一个Activity，需要在屏幕上显示设备位置。常见的实现可能如下所示：

class MyLocationListener {
    public MyLocationListener(Context context, Callback callback) {
        // ...
    }

    void start() {
        // connect to system location service
    }

    void stop() {
        // disconnect from system location service
    }
}


class MyActivity extends AppCompatActivity {
    private MyLocationListener myLocationListener;

    @Override
    public void onCreate(...) {
        myLocationListener = new MyLocationListener(this, (location) -> {
            // update UI
        });
    }

    @Override
    public void onStart() {
        super.onStart();
        myLocationListener.start();
        // manage other components that need to respond
        // to the activity lifecycle
    }

    @Override
    public void onStop() {
        super.onStop();
        myLocationListener.stop();
        // manage other components that need to respond
        // to the activity lifecycle
    }
}

即使这个示例看起来很好，但在真实的应用程序中，最终会有太多的调用来管理UI和其他组件以响应生命周期的当前状态。管理多个组件会在生命周期方法中放置大量代码，例如 onStart() 和 onStop()，这使得它们难以维护。

 

此外，无法保证组件在Activity或Fragment停止之前启动。如果我们需要执行长时间运行的操作，例如在onStart()中进行某些配置检查，这可能导致竞争条件，可能会出现在onStart()中启动的配置检查组件还没完成其检查任务前就已经执行完onStop()了。这会使组件保持活动的时间大于其所需的时间。如下面例子所示：

class MyActivity extends AppCompatActivity {
    private MyLocationListener myLocationListener;

    public void onCreate(...) {
        myLocationListener = new MyLocationListener(this, location -> {
            // update UI
        });
    }

    @Override
    public void onStart() {
        super.onStart();
        Util.checkUserStatus(result -> {
            // 如果这个回调是在Activity onStop后才触发会发生什么?
            if (result) {
                myLocationListener.start();
            }
        });
    }

    @Override
    public void onStop() {
        super.onStop();
        myLocationListener.stop();
    }
}

简介

一个生命周期管理的组件，可管理Activity，Fragment和Service的生命周期，也可管理自定义对象的生命周期。能够避免内存泄漏，并且使加载数据到UI界面显示的过程更加方便。

 

结构

Lifecycle

Lifecycle 是一个类，它包含有关组件生命周期状态的信息（如活动或片段），并允许其他对象观察此状态。

Lifecycle 使用两个主要枚举来跟踪其关联组件的生命周期状态：

Event(事件)

从框架和Lifecycle类调度的生命周期事件 。这些事件映射到活动和片段中的回调事件。

State(状态)

Lifecycle对象跟踪的组件的当前状态 。

下图显示了Event与State的关系：

将状态视为图形的节点，将事件视为这些节点之间的边。

LifecycleObserver

LifecycleObserver是一个接口，没有任何方法，实现该接口的类表明是生命周期的观察者，可以通过LifecycleOwner类的addObserver(LifecycleObserver o)方法注册，被注册后，LifecycleObserver便可以观察到LifecycleOwner的生命周期事件。通过方法注解OnLifecycleEvent来实现观察者方法与生命状态变化事件（Event）的绑定。

LifecycleOwner

LifecycleOwner 是一个单一的方法接口，表示该类有一个 Lifecycle。它有一个方法， getLifecycle() 必须由类实现。如果您正在尝试管理整个应用程序流程的生命周期，可以使用ProcessLifecycleOwner，可以监控自身应用进入前台和退出到后台的变化事件。

此接口Lifecycle从各个类（例如Fragment和AppCompatActivity）中抽象出所有权 ，并允许编写与其一起使用的组件。任何自定义应用程序类都可以实现LifecycleOwner 接口。

与实现的组件LifecycleObserver 无缝实现工作的组件， LifecycleOwner 因为所有者可以提供生命周期，观察者可以注册观察。

android support包中的Activity和Fragment已实现好了这套Lifecycles；下图是以support包中Fragment为例的几个重要类之间的关系类图：

查看Fragment相关源码——>

优化MyLoacationListener

对于位置跟踪的例子，我们可以使MyLocationListener类实现LifecycleObserver ，然后在Activity的onCreate()方法中使用LifeCyclec初始化MyLocationListener。这允许 MyLocationListener类自给自足，这意味着响应生命周期状态变化的逻辑被声明在MyLocationListener中，而不是Acitity。使各个组件存储自己的逻辑使得Activity和Fragment逻辑更易于管理。

一个常见的情况是，如果Lifecycle现在不处于良好状态，则应避免调用某些回调 。例如，如果回调在保存Activity状态后运行Fragment事务，则会触发崩溃。或者在Activity stop之后展示PopupWindow,也会触发崩溃；这种情况也可以通过Lifecycle getCurrentState().isAtLeast方法来避免；

class MyLocationListener implements LifecycleObserver {
    private boolean enabled = false;
    public MyLocationListener(Context context, Lifecycle lifecycle, Callback callback) {
   ...
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    void start() {
        if (enabled) {
            // connect
        }
    }

    public void enable() {
        enabled = true;
        if (lifecycle.getCurrentState().isAtLeast(STARTED)) {
            // connect if not connected
        }
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    void stop() {
        // disconnect if connected
    }
}

自定义LifeCycleOwner

实现LifecycleOwner接口，并使用LifecycleRegistry 类，并且将自定义的生命周期事件转发到该类，如以下代码示例所示：

public class MyActivity extends Activity implements LifecycleOwner {
    private LifecycleRegistry mLifecycleRegistry;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mLifecycleRegistry = new LifecycleRegistry(this);
        mLifecycleRegistry.markState(Lifecycle.State.CREATED);
    }

    @Override
    public void onStart() {
        super.onStart();
        mLifecycleRegistry.markState(Lifecycle.State.STARTED);
    }

    @NonNull
    @Override
    public Lifecycle getLifecycle() {
        return mLifecycleRegistry;
    }
}

LiveData

简介

是一种可观察的数据存储器。应用中的其他组件可以使用此存储器来监控对象的更改，而无需在它们之间创建明确且严格的依赖路径。LiveData 组件还遵循应用组件（如 Activity、Fragment 和 Service）的生命周期状态，并包括清理逻辑以防止对象泄漏和过多的内存消耗。

与常规的Observable不同，LiveData能意识到应用程序组件的生命周期变化，这意味着它能遵守Activity、Fragment、Service等组件的生命周期。这种意识确保LiveData只更新处于活跃状态的应用程序组件Observer。

 

优点

确保UI符合数据状态 LiveData遵循观察者模式。 当生命周期状态改变时，LiveData会向Observer发出通知。 您可以把更新UI的代码合并在这些Observer对象中。不必去考虑导致数据变化的各个时机，每次数据有变化，Observer都会去更新UI。

没有内存泄漏 Observer会绑定具有生命周期的对象，并在这个绑定的对象被销毁后自行清理。

不会因停止Activity而发生崩溃 如果Observer的生命周期处于非活跃状态，例如在后退堆栈中的Activity，就不会收到任何LiveData事件的通知。

不需要手动处理生命周期 UI组件只需要去观察相关数据，不需要手动去停止或恢复观察。LiveData会进行自动管理这些事情，因为在观察时，它会感知到相应组件的生命周期变化。

始终保持最新的数据 如果一个对象的生命周期变到非活跃状态，它将在再次变为活跃状态时接收最新的数据。 例如，后台Activity在返回到前台后立即收到最新数据。

正确应对配置更改 如果一个Activity或Fragment由于配置更改（如设备旋转）而重新创建，它会立即收到最新的可用数据。

共享资源 您可以使用单例模式扩展LiveData对象并包装成系统服务，以便在应用程序中进行共享。LiveData对象一旦连接到系统服务，任何需要该资源的Observer都只需观察这个LiveData对象。

 

使用LiveData

一般使用LiveData的方法如下：

1. 创建一个LiveData的实例来保存特定类型的数据。 这通常在ViewModel类中完成。

2. 创建一个定义了onChanged()方法的Observer对象，当LiveData对象保存的数据发生变化时，onChanged()方法可以进行相应的处理。 您通常在UI控制器（如Activity或Fragment）中创建Observer对象。

3. 使用observe()方法将Observer对象注册到LiveData对象。 observe()方法还需要一个LifecycleOwner对象作为参数。 Observer对象订阅了LiveData对象，便会在数据发生变化时发出通知。 您通常需要UI控制器（如Activity或Fragment）中注册Observer对象。

当你更新LiveData对象中存储的数据时，所有注册了的Observer，只要所绑定的LifecycleOwner处于活动状态，就会被触发通知。 LiveData允许UI控制器Observer订阅更新。 当LiveData对象所保存的数据发生变化时，UI会在响应中自动更新。

 

创建LiveData

LiveData是一个包装器，可用于任何数据，包括实现Collections的对象，如List。一个 LiveData对象通常存储在ViewModel对象中，并通过getter方法访问，如以下示例所示：

public class NameViewModel extends ViewModel {

    // Create a LiveData with a String
    private MutableLiveData<String> mCurrentName;

    public MutableLiveData<String> getCurrentName() {
        if (mCurrentName == null) {
            mCurrentName = new MutableLiveData<String>();
        }
        return mCurrentName;
    }

// Rest of the ViewModel...
}

起初，LiveData对象中的数据未设置。

注意:确保在ViewModel而不是Activity或Fragment中保存用来更新UI的LiveData对象，原因如下：

• 避免臃肿的Activity和Fragment。 这些UI控制器负责显示数据而不是保存数据状态。

• 将LiveData实例与特定Activity或Fragment实例分离，这将使得LiveData对象在配置更改后仍然存活。

观察LiveData

在大多数情况下，出于以下原因，应用程序组件的onCreate()方法是开始观察LiveData对象的最佳位置：

1. 确保系统不会从Activity或Fragment的onResume()方法中进行多余的调用。

2. 确保Activity或Fragment一旦变为活动状态时，就有可展示的数据。 当应用程序组件处于STARTED状态，它就需从它所观察的LiveData对象中接收到最新的值。 所以我们需要在一开始就设置好观察。

通常情况下，LiveData只在数据有变化时，给活跃的Observer进行通知。 此行为的一个例外是，Observer在从非活跃状态变为活跃状态时也会收到通知。 并且，如果Observer第二次从非活跃状态变为活跃状态，则只有在自上一次变为活跃状态以来该数据发生变化时才会接收到更新。

以下示例代码演示了如何开始观察LiveData对象：

public class NameActivity extends AppCompatActivity {

    private NameViewModel mModel;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // Other code to setup the activity...

        // Get the ViewModel.
        mModel = ViewModelProviders.of(this).get(NameViewModel.class);

        // Create the observer which updates the UI.
        final Observer<String> nameObserver = new Observer<String>() {
            @Override
            public void onChanged(@Nullable final String newName) {
                // Update the UI, in this case, a TextView.
                mNameTextView.setText(newName);
            }
        };

        // Observe the LiveData, passing in this activity as the LifecycleOwner and the observer.
        mModel.getCurrentName().observe(this, nameObserver);
    }
}

传递nameObserver作为参数,调用observe()之后，将立即回调onChanged()，提供存储在mCurrentName中的最新值。 如果LiveData对象mCurrentName的值并未设置，则不调用onChanged()。

 

更新LiveData对象

LiveData没有公用的方法来更新存储的数据。 MutableLiveData类暴露公用的setValue(T)和postValue(T)方法，如果需要编辑存储在LiveData对象中的值，必须使用这两个方法。 通常在ViewModel中使用MutableLiveData，然后ViewModel仅向Observer公开不可变的LiveData对象。

在建立观察者关系之后，可以更新LiveData对象的值，如以下示例所示，当用户点击按钮时向所有观察者发出通知：

mButton.setOnClickListener(new OnClickListener() {
    @Override
    public void onClick(View v) {
        String anotherName = "John Doe";
        mModel.getCurrentName().setValue(anotherName);
    }
});

在示例中调用setValue(T)会导致Observer使用值"John Doe"调用onChanged()方法。 这个例子展示了点击按钮，setValue()或者postValue()被调用来更新mName，原因有多种，包括响应网络请求或数据库加载完成；在所有情况下，调用setValue()或postValue()都会触发观察者并更新UI。

LiveData配合Room使用

Room持久性库支持Observable查询返回LiveData对象。 Observable查询成为数据库访问对象（DAO）的一项功能。 当更新数据库时，会生成所有必要的代码来更新LiveData对象。 生成的代码在需要时在后台线程上异步运行查询。 这种模式对于保持用户界面中显示的数据与存储在数据库中的数据同步很有用。 您可以在Room持久性库指南中阅读关于Room和DAO的更多信息。

 

扩展LiveData

如果Observer的生命周期处于STARTED或RESUMED状态，则LiveData将认为Observer处于活动状态。以下示例代码说明了如何扩展LiveData类：

public class StockLiveData extends LiveData<BigDecimal> {
    private StockManager mStockManager;

    private SimplePriceListener mListener = new SimplePriceListener() {
        @Override
        public void onPriceChanged(BigDecimal price) {
            setValue(price);
        }
    };

    public StockLiveData(String symbol) {
        mStockManager = new StockManager(symbol);
    }

    @Override
    protected void onActive() {
        mStockManager.requestPriceUpdates(mListener);
    }

    @Override
    protected void onInactive() {
        mStockManager.removeUpdates(mListener);
    }
}

本例中StockLiveData的实现包括以下重要的方法：

• 当LiveData对象有一个活跃的Observer时，onActive()方法被调用。 这意味着你需要从这个方法开始观察股票价格的更新。

• 当LiveData对象没有任何活跃的Observer时，onInactive()方法被调用。 由于没有Observer在监听，所以没有理由继续保持与StockManager服务的连接。

• setValue(T)方法更新LiveData实例的值，并通知活动观察者有关更改。 您可以这样使用StockLiveData类，如下所示：

public class MyFragment extends Fragment {
    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);
        LiveData<BigDecimal> myPriceListener = ...;
        myPriceListener.observe(this, price -> {
            // Update the UI.
        });
    }
}

observe()方法第一个参数是作为LifecycleOwner实例的Fragment。 这样做表示此Observer绑定了Lifecycle对象的生命周期，即：

• 如果Lifecycle对象不处于活动状态，则即使值发生更改，也不会调用Observer。

• Lifecycle对象被销毁后，Observer被自动删除。 LiveData对象具有感知生命周期的能力意味着您可以在多个Activity，Fragment和service之间共享它们。 为了保持简洁，你可以使用单例模式实现LiveData，如下所示：

public class StockLiveData extends LiveData<BigDecimal> {
    private static StockLiveData sInstance;
    private StockManager mStockManager;

    private SimplePriceListener mListener = new SimplePriceListener() {
        @Override
        public void onPriceChanged(BigDecimal price) {
            setValue(price);
        }
    };

    @MainThread
    public static StockLiveData get(String symbol) {
        if (sInstance == null) {
            sInstance = new StockLiveData(symbol);
        }
        return sInstance;
    }

    private StockLiveData(String symbol) {
        mStockManager = new StockManager(symbol);
    }

    @Override
    protected void onActive() {
        mStockManager.requestPriceUpdates(mListener);
    }

    @Override
    protected void onInactive() {
        mStockManager.removeUpdates(mListener);
    }
}

你可以在Fragment中使用它，如下所示：

public class MyFragment extends Fragment {
    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        StockLiveData.get(getActivity()).observe(this, price -> {
            // Update the UI.
        });
    }
}

多个Activity和Fragment可以观察到MyPriceListener实例。 LiveData只在他们至少一个处于可见和活跃状态时才连接到系统服务。

 

转换LiveData

您可能希望先转换存储在LiveData对象中的值，然后再将其分派给Observer，或者您可能需要根据一个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对象中的值，并向下传递结果。 传递给switchMap()的函数必须返回一个LiveData对象，如下例所示：

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

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

您可以使用转换方法在Observer的生命周期中传递信息。 除非Observer正在观看返回的LiveData对象，否则不会计算转换。 由于转换是延迟计算的，所以与生命周期相关的行为隐式传递，而不需要额外的显式调用或依赖关系。 如果您认为在ViewModel对象中需要Lifecycle对象，则转换可能是更好的解决方案。 例如，假设您有一个接受地址并返回该地址的邮政编码的UI组件。 您可以为此组件实现朴素的ViewModel，如以下示例代码所示：

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

UI组件随后需要从以前的LiveData对象注销，并在每次调用getPostalCode()时注册到新实例。 另外，如果UI组件被重新创建，它会触发对repository.getPostCode()方法的另一个调用，而不是使用前一个调用的结果。 相反，您可以实现邮政编码查找作为地址输入的转换，如以下示例所示：

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字段是公开的和最终的，因为该字段永远不会改变。 postalCode字段定义为addressInput的转换，这意味着addressInput发生更改时,如果有一个活跃的Observer,将调用repository.getPostCode()方法,如果在repository.getPostCode()被调用时没有活跃的Observer，直到添加一个观察者才会进行计算。 此机制允许较低级别的应用程序创建按需延迟计算的LiveData对象。 ViewModel对象可以很容易地获得对LiveData对象的引用，然后在其上定义转换规则。

 

合并多个LiveData源

MediatorLiveData是LiveData的一个子类，帮助您合并多个LiveData源。 在任何原始LiveData源对象改变后，MediatorLiveData对象的Observer会被触发。 例如，如果在UI中有一个从本地数据库或网络获取更新的LiveData对象，则可以将以下数据源添加到MediatorLiveData对象：

• 与存储在数据库中的数据关联的LiveData对象。

• 与从网络访问的数据关联的LiveData对象。 您的Activity只需观察MediatorLiveData对象即可接收来自两个数据源的更新。

 

ViewModel

简介

ViewModel对象为特定的界面组件（如 Fragment 或 Activity）提供数据，并包含数据处理业务逻辑，以与模型进行通信。例如，ViewModel 可以调用其他组件来加载数据，还可以转发用户请求来修改数据。ViewModel 不了解界面组件，因此不受配置更改（如在旋转设备时重新创建 Activity）的影响。

Android framework管理UI控制器（如Activity和Fragment）的生命周期。 framework可能会决定销毁或重新创建UI控制器，以响应完全不受控制的某些用户操作或设备事件。

如果系统销毁或重新创建UI控制器，则存储在其中的所有临时的UI相关数据都将丢失。 举个例子，您的应用中的一个Activity可能包含用户列表。 当因配置更改重新创建Activity时，新Activity必须重新获取用户列表。 对于简单数据，活动可以使用onSaveInstanceState()方法并从onCreate()中的数据包中恢复其数据，但是此方法仅适用于可以序列化然后反序列化的少量数据，而不适用于潜在的大量数据,例如用户列表或位图。

另一个问题是UI控制器经常需要异步请求，需要一些时间才能获取结果。 UI控制器需要管理这些请求，确保在系统销毁自己时，清理这些请求以避免潜在的内存泄漏。 这种管理需要大量的维护代码，并且在因配置更改而重新创建UI控制器的时，可能不得不重新发出已经发出过的请求，这样会浪费许多资源。

UI控制器（如Activity和Fragment）主要用于显示UI数据，对用户操作做出响应，或处理与操作系统之间的通信（如权限请求）。 再让UI控制器负责从数据库或网络加载数据，会导致该类过度臃肿。 给UI控制器分配过多的工作，可能会导致一个类去单独处理应用程序的所有工作，而不是将工作委托给其他类。 给UI控制器分配过多的工作也使得测试工作变得更加困难。

将视图数据的所有权从UI控制器逻辑中分离出来，会让项目更简单，更高效。

 

使用ViewModel

Android架构组件为UI控制器提供了ViewModel助手类，以便给UI准备数据。ViewModel对象在配置更改期间会自动保留，以便它们保存的数据可以立即提供给新的Activity或Fragment实例。 例如，您如果需要在应用程序中显示用户列表，请确保将获取用户列表的工作让ViewModel去做，而不是Activity或Fragment，如以下示例代码所示：

public class MyViewModel extends ViewModel {
    private MutableLiveData<List<User>> users;
    public LiveData<List<User>> getUsers() {
        if (users == null) {
            users = new MutableLiveData<List<Users>>();
            loadUsers();
        }
        return users;
    }

    private void loadUsers() {
        // Do an asyncronous operation to fetch users.
    }
}

然后，您可以在Activity中按如下方式访问用户列表：

public class MyActivity extends AppCompatActivity {
    public void onCreate(Bundle savedInstanceState) {
        // Create a ViewModel the first time the system calls an activity's onCreate() method.
        // Re-created activities receive the same MyViewModel instance created by the first activity.

        MyViewModel model = ViewModelProviders.of(this).get(MyViewModel.class);
        model.getUsers().observe(this, users -> {
            // update UI
        });
    }
}

如果重新创建Activity，它将接收由第一个Activity创建的那个MyViewModel实例。 当持有ViewModel的Activity被FINISHED之后，framework将调用ViewModel对象的onCleared()方法，以便清理资源。

业务逻辑也应该在ViewModel中进行处理:

 public class UserActivity extends Activity {

     @Override
     protected void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         setContentView(R.layout.user_activity_layout);
         final UserModel viewModel = 		             ViewModelProviders.of(this).get(UserModel.class);
         viewModel.userLiveData.observer(this, new Observer() {
            @Override
             public void onChanged(@Nullable User data) {
                 // update ui.
             }
         });
         findViewById(R.id.button).setOnClickListener(new View.OnClickListener() {
             @Override
             public void onClick(View v) {
                  viewModel.doAction();
             }
         });
     }
 }

 public class UserModel extends ViewModel {
     public final LiveData<User> userLiveData = new LiveData<>();

     public UserModel() {
         // trigger user load.
     }

     void doAction() {
         // depending on the action, do necessary business logic calls and update the
         // userLiveData.
     }
 }

ViewModel的寿命和View、LifecycleOwners实例无关。 这样做也方便了您编写覆盖ViewModel的测试，因为它不用去考虑生命周期。 ViewModel对象可以包含LifecycleObservers，例如LiveData对象。 但是，ViewModel对象绝不能去观察有生命周期感知能力的Observer（如LiveData对象）。 如果ViewModel需要Context，例如获得一个系统服务，那么它可以扩展AndroidViewModel类，并在构造函数中有一个接收Application的构造函数，而Application是Context的子类。

 

ViewModel的生命周期

ViewModel生命长度是在获取ViewModel时传递给ViewModelProvider的对象的生命周期决定的。 ViewModel保留在内存中，直到所依赖的有生命周期的对象永久消失：在Activity的情况下，当它被FINISHED，而在Fragment的情况下，当它被DETACHED。

下图展示了一个活动在经历一个循环后的各种生命周期状态，然后结束。 该图还显示了相关活动生命周期旁边的ViewModel的生命周期。 这个特定的图表说明了一个活动的状态。 相同的基本状态适用于片段的生命周期。

您通常在系统第一次调用Activity对象的onCreate()方法时初始化ViewModel。 系统可能会在Activity的整个生命周期内多次调用onCreate()，例如当设备屏幕旋转时。 ViewModel的生命周期从第一次请求ViewModel开始，直到Activity被FINISHED并销毁。

 

在Fragment之间共享数据

Activity中Fragment们需要相互通信是很常见的事情。 想象一下，用户在一个Fragment的列表中选择一个项目，另一个Fragment显示所选项目的内容。 这实现起来并不太容易，因为这两个Fragment都需要定义一些接口，而它们的Activity必须将两者联系在一起。 此外，Fragment必须处理另一个Fragment尚未创建或可见的情况。

ViewModel可以解决这个常见的痛点。 Fragment可以通过一个在Activity范围内共享的ViewModel来处理彼此的通信，如以下示例代码所示：

public class SharedViewModel extends ViewModel {
    private final MutableLiveData<Item> selected = new MutableLiveData<Item>();

    public void select(Item item) {
        selected.setValue(item);
    }

    public LiveData<Item> getSelected() {
        return selected;
    }
}

public class MasterFragment extends Fragment {
    private SharedViewModel model;
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        itemSelector.setOnClickListener(item -> {
            model.select(item);
        });
    }
}

public class DetailFragment extends Fragment {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        SharedViewModel model = ViewModelProviders.of(getActivity()).get(SharedViewModel.class);
        model.getSelected().observe(this, { item ->
           // Update the UI.
        });
    }
}

请注意，在获取ViewModel时，两个Fragment都要使用getActivity()。这样，这两个Fragment会收到同一个SharedViewModel实例，该实例的作用域为Activity。

这样做有以下好处：

• 这个Activity不需要做任何事情，也不需要知道Fragment之间的交流。

• 除了SharedViewModel的接口之外，Fragment不需要了解彼此。 如果其中一个Fragment消失，另一个Fragment继续照常工作。

• 每个Fragment都有自己的生命周期，不受其他生命周期的影响。 一个Fragment替换成另一个Fragment，UI继续工作也没有任何问题。

 

用ViewModel替换Loader

  像CursorLoader这样的Loader类经常被用来保持应用程序中UI数据与数据库同步。 您可以使用ViewModel和其他几个类来替换Loader。 使用ViewModel将UI控制器与数据加载操作分开，这意味着您在类之间的强引用减少了。

  Loader常见的用处是观察数据库的内容。 当数据库中的值发生更改时，Loader会自动触发重新加载数据并更新UI：

  配合使用ViewModel、Room和LiveData来替换Loader。 ViewModel确保数据在设备配置更改后仍然存在。 当数据库发生变化时，Room会通知你的LiveData，而LiveData则用修改后的数据更新你的UI。

随着你的数据变得越来越复杂，你可能会选择一个单独的类来加载数据。 ViewModel的目的是封装UI控制器的数据，以使数据在配置更改后不受影响。