chuyouyinghe的专栏

是 Android 提供的一种编译时生成类的机制，用于更高效地绑定 XML 布局文件中的视图。通过，开发者可以在编译时生成与 XML 布局文件对应的绑定类，避免了手动查找视图的操作，提升了代码的安全性和可维护性。为 Android 开发者提供了一种高效、安全的方式来处理 UI 绑定，避免了手动查找视图带来的麻烦。它特别适合需要快速开发、简化代码的场景，能有效提升开发体验。在实际开发中，如果你不需要复杂的数据绑定功能，是一个理想的选择。通过它，你可以写出更简洁、可维护的代码。

定义一个ViewModel，让这两个Activity去共享这个ViewModel

PS：知道kotlin的可以跳过这段，往下看Kotlin是一种静态类型的编程语言，由JetBrains开发，可运行于Java虚拟机（JVM）上。它被设计为在Java开发环境中的替代语言，具有现代化的特性和语法。Kotlin具有许多优点，包括更简洁的语法、空安全、函数式编程支持、扩展函数、类型推断和智能转换等。它还提供了一些有用的工具和库，帮助开发者提高生产力。Kotlin与Java可以无缝地互操作，因此可以与现有的Java代码库和框架集成。

这里采用难度系数最大的 6颗星难度来架构项目架构模式：采用自研全动态插件化框架进行插件化部署项目内部架构：采用 Kotlin 语言编写，架构选用 MVVM 代码架构模式，联合使用JetpackRoomLifecyleLiveDataViewModel，等项目网络封装：采用协程 +FlowRetrofitOkHttp项目图片加载：采用谷歌开源Glide图片加载框架项目音乐视频：采用谷歌开源Exoplayer框架进行视频播放，音乐播放项目数据库：使用官方Jetpack中组件Room数据库。

例如我们的 Activity/Fragment 内部的对象初始化，如果是常规的通用的对象初始化，我们当然可以在基类中就定义了。但是对于一些类似ViewModel，ViewBindig之类的对象初始化，我们需要明确知道是哪一个类型才能初始化的怎么办？这样会报错的，因为运行期间泛型会被擦除也无法实例化对应的对象。那...可如何是好呐。

之前的 MVI 架构一文中，有小伙伴会有疑问，为什么要用这个Flow，能不能平替其他的 Flow。其实在 MVI 的封装中，每一种 Flow 都用到了，特别适合对比学习各种 Flow 的各种特性。我们直接先上代码，然后再一一讲解区别。代码很清晰，注释很详细，接下来我们就看看他们的区别。

如果说Android开发其他组件都有的选，例如Flow与LiveData、Room与GreenDao等，但是ViewModel是我们现在Android开发必不可少的一环，对比其他平台如鸿蒙或Flutter的控制器那是真YYLX。今天我们会简单的回顾一下ViewModel的重要知识点，复习ViewModel的创建销毁流程，本文的重点是ViewModel的各种创建方式包括Hilt的创建方式，为什么那么简单，到底是什么魔法。

Shared ViewModel 在Android应用中在不同组件之间共享数据是一个常见的需求。使用ViewModels是实现这一点的有效方式。在这个指南中，我们将探索在Android中创建SharedViewModel的各种方法。

1、减少代码量：使用数据绑定可以减少代码量，因为不需要手动更新UI，而是通过数据的变化自动更新UI。2、提高开发效率：数据绑定可以提高开发效率，因为不需要手动更新UI，开发人员可以更快地完成开发任务。3、降低出错率：使用数据绑定可以降低出错率，因为不需要手动更新UI，减少了手动操作的机会，从而减少了出错的可能性。4、提高代码可读性：使用数据绑定可以提高代码可读性，因为数据绑定可以将UI和数据分离，使代码更加清晰易懂。

到这里关于 Kotlin Flow 在 MVVM 当中每层的实践就分析完了，如果使用过 RxJava 的小伙伴们应该会非常熟悉，对于没有使用过 RxJava 的小伙伴们，入门的门槛也是非常低的，强烈建议至少体验一次，体验过之后，我认为你会跟我一样爱上它的。Flow 是协程的扩展，如果要在 Room 和 Retrofit 中使用，Room 和 Retrofit 需要支持协程才可以，在。文章也有提到， 这里我们在深入分析一下，在 ViewModel 中接受 Flow 发送的数据有三种方法，根据实际情况去调用。

在最近的Android开发中,主流推送慢慢从Java→Kotlin,LifeData→Flow.那里面各有各的好处,也都是为了解决不同应用场景给出不同的方案。但是在使用官方推荐的ViewModel+Flow时,会有很多需要解决的细节,里面也会牵涉到比较多的知识点。所以这个文章就是将自己学习到的东西进行总结.此文章会涉及到的知识点会比较多包括:kotlin扩展函数kotlin高阶函数kotlin内联函数Flow的使用。

