安卓 Jetpack学习笔记
第四章 ViewModel
4.4 ViewModel的原理
不要向 ViewModel中传入任何类型的Context或带有 Context引用的对象
从ViewModelStore 的源码可以看出，ViewModel实际上是以HashMap<String.ViewModel>的形式被缓存起来了。ViewModel 与页面之间没有直接的关联，它们通过ViewModelProvider 进行关联。当页面需要 ViewModel 时，会向ViewModelProvider 索要，ViewModelProvider 检查该 ViewModel 是否已经存在于缓存中，若存在，则直接返回，若不存在，则实例化一个。因此，Activity 由于配置变化导致的销毁重建并不会影响 ViewModel，ViewModel 是独立于页面而存在的。也正因为此，我们在使用 ViewModel 时，需要特别注意，不要向 ViewModel中传入任何类型的Context或带有 Context引用的对象，这可能会导致页面无法被销毁，从而引发内存泄漏。
4.7总结
需要注意的是，在使用 ViewModel 的过程中，千万不要将任何类型的 Context或带有Context引用的对象传入ViewModel，这可能会引发内存泄漏。如果一定要在ViewModel中使用Context,那么建议使用ViewModel的子类AndroidViewModel。
第五章 LiveData
5.1实时数据LiveData
在上一章中，我们学习了 ViewModel，了解到 ViewModel 的主要作用是存放页面所需要的各种数据。我们在示例代码中定义了接口，当数据发生变化时，采用接口的方式实现对页面的通知。对此前面已经做了相关说明，通过接口的方式对页面进行通知是可行的，但如果要观察的数据很多，则需要定义大量的接口，代码会显得十分冗余。为此，Jetpack 提供了 LiveData 组件。
LiveData 是一个可被观察的数据容器类。具体说来，可以将 LiveData 理解为一个数据的容器，它将数据包装起来，使数据成为被观察者，当该数据发生变化时，观察者能够获得通知。我们不需要自已去实现观察者模式，LiveData 内部已经默认实现好了，我们只要使用就可以了。
5.2 LiveData和ViewModel的关系
对页面来说，它并不关心 ViewModel 中的业务逻辑，它只关心需要展示的数据是什么，并且希望在数据发生变化时，能及时得到通知并做出更新。LiveData的作用就是，在 ViewModel 中的数据发生变化时通知页面。因此，LiveData 通常被放在 ViewModel中使用，用于包装 ViewModel 中那些需要被外界观察的数据。我们从 LiveData(实时数据)这个名字，也能大概推测出它的特性与作用。
5.3 LiveData的基本使用方法
LiveData 是一个抽象类，不能直接使用。通常我们使用的是它的直接子类MutableLiveData。
5.7 总结
ViewModel 用于存放页面的数据，当数据发生变化时，我们需要通知页面进行更新。在没有 LiveData 之前，可以通过定义接口完成这个需求，有了 LiveData后，事情变得更加简单、方便。使用 LiveData 对 ViewModel中我们关心的数据进行包装，并在页面中对其进行监听，当数据发生变化时，页面就能收到通知，进而更新 UI。
LiveData 的本质是观察者模式，并且它能感知页面的生命周期，只在页面存活时才会进行通知，从而避免了内存泄漏。当然你也可以使用 observeForever()方法让 LiveData忽略页面的生命周期，但用完后，一定要记得使用removeObserver()方法移除监听，否则会造成内存泄漏。
LiveData 大部分时候是在 ViewModel 中使用的。但它的作用不止于此，LiveData 在其他地方也能发挥重要作用。Jetpack 在设计之初就充分考虑了组件配合使用的需求。例如，我们在下一章将会学习，LiveData 如何搭配 Room 数据库组件进行使用。
第六章 Room
6.3 Room与LiveData、ViewModel结合使用
运行应用程序，当对数据库进行增加、删除或修改操作时onChange(List
6.6总结
在本章中，我们学会了如何使用 Room 组件来创建数据库，并对数据库进行增删/改/查等基本操作。Jetpack 在各个组件设计之初就考虑到了组件搭配使用的问题，LiveData 可以很好地配合 Room，实现数据的更新。
第九章 Paging
第十章 MVVM架构
10.2 数据模型驱动界面更新
我们希望数据在发生变化时，界面能够自动得到通知并进行更新，这就是数据模型驱动界面更新
MVVM 架构的应用程序采用了数据模型驱动界面更新的设计方案。因此，在了解MVVM之前，我们需要先了解数据模型驱动界面更新的概念。我们希望数据在发生变化时，界面能够自动得到通知并进行更新，这就是数据模型驱动界面更新。对于普通应用程序，数据的来源无非就两种，一种来源于本地，通常是本地数据库;另外一种来源于远程服务端，即网络数据，如图 10-1 所示。
在 Repository 层处理本地数据和网络数据之间的业务逻辑，让 Repository 层对 ViewModel 层负责，使 ViewModel只需要关心自己的业务逻辑，而不用关心数据的具体来源，这便是 Repository 层存在的意义。
从图 10-1 可以看出，ViewModel 层的数据既可以来源于本地数据库，也可以来源于远程服务器。在实际开发过程中，为了更好的用户体验，通常我们会将本地数据库和远程服务器这两种方式进行结合。若在 ViewModel 层对本地数据和网络数据进行业务逻辑处理，势必会增加 ViewModel 的复杂度。因此，可以在ViewModel层和Model 层之间引 Repository 层。在 Repository 层处理本地数据和网络数据之间的业务逻辑，让 Repository 层对 ViewModel 层负责，使 ViewModel只需要关心自己的业务逻辑，而不用关心数据的具体来源，这便是 Repository 层存在的意义。引入 Repository 层后的架构如图 10-2 所示。
请永远记住，MVVM 架构中每一层的职责都是清晰的、明确的，且只对其上层负责。这样从长远来看，随着代码量的增加，不容易让项目陷人技术债务中并且由于每一层的职责单一，每个模块也更容易进行独立测试。
