Android之简单描述jetpack

把很多变量，逻辑和数据摆在我们的Activity和Fragment中，这样的代码很混乱，难以维护。

这样的开发模式违反了单一责任的原则。

而ViewModel可以有效地划分责任。

具体的可以用于持有和UI元素相关的数据 ，以保证这些数据在屏幕旋转时不会丢失，以及负责和仓库之间进行通讯。

然后Activity仅负责了解如何在屏幕上显示该数据和接受用户互动，但是它不会处理这些互动。

---

如果你的应用需要获取和存储数据，那么建议创建一个Repository的仓库储存区类。

存储与加载应用数据的API，要做的工作是自主判断接口请求的数据应该是从数据库中读取还是从网络中获取，并将数据返回给调用方。如果是从网络中获取的话还要将这些数据存入到数据库当中，以避免下次重复从网络中获取。简而言之，仓库的工作就是在本地和网络数据之间做一个分配和调度的工作，调用方不管你的数据是从何而来的，我只是要从你仓库这里获取数据而已，而仓库则要自主分配如何更好更快地将数据提供给调用方。

---

至于去哪里分配和调度又分为了两条互不相干的路线。

如果本地没有，就去网络上调取并存到本地进行缓存。

如果本地有，直接拿。

本地数据层：实现方式并不固定，使用了LitePal来进行数据持久化处理，也可以使用Room库，最后两者也都是去访问SQLite本地数据库。

网络数据层：可以使用Retrofit从webservice接口获取数据。

图中所有的箭头都是单向的，比方说WeatherActivity指向了WeatherViewModel，表示WeatherActivity持有WeatherViewModel的引用，但是反过来WeatherViewModel不能持有WeatherActivity的引用。其他的几层也是一样的道理，一个箭头就表示持有一个引用。

还有，引用不能跨层持有，就比方说UI控制层不能持有仓库层的引用，每一层的组件都只能和它的相邻层交互。

(此图取自https://gitcode.net/mirrors/guolindev/coolweatherjetpack/-/tree/master/app/src/main/java/com/coolweather/coolweatherjetpack/ui)

---

另外，应该确保ViewModel不会因为承担过多责任而臃肿。

避免这种情况，则可以创建Presenter类，来处理UI数据。

或者实现更成熟的架构。