在Android应用中，ViewModel是一种设计模式，用于管理UI相关的数据和业务逻辑。它主要解决了由生命周期引起的数据丢失、内存泄漏和重复加载数据等问题。ViewModel的设计思想是将UI和数据分开，使得数据在配置更改、Activity或Fragment销毁重建等情况下能够持久保留。ViewModel的主要作用是存储和管理与UI相关的数据，如界面元素的状态、用户输入等。通过ViewModel，我们可以在不同的配置更改和生命周期事件之间保持数据的一致性，避免了重新加载数据带来的性能问题和用户体验下降。

binding.isLogin = UserManager.isLogin()通过binding将isLogin的值设置到xml中isLogin来接收登录状态通过判断登录状态来确定是否显示View。

注意：如果采取映射，并且view中已绑定了，那我们在onBindViewHolder中不要再通过代码去设置，这样会导致recycleview不滑动，view虽然绘制，但是databind默认加载是空数据，这样就会导致是空白，只有滑动可见后，通过我们手动设置的数据取填充。在get方法修饰，用于双方绑定，该注解用于标记实体类中的get方法或“is”开头的方法，会通过Bindable在BR中生成对应的fieldId(Int 型)，如果未绑定，将无法生成，生成后便于。在绑定数据这边有两种。

这是一个比较广义的架构模式，有着非常广泛的应用，在大型软件系统设计，开源框架的设计中都非常常见。ViewModel都会配合LiveData来使用，ShareViewModel一般用于页面间通信，发送更全局的事件，生命周期更长，而StateViewModel一般管理页面内的状态，分担Activity和Fragment的压力，设置不同作用域的ViewModel，比如可以分开拿Activity和Fragment的ViewModel对象，作用域范围是不同，也可以更好的避免内存泄露。

层中的方法来实现，还是需要一系列复杂操作，有没有什么机制自动去更新视图而不用我们手动去更新呢，所以，层相互持有、相互操作，导致紧密耦合，在可维护性上有待提升。层不部署业务逻辑，除了展示数据和触发事件之外，其它时间都在等着。层经过对事件的处理完成相关业务逻辑，要求。层采用双向绑定的形式（Binding），框架，可见这些模式的划分也不是那么严格。层来更新自己，被称为「被动视图」。模式将程序分为三个部分：模型（在实际操作时，用户可以直接对。在实际操作时，用户可以直接对。层也被隔离开，彻底解耦，

Presenter作为View和Model之间的“中间人”，除了基本的业务逻辑外，还有大量代码需要对从View到Model和从Model到View的数据进行“手动同步”，这样Presenter显得很重，维护起来会比较困难。除非客户端再次发起请求，否则服务器端的Model的变更就无法告知客户端。虽然在MVC里，View是可以直接访问Model的，但MVP中的View并不能直接使用Model，而是通过为Presenter提供接口，让Presenter去更新Model，再通过观察者模式更新View。

上文提到的 “粘性观察者”，对应的是 BehaviorSubject 实现，强调 “总是有一个状态”，比如门要么是开着，要么是关着，门在订阅 BehaviorSubject 时，会被自动回推最后一次 State 来反映状态。常见 BehaviorSubject 实现有 ObservableField、LiveData、StateFlow 等。反之是 PublishSubject 实现，对应的是一次性事件，常见 PublishSubject 实现有 SharedFlow 等。

MVI并非新兴事物，在2020年时亦曾有通过撰写一篇文章与诸位读者探讨一二的念头。当时项目采用MVP分层设计，组员的代码风格差异也较大，代码中类职责赋予与封装风格各成一套，随着业务急速膨胀，代码越发混乱。试图用MVI架构+单向流形成掣肘带来一致风格。但这种做法不够以人为本，最终采用"在MVP的基础上进行了适当改造+设计约定的方式"解决了问题，并未将MVI投入到商业项目中，于是放弃了纸上谈兵。在半年前终于有机会在商业项目中进行实践，同诸位谈一谈使用后的个人感悟，并藉此讲透MVI等架构。

引子MVI 是Model-View-Intent的简称，它们分别表示。。。。。我并不打算逐个字母介绍它们代表的意思。因为这样一点也不能增进对 MVI 的理解，反而会对它的认识蒙上厚厚的一层迷雾。奥古斯都在《忏悔录》里面问我这样一个问题：“时间到底是什么？你不问我的时候，我是知道的；你一问我，我就不知道了。”把“时间”换成“MVI”，这个问题同样困扰着我：“MVI 到底是什么？你不问我的时候，我是知道的；你一问我，我就不知道了。”维特根斯坦会说，上面是一个非法的问题，源于错误地使用了语言

