安卓MVVM架构--联合《第一行代码》SunnyWeather实战解说
没有架构之前的天下早期没有 MVVM 的时候，Activity 或 Fragment 里通常既负责 UI 展示，也直接进行数据获取，包括网络请求、数据库操作等。这种做法被称为 God Activity，导致了代码维护困难，常见题目包括：
[*]代码职责混乱
Activity/Fragment 既处置惩罚 UI，又负责业务逻辑和数据请求，导致代码量巨大，难以维护。
[*] 生命周期管理困难
在早期开发中，假如 Activity 旋转（横竖屏切换），onCreate() 会重新执行，导致数据丢失。
需要手动管理 AsyncTask、Thread，否则会导致 内存走漏 或 瓦解。
.....
总结：没有架构的代码 -- 耦合度高、可读性、可扩展性、可测试性低
MVVM(Model - View - ViewModel)架构
各层简介
View层--仅负责 UI 界面和用户交互
ViewModel层 -- 存储和UI界面相关的数据（谷歌为支持这种架构提出了JetPack ViewModel，下文中请注意区分）
Model层 -- 负责数据的存储和获取，并进行业务逻辑的处置惩罚
图解
开发者文档中图片如下：
https://i-blog.csdnimg.cn/direct/d79fa0b2da094fb9953a325297093e60.png
UILayer
界面层由以下两部分组成：
[*] 在屏幕上出现数据的界面元素。您可以使用 View 或 Jetpack Compose 函数构建这些元素。
[*] 用于存储数据、向界面提供数据以及处置惩罚逻辑的状态容器（如 ViewModel 类）。
Data Layer
数据层（Data Layer）的重要职责是从不同的数据源（如网络请求、本地数据库、文件等）获取数据。
[*] 为了提高封装性，通常会对外提供一个同一的接口类 Repository，用于选择数据泉源（本地或网络）。Repository 屏蔽了数据获取的具体实现细节，使上层代码只需关注数据本身，而无需关心其泉源和获取方式。
[*] 数据获取和存储交给Data Sources来做
https://i-blog.csdnimg.cn/direct/84e3ed3afca74ed9a0ff8175a4a8dfec.png
扩展：业务逻辑该在哪里做
假如是和UI界面相关的，比如简朴的表单数据格式验证、简朴数据的转换应该交给ViewModel做。
而存储数据的转换和账号暗码的服务器校验之类的业务逻辑应该交给Data Layer做。
项目实例
项目结构
联合上面的理论，给出项目的架构图。(泉源：《第一行代码》)
https://i-blog.csdnimg.cn/direct/03ee998e65bb461082957e294b9850e6.png
注意：只有上层才能拥有下层的引用，且不能跨层引用。
为了搭配MVVM架构，谷歌的JetPack提供了ViewModel类，来帮我们简化代码。 这里不睁开先容，简朴说一下：
1、ViewModel类的生命周期是Activity创建到Activity销毁之后。
2、ViewModel类可以存储和Acticity界面相关的数据。
3、ViewModel类搭配谷歌提供的LiveData类，可以实现 监控变量 的效果，一样平常是UI界面的更新。
代码实例
下面的代码可以清晰的看出，上层是怎样使用下一层的。不要关注实现细节，关注架构(注释)就好。
//1️⃣ View 层（UI 层）
class WeatherActivity : AppCompatActivity() {
//这里是UI层对ViewModel层的引用
val viewModel by lazy { ViewModelProvider(this).get(WeatherViewModel::class.java)}
override fun onCreate(savedInstanceState: Bundle?) {
......
//这里是viewMode中的LiveData提供的监测observe，这个数据变化时，UI界面会变化
viewModel.weatherLiveData.observe(this , Observer{result->
val weather = result.getOrNull()
if(weather != null){
showWeatherInfo(weather)
}else{
Toast.makeText(this,"无法成功获取天气信息",Toast.LENGTH_SHORT).show()
result.exceptionOrNull()?.printStackTrace()
}
})
....
}
//
页:
[1]