Android架构模式篇

根据项目的复杂程度选择架构，可是是项目结构更加清晰

MVC：model-view-control

model：模型，就是获取数据的接口

View：一般指布局文件

control：一般指Activity或Fragment

MVP

由于Activity跟Fragment中代码臃肿，所有需要将其中的Activity中的业务逻辑抽到presenter。

具体实现逻辑：定义更新更新View的接口，让Activity实现接口，定义presenter将Activity传过去。

MVVM

通过双向数据绑定DataBinding实现模型和视图的自动更新

DataBinding

DataBinding：布局文件外层是layout，编译后会生成DataBinding类文件，DataBinder类会有布局文件中控件，在布局文件中可以给属性以及事件关联对象的属性或方法，也可以进行一些运算。

ViewModel

ViewModel：类旨在以注重生命周期的方式存储和管理界面相关数据。第一viewmodel在activity和fragment销毁时自己也会被清除掉，第二点viewmodel在屏幕旋转activity销毁后重建可以显示之前数据。

原理：在参数变化销毁时时，会调用onRetainNonConfigurationInstance保存之前的ViewModelStore，重建时可以调用getLastNonConfigurationInstance获取之前的ViewModelStore。又通过ViewModelProvider管理ViewModelStore。

ViewModel可以解决以下痛点

1. 数据持久化

在屏幕旋转的时候会经历 Activity 的销毁与重新创建，这里就涉及到数据保存的问题，显然重新请求或加载数据是不友好的。在ViewModel 出现之前我们可以用 Activity 的 onSaveInstanceState() 机制保存和恢复数据，但缺点很明显，onSaveInstanceState只适合保存少量的可以被序列化、反序列化的数据，这种机制明显不合适。

ViewModel 生命周期图如下：

由图可知，ViewModel 生命周期是贯穿整个 activity 生命周期，包括 Activity 因旋转造成的重创建，直到 Activity 真正意义上销毁后才会结束。既然如此，用来存放数据再好不过了。

2. 异步回调问题

通常我们 App 需要频繁异步请求数据，比如调接口请求服务器数据。当然这些请求的回调都是相当耗时的，之前我们在 Activity 或Fragment里接收这些回调。所以不得不考虑潜在的内存泄漏情况，比如 Activity被销毁后接口请求才返回。处理这些问题，会给我们增添好多复杂的工作。但现在我们利用 ViewModel处理数据回调，可以完美的解决此痛点。意思只要继承我们的ViewModel后，可能会出现的bug，google都帮我们处理了。

3. 分担 UI controller 负担

从最早的 MVC 到目前流行的 MVP、MVVM，目的无非是 明确职责，分离 UI Controller 负担。 UI Controller比如 Activity 、Fragment是设计用来渲染展示数据、响应用户行为、处理系统的某些交互。如果再要求他去负责加载网络或数据库数据，会让其显得臃肿和难以管理。

所以为了简洁、清爽、丝滑，我们可以分离出数据操作的职责给 ViewModel。

4. Fragments 间共享数据

比如在一个 Activity 里有多个 Fragment，这 Fragment 之间需要做某些交互。我之前的做法是接口回调，需要统一在 Activity 里管理，并且不可避免的 Fragment 之间还得互相持有对方的引用。

ViewModel生命周期

ViewModel对象的范围由获取ViewModel时传递至ViewModelProvider的Lifecycle所决定。ViewModel始终处在内存中，直到Lifecycle永久地离开—对于Activity来说，是当它终止（finish）的时候，对于Fragment来说，是当它分离（detached）的时候。

Activity在生命周期中可能会触发多次onCreate()，而ViewModel则只会在第一次onCreate()时创建，然后直到最后Activity销毁。当ViewModel的实例生成之后，它会一直待在内存中，直到对应的Lifecycle彻底结束。

从图中可以看出，在第一次调用Activity对象的onCreate()方法时创建了一个ViewModel。在Activity运行过程中可能会多次调用onCreate()方法（比如当设备屏幕旋转时），但是ViewModel一直存在，直到Activity结束并销毁。这意味着ViewModel不会因为它的创建者的一个配置变化而被销毁，Activity的新实例将与现有的ViewModel重新连接。

这里最大的亮点是以生命周期的方式。举例：假如在Activity里使用，他会贯穿整个Activity里的生命周期。

ViewModel只会在Activity存活，且只会创建一次。当销毁时，会主动调用onClered。

因为在Activity存活时，只创建一次，那么在此Activity下的所有Fragment都可以共享一个ViewModel。 由于 ViewModel 生命周期可能长与 activity生命周期，所以为了避免内存泄漏Google禁止在ViewModel中持有Context或activity或view的引用。如果非得使用Context，可以继承AndroidViewModel类中获取ApplicationContext。

LiveData

LiveData：是一个泛型类，泛型对象就是要观察的对象。

数据观察：LiveData 允许其他组件（如 Activity、Fragment 或 Service）观察数据的变化。当数据发生变化时，相关观察者将收到通知，并可以执行相应的操作。

生命周期感知：LiveData 可以感知相关组件的生命周期状态，只有当组件处于活跃状态时，LiveData 才会通知观察者进行更新。这可以防止资源浪费和内存泄漏。

线程安全：LiveData 提供了主线程执行机制，确保数据更改和观察者通知都在主线程中进行。这样可以避免在主线程之外进行 UI 更新，从而简化了多线程操作。

数据更新控制：LiveData 具有精确的数据更新控制机制。LiveData 只会在数据实际发生变化时才通知观察者更新，避免了观察者在数据没有实际变化时多次接收通知。

使用时一般继承MutableLiveData才可以发送消息，LiveData 只能接收消息

一般调用setValue、postValue（子线程）通知更新视图