10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发

从 API 1 开始,处理 Activity 的生命周期 (lifecycle) 就是个老大难的问题,基本上开发者们都看过这两张生命周期流程图:

10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发_第1张图片

随着 Fragment 的加入,这个问题也变得更加复杂:

10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发_第2张图片

而开发者们面对这个挑战,给出了非常稳健的解决方案: 分层架构。

分层架构

10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发_第3张图片

如上图所示,通过将应用分为三层,现在只有最上面的 Presentation 层 (以前叫 UI 层) 才知道生命周期的细节,而应用的其他部分则可以安全地忽略掉它。

而在 Presentation 层内部也有进一步的解决方案: 让一个对象可以在 Activity 和 Fragment 被销毁、重新创建时依然留存,这个对象就是架构组件的 ViewModel 类。下面让我们详细看看 ViewModel 工作的细节。

10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发_第4张图片

如上图,当一个视图 (View) 被创建,它有对应的 ViewModel 的引用地址 (注意 ViewModel 并没有 View 的引用地址)。ViewModel 会暴露出若干个 LiveData,视图会通过数据绑定或者手动订阅的方式来观察这些 LiveData。

当设备配置改变时 (比如屏幕发生旋转),之前的 View 被销毁,新的 View 被创建:

10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发_第5张图片

这时新的 View 会重新订阅 ViewModel 里的 LiveData,而 ViewModel 对这个变化的过程完全不知情。10分钟带你搞懂协程、LiveData-和-Flow,kotlin协程并发_第6张图片

归根到底,开发者在执行一个操作时,需要认真选择好这个操作的作用域 (scope)。这取决于这个操作具体是做什么,以及它的内容是否需要贯穿整个屏幕内容的生命周期。比如通过网络获取一些数据,或者是在绘图界面中计算一段曲线的控制锚点࿰

你可能感兴趣的:(程序员,架构,移动开发,android)