最近铺天盖地的看到Android MVI模式的文章。MVVM还没捂热，什么时候又来了个MVI？我们android开发这么卷吗？到底是谁在卷？MVI模式被造出来是为了解决什么问题的？ 我们要不要学MVI模式，项目中要不要用起来？android官方真的推荐用MVI模式？MVI和MVVM有什么区别？我们该应该如何学习MVI架构模式？MVI学习路线建议。带着这些疑问，大叔逐个找到了答案。于是持续很多天“吐血整理”，希望对学习MVI的小伙伴有所帮助~嘿嘿~ 为大叔的辛苦整理，看完点个赞，.

1前言前段时间写了一些介绍MVI架构的文章，不过软件开发上没有最好的架构，只有最合适的架构，同时众所周知，Google推荐的是MVVM架构。相信很多人都会有疑问，我为什么不使用官方推荐的MVVM，而要用你说的这个什么MVI架构呢？不过我这几天查看Android的应用架构指南，发现谷歌推荐的最佳实践已经变成了单向数据流动 + 状态集中管理，这不就是MVI架构吗？看起来Google已经开始推荐使用MVI架构了，大家也有必要开始了解一下Android应用架构指南的最新版本了~本文主要基

前言Android开发发展到今天已经相当成熟了，各种架构大家也都耳熟能详，如MVC,MVP,MVVM等，其中MVVM更是被官方推荐，成为Android开发中的显学。不过软件开发中没有银弹，MVVM架构也不是尽善尽美的，在使用过程中也会有一些不太方便之处，而MVI可以很好的解决一部分MVVM的痛点。本文主要包括以下内容MVC,MVP,MVVM等经典架构介绍 MVI架构到底是什么? MVI架构实战需要重点指出的是,标题中说MVI架构是MVVM的进阶版是指MVI在MVVM非常相似，并在其基..

如果 ViewModel 中要用到 context 怎么办呢？没关系，框架提供了一个 ViewModel 的子类 AndroidViewModel ，它在构造时需要传入 Application 实例。既然 ViewModel 与 UI Controller 无关，当然可以用作 MVP 的 Presenter 层提供 LiveData 给 View 层，因为 LiveData 绑定了 Lifecycle，所以不存在内存泄露的问题。除此之外，ViewModel 也可以用做 MVVM 模式的 VM 层，利用

RecyclerView+Databinding最佳实践????Hello大家好，这里是码上夏雨，一名安卓初学者，也会定期给大家带来自己的学习心得????????这次带给大家的是安卓架构组件的数据绑定库方面的内容，如果你对此感兴趣也可以查看官方文档数据绑定库????????那事不宜迟，我们现在就发车????添加DataBinding支持要将应用配置为使用数据绑定，请在应用模块的 build.gradle 文件中添加 dataBinding 元素，如以下示例所示：//开启dataBindin

这一章，为大家带来利用Data Binding为RecyclerView填充数据。这里的难点和核心点就是RecyclerView中Adapter的实现。这里以RecyclerView多布局的情况来讲解。1、一般情况下，我们RecyclerView多布局的Adapter大致如下public class MultiItemAdapter extends BaseBindRecyclerViewAdapter<IBaseBindingAdapterBean> { pub

为什么要使用DataBinding在不支援DataBinding之前，数据和UI间的更新需要依靠findViewById(), setText(), setVisibility(), setEnabled()等，稍微复杂的UI会充斥大量的毫无营养的代码；通过DataBinding，可以使用声明式布局以及精简的代码来绑定应用程序逻辑和布局。DataBinding基础1. 让Module支援DataBinding在Module的build.gradle中支援DataBindinga

前言前面一章和大家简单的讲解了 Kotlin 中的变量、方法以及对象声明的定义，今天呢，就和大家讲讲 Kotlin 中的 DataBinding 的使用。 KotlinTest Github:添加 DataBinding 依赖 在我之前的文章里就有说过如何在项目中使用 DataBinding，当然了，那是在 Java 语言开发中，要是使用 Kotlin 开发的话，还是有所区别的。不了解的可以看看我之前的 Android项目基本架构（四） DataBinding 如果使用 Java .

前言打开Android架构组件页面,我们可以发现一些最新发布的jetpack组件，如Room，DataStore, Paging3,DataBinding 等都支持了FlowGoogle开发者账号最近也发布了几篇使用Flow的文章，比如：从 LiveData 迁移到 Kotlin 数据流看起来官方在大力推荐使用Flow取代LiveData，那么问题来了,有必要吗？我LiveData用得好好的，有必要再学Flow吗?本文主要回答这个问题,具体包括以下内容1.LiveData有什么不足?2.Flow

本系列将分享那些 AAC 中常见的错误用法，以帮助大家打造更健康的应用架构。1Fragment 作为 LifecycleOwner 的问题MVVM 的核心是数据驱动UI，在 Jetpack 中，这一思想体现在以下场景：Fragment 通过订阅 ViewModel 中的 LiveData 以驱动自身 UI 的更新。关于订阅的时机，一般会选择放到onViewCreated中进行，如下：overridefunonViewCreated(view:View,s...

遇到的问题最近在学习LiveData和ViewModel，跟着官网敲，碰到了以下情况private val model: NameViewModel by viewModels()这里的viewModels()爆红已经添加的依赖如下implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.0'implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2

前言上一篇简单的介绍了DataBinding的用法，这几篇来仔细的介绍一下的功能。data 标签 的功能<data class="test"></data>class 属性生成指定的名称的Binding对象。什么是Bind对象呢?来回顾之前的一句代码ViewDataBinding mBinder = DataBindingUtil.setContentView(this, R.layout.activity_main);通过这一句，系统会自动帮助我们生

ViewModel 是什么？ViewModel 是 Jetpack 的一部分。ViewModel 类旨在以注重生命周期的方式存储和管理界面相关的数据。ViewModel 类让数据可在发生屏幕旋转等配置更改后继续留存。摘自官方文档：ViewModel 概览ViewModel 相关问题是高频面试题。主要源于它是 MVVM 架构模式的重要组件，并且它可以在因配置更改导致页面销毁重建时依然保留 ViewModel 实例。看看 ViewModel 的生命周期ViewModel 只有在正常 Act

1.MVVM模式分为Model，View，ViewModel 三个部分(1).Model:数据层，包含数据实体和对数据实体的操作(2).View:界面层，对应于Activity，XML,View，负责数据显示以及用户交互。(3).ViewModel：关联层，将Model和View进行绑定，Model或者View更改时，实时刷新对方。注意点1.View只做和UI相关的工作，不涉及任何业务逻辑，不涉及操作数据，不处理数据。UI和数据严格的分开2.ViewModel只做和业务逻辑相关的工作，不涉

前言在之前分享过一篇 Jetpack 综合实战应用 神奇宝贝(PokemonGo) 眼前一亮的 Jetpack + MVVM 极简实战 ，这个项目主要包了以下功能：自定义 RemoteMediator 实现 network + db 的混合使用 ( RemoteMediator 是 Paging3 当中重要成员 ) 使用 Data Mapper 分离数据源 和 UI Kotlin Flow 结合 Retrofit2 + Room 的混合使用 Kotlin Flow 与 LiveData 的使用

文章目录前景回顾事件绑定整体思路拓展运行效果前景回顾Android 安卓DataBinding（一）·基础Android 安卓DataBinding（二）·入门Android 安卓DataBinding（三）·单向绑定 BaseObservableAndroid 安卓DataBinding（四）·单向绑定 ObservableFieldAndroid 安卓DataBinding（五）·单向绑定 ObservableCollection（集合使用）Android 安卓DataBindi

文章目录前景回顾双向绑定新的数据源（Bean）布局文件（activity_main.xml）MainActivity.java总结前景回顾Android 安卓DataBinding（一）·基础Android 安卓DataBinding（二）·入门Android 安卓DataBinding（三）·单向绑定 BaseObservableAndroid 安卓DataBinding（四）·单向绑定 ObservableFieldAndroid 安卓DataBinding（五）·单向绑定 Ob

文章目录前景回顾单向绑定ObservableMapObservableMap 运行效果ObservableListObservableList 运行效果更新UI更新UI运行效果前景回顾Android 安卓DataBinding（一）·基础Android 安卓DataBinding（二）·入门Android 安卓DataBinding（三）·单向绑定 BaseObservableAndroid 安卓DataBinding（四）·单向绑定 ObservableField上一期讲到

文章目录前景回顾单向绑定ObservableField运行效果前景回顾Android 安卓DataBinding（一）·基础Android 安卓DataBinding（二）·入门Android 安卓DataBinding（三）·单向绑定 BaseObservable上一期讲到 BaseObservable 单向绑定，在中间又要写注解，又要加注解，然后还得用 notifyPropertyChanged(); 和 notifyChange(); 进行刷新。这样整体下来是比较麻烦的，所以，可以

文章目录前景回顾单向绑定BaseObservableBean类继承BaseObservable布局文件运行效果前景回顾Android 安卓DataBinding（一）·基础Android 安卓DataBinding（二）·入门在上文中讲到，通过DataBinding进行绑定控件以及进行相关操作，但是，这遇到了一个瓶颈，就比如绑定的变量发生变化的时候，每次都要重新向 ViewDataBinding 传值进行更新操作之后才能刷新UI。那么怎么就能自动刷新UI了呢？那就得用 单向绑定 了！