了解版本更新日志及下阶段目标，请看这里

[qingmei2]

更新日志

Update :2020/ 8/ 27

• 重构，分页库迁移到Paging3；
• 增加首页搜索功能页面；

感谢DaQinShgy对本次更新相关功能的贡献 🎉。

Update: 2020/ 7/ 3

• 重构，移除了 Kodein, 使用 Dagger-Hilt;
• 添加 Activity 和 Fragment 库。

Update: 2020/ 1/ 15

• 重构，添加了 Coroutine + Jetpack 对 MVVM 的实现方式；

现在项目采用了2种 MVVM 的实现方式，你可以参考任意感兴趣的进行了解：Jetpack + 协程 或者 Jetpack + RxJava 。

---

...
...
更多早期的更新日志都已经随风飘逝......

[qingmei2]

接下来的开发方向

考虑优先级从高到低,删除线表示已完成：

• 增加更多页面，扩展更多功能;
• 增加Paging3的使用示例；
• 提供 Jetpack + 协程 的实现方式
• 提供 Jetpack + RxJava 的实现方式
• 优化Room/Navigation/Paging的使用示例；
• 更新Login界面的逻辑；
• 移除DataBinding；
• 移除LiveData；

如果您有其它的建议，欢迎在本页面进行提出,我将在第一时间进行回复。 🤝

[TianGuisen]

求求大佬注释多写点,中文哈.

[quguangle]

为啥要移除liveData, 我觉得livedata挺好的， 如果把livedata的移除了，这个架构就失去了意义

[quguangle]

如果说把databinding去掉，那么mvvm会大打折扣

[qingmei2]

@quguangle

如果把livedata的移除了，这个架构就失去了意义

因为MVVM架构中，RxJava比LiveData更适合作为观察者模式的组件，LiveData唯一比RxJava的优势就是原生支持DataBinding，而如果移除了DataBinding，LiveData对于集成了RxJava依赖的项目来说意义不大，因此我决定在后面的版本中移除LiveData。

我们来看看Google官方的描述：

我们可以看到，无论是Room还是Paging等其它官方组件，Google官方还额外提供了RxJava响应式的额外原生支持，这本身就说明了Google对RxJava的肯定，如果RxJava作为三方库有缺陷或者说LiveData本身就比RxJava更优秀，Google有必要提供这样额外的支持吗？

参考dagger，其本身就是优秀的，但是Google依然不满意其反射带来的性能开销，而转身开发了一个dagger2，这也正是体现了Google某种精益求精的执拗。

因此，我完全有理由去站队RxJava，正如我所说的：

因为目前来看，离开了DataBinding,LiveData和RxJava相比没有任何优势。

---

2019/6/12 补充

我对自己学习的思路是，不断学习优秀的代码，保持对自己代码的怀疑，并督促自己对现有代码的优化。

我在日志中提出了 “离开DataBinding，LiveData毫无意义“，实际上在最近的学习中，我发现我的这个观点是片面、不成熟的，因为作为异步的实现思路之一， 协程 越来越成熟了，因此LiveData + 协程也是一个不错的MVVM的实现方式。

现在，我重新组织自己的语言，移除LiveData的原因应该是：因为项目中使用RxJava作为异步代码的组织者（而不是协程），因此暂时移除了LiveData。😃

[quguangle]

嗯，我没仔细看。MVI是啥？我还是第一次了解。 你这边对jetpack讲得挺好的

[quguangle]

我觉得如果mvvm没有了databinding，感觉这个框架就缺少很多。

[RoyGuanyu]

感謝，透過這個 Project 學到不少，期待未來版本。

[worldlk]

感谢作者，学到了很多东西，希望作者能改进一下网络请求：
1.添加cookie ，失败重试等
2.可不可以添加一下上传和下载的功能
毕竟网络请求是非常重要的，在整个app中。想学习一下！
谢谢！！！

[MhuiHugh]

DataBinding 还会加入进来吗？核心组件移除了，MVVM还有啥意义呢

[qingmei2]

@MhuiHugh

DataBinding 还会加入进来吗？

DataBinding已经被抛弃了，因此不考虑再加进来。

核心组件移除了，MVVM还有啥意义呢

MVVM代表的是一种思想，Google从来没有说过DataBinding是MVVM的核心组件，如果有更好的代替品（或者本身有严重的缺陷），当然要义无反顾的抛弃它。

[adoukei]

生命周期这一块，以后可能会麻烦些。 去掉DataBinding livedata以后 这个生命周期可能会受什么影响 比如？

[qingmei2]

@adoukei

生命周期这一块，以后可能会麻烦些。 去掉DataBinding livedata以后 这个生命周期可能会受什么影响 比如？

生命周期相关的是Lifecycle组件，去掉DataBinding livedata对生命周期不会有任何影响的。

[adoukei]

@adoukei

生命周期这一块，以后可能会麻烦些。 去掉DataBinding livedata以后 这个生命周期可能会受什么影响 比如？

生命周期相关的是Lifecycle组件，去掉DataBinding livedata对生命周期不会有任何影响的。

见笑了，那么 还能做到数据驱动UI吗？看代码 还是通过找到相应的id设置属性或者值。

[qingmei2]

@adoukei

见笑了，那么 还能做到数据驱动UI吗？看代码 还是通过找到相应的id设置属性或者值。

嗯，这个应该是不同的人有不同的理解，对于 数据驱动UI，我的理解是—— View观察唯一数据源的变更，并进行对应的更新。

对于DataBinding，View观察LiveData内，并仅根据唯一的这个LiveData进行UI自动更新，所以说，LiveData内的这个数据，驱动了UI的更新——DataBinding只是把更新的逻辑写在了xml里面，实际上本质仍然是编译器生成java代码对UI更新的，这个和我们直接在Activity中进行更新，是一样的。

需要理解的是，“驱动”一词的关键在于 观察者模式 和 唯一的数据源，因此重点在于 LiveData （我也说过了RxJava更强大，完全有能力替代前者），而不是DataBinding。

个人观点，欢迎讨论哈。

[williamwue]

之前一直在使用RxJava，最近在项目中使用了databinding+livedata，实践中也遇到了一些问题，虽然最终都找到办法解决了，但是总感觉不是最佳实践的方式，看到你上面的解答，发现确实RxJava能处理应付的场景还是要多很多，正如Google官方解释的那样，已经上手RxJava的开发者，继续使用RxJava会是更好的选择

[qingmei2]

之前一直在使用RxJava，最近在项目中使用了databinding+livedata，实践中也遇到了一些问题，虽然最终都找到办法解决了，但是总感觉不是最佳实践的方式，看到你上面的解答，发现确实RxJava能处理应付的场景还是要多很多，正如Google官方解释的那样，已经上手RxJava的开发者，继续使用RxJava会是更好的选择

@williamwue

如果您已经习惯了RxJava的思想，RxJava毫无疑问是项目中代码组织的强有力武器，但是坦诚的说，协程确实学习成本更低、对于不熟悉RxJava的开发者而言 协程 代码可读性也更强，因此 协程 也是一个不错的选择。

感谢你的回复，我已经将我最新的理解在 6楼进行了补充更新，开发者应该根据自身情况选择合适自己的工具。 🤝

[williamwue]

之前一直在使用RxJava，最近在项目中使用了databinding+livedata，实践中也遇到了一些问题，虽然最终都找到办法解决了，但是总感觉不是最佳实践的方式，看到你上面的解答，发现确实RxJava能处理应付的场景还是要多很多，正如Google官方解释的那样，已经上手RxJava的开发者，继续使用RxJava会是更好的选择

@williamwue

如果您已经习惯了RxJava的思想，RxJava毫无疑问是项目中代码组织的强有力武器，但是坦诚的说，协程确实学习成本更低、对于不熟悉RxJava的开发者而言 协程 代码可读性也更强，因此 协程 也是一个不错的选择。

感谢你的回复，我已经将我最新的理解在 6楼进行了补充更新，开发者应该根据自身情况选择合适自己的工具。 🤝

赞同你的看法，我也在关注协程的发展，其目前也越来越稳定，非常期待能在这个项目中看到你对livedata+协程的实践探索 😊

[nEdAy]

是否有计划更新下retrofit2.6.0对suspend的支持？

[qingmei2]

是否有计划更新下retrofit2.6.0对suspend的支持？

协程很不错，但是现有的框架中已经有了RxJava，我个人认为RxJava比协程更优秀，目前为止，协程能实现的功能RxJava都能实现，反之则不行，因此我暂时不会考虑使用它。

[luciferChou]

请问一下，每一个Model里面的ModelFactory相关代码都是手写的么。还是用模板写的呀

[qingmei2]

请问一下，每一个Model里面的ModelFactory相关代码都是手写的么。还是用模板写的呀

@luciferChou

模版手写都可以，模版已经配置好了：

https://github.com/qingmei2/MVVM-Rhine-Template/blob/master/MVVMFrgTemplate/root/src/app_package/BasicFragmentViewModel.kt.ftl

[wuao]

你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情：
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 ：
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;

rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ，最后我发觉协程确实可以解决很多问题 。

[williamwue]

你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情：
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 ：
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;

rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ，最后我发觉协程确实可以解决很多问题 。

rx适合多任务处理的场景，看业务需求，一般项目里协程就能解决的场景可能要多些，我觉得可以尝试两者搭配着来

[qingmei2]

@wuao

跨组件通讯我也不会优先考虑类似RxBus,EventBus或者LiveDataBus，这些在我看来其实就是对Android机制本身的不熟悉，不说ViewModel这些组件和类似Bundle、startActivityForResult这些原生的API，原生提供的AIDL甚至可以进行跨进程通讯。

消息机制的可选择性很多，而类似EventBus虽然便于上手，但是很容易造成滥用。比如你所说的：

一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略

其实这一点我觉得应该还是可以优化的，毕竟极少有页面真的需要注册这么多观察者。

如果使用了多Module构建的项目，使用EventBus没有什么问题，但是我个人认为，越是业务复杂的项目，类似dagger的依赖注入系统意义越大。

---

综上所述，你说的都是三方库上的问题，我的观点是，涉及三方库的选型的问题就不是问题，因为每个人都有不同的理解，这个看个人爱好就可以了。

另外，从思想上来说，我认为RxJava和协程都是非常优秀的异步处理组件，选哪个都无不可，但是同时使用，那就没必要了。

[kefengxw]

支持你去掉databinding，除了bug的问题外，其实以下这些方面也是考虑的因素：后期代码维护，热补丁，app的编译大小，闪退快速定位等等，都是datebinding可能存在的潜在的风险；

[leobert-lan]

首先表达对楼主开源和务实精神的支持，这里谈一谈我对于楼主livedata和RxJava观点的看法，livedata是Google提供的一个套件，体现了Google在处理响应式变更上的思路，相比于一般的响应式UI体系，Android需要考虑自身的生命周期问题，livedata将这些内容都做了封装，可以认为官方指导了一下在Android上应该如何去做响应式数据封装。而RxJava最开始的意图是优雅的处理异步问题，随着在创建响应式业务模型的问题上（简而言之是创建特定的数据流变化和相关事件订阅）体现出优势，被广大开发者接受并推广，Google15年推出databinding，随后才逐步推出JetPack中的各种套件，当时RxJava（RxAndroid）已经广泛使用了，所以Google认可他并提供相关的扩展是正常的。 当然，用任何的异步处理框架去实现响应式数据都是可以的，我记忆中Google推出jetPack时提到过，有很多用户抱怨Google没有像Apple在iOS的生态中那样，为开发者提供各种成熟的开箱可用的套件，大多数都是靠社区和广大开发者维护，所以Google痛定思痛决定对自家人好点，也弄点东西给大家用用。

而databinding呢，他的设计理念是为了让写响应式UI设计更简单一点，并不利于View的复用。

[KunMinX]

@qingmei2
刚刚在掘金看到作者这篇文章，大赞，尤其是文中对 数据驱动 UI 和 RxJava 的本质的精确描述。

事实上，数据驱动 UI 和 RxJava 都属于函数式编程的应用，函数式编程主要是为了解决 过程的一致性问题，也即，只有一个入口，只有一个出口，过程不被外界从旁干预，也不对外产生副作用。

DataBinding 本质上是一个外挂，它不是一个强约束的框架，没有彻底迫使 原视图系统 贯彻函数式编程的思想，使得视图树在构建后，仍然可以通过 mBinding 拿到视图实例。

但只要理解了函数式编程思想的目的 —— 解决过程的一致性问题，就能恰到好处地使用 DataBinding。

数据驱动 UI 框架，在解决 视图调用 的一致性问题 上，是不可替代的，比如 “横竖屏布局控件存在差异” 这种情况，以往需要手动判空来解决 null 安全问题，但手动判空并不可靠，因为视图实例一旦能在 Activity 中拿到，就会不受控制地遍布在各种方法中，也即这个方法判空了，另外的方法却可能疏忽。

而目前来说，只有 DataBinding 能妥善解决这个问题 —— 通过数据来驱动 —— 视图在？那么就能被绑定到的数据驱动；视图不在？ok 没问题，啥事也没有，不会有视图调用的 null 安全问题。

所以个人认为，从软工安全角度来看，DataBinding 的存在有其不可替代的因素，仍然值得存在于 MVVM 架构中。唯一可与之竞争的，只有更加纯粹和强约束的数据驱动框架：Jetpack Compose。

[tickboxs]

DataBinding的一些思考
我使用过的MVVM
1.Web端 Angular+RxJS 算是强制吧UI数据绑定代码写在HTML里面 类似于 data binding
2.iOS端 Swift + RxSwift,目前是UI数据绑定代码写在Controller里面的,可能未来SwiftUI成熟了 支持在SwiftUI界面布局代码里面直接写UI数据绑定代码吧
3.Xamarin.Form C#+原生响应代码 Xamarin.Form是原生支持MVVM的 和databinding 类似 UI数据绑定的代码是强制写在XML布局代码里面的

所以 我觉得就是2个方案 一个是UI数据绑定代码写在布局文件XML里面。另一个方案是在代码里面获取UI的reference，然后在代码里面进行UI和数据的绑定。我觉得两种都可以把，具体看个人喜好

[chengxinping]

不知道什么时候能看到大佬的databinding+livedata+协程版本

[qingmei2]

不知道什么时候能看到大佬的databinding+livedata+协程版本

LiveData+Coroutine 版本已经出来了呀，databinding的话应该不会加进去了，不过这个组件比较独立，添加起来很方便，直接在xml中使用ViewModel的LiveData属性就可以了。

[DongDian455]

移除DataBinding 的原因是？

[qingmei2]

移除DataBinding 的原因是？

@DongDian455

对于大体量的项目而言，DataBinding的「魔法糖」是毒药（我觉得魔法糖比语法糖更适合形容它）。

对此，你可以参考南尘的 这篇文章， 随着业务复杂度的指数级上升，DataBinding最终会成为限制项目架构的瓶颈，同时多人开发模式下也会面临滥用的问题。

[nEdAy]

Databinding XML里逻辑IDE没什么检查提示，逻辑很难找不喜欢
Butterknife 模块化 R2 问题，还有编译期生成类IDE查找时候不喜欢

还是kotlinx，真香

[cyixlq]

有个小问题想请教一下大佬，为什么_stateLiveData每次post的时候都使用copy而不直接创建一个新的对象，不改变的值使用默认值

[monkeydone]

@quguangle

如果把livedata的移除了，这个架构就失去了意义

因为MVVM架构中，RxJava比LiveData更适合作为观察者模式的组件，LiveData唯一比RxJava的优势就是原生支持DataBinding，而如果移除了DataBinding，LiveData对于集成了RxJava依赖的项目来说意义不大，因此我决定在后面的版本中移除LiveData。

我们来看看Google官方的描述：

我们可以看到，无论是Room还是Paging等其它官方组件，Google官方还额外提供了RxJava响应式的额外原生支持，这本身就说明了Google对RxJava的肯定，如果RxJava作为三方库有缺陷或者说LiveData本身就比RxJava更优秀，Google有必要提供这样额外的支持吗？

参考dagger，其本身就是优秀的，但是Google依然不满意其反射带来的性能开销，而转身开发了一个dagger2，这也正是体现了Google某种精益求精的执拗。

因此，我完全有理由去站队RxJava，正如我所说的：

因为目前来看，离开了DataBinding,LiveData和RxJava相比没有任何优势。

2019/6/12 补充

我对自己学习的思路是，不断学习优秀的代码，保持对自己代码的怀疑，并督促自己对现有代码的优化。

我在日志中提出了 “离开DataBinding，LiveData毫无意义“，实际上在最近的学习中，我发现我的这个观点是片面、不成熟的，因为作为异步的实现思路之一， 协程 越来越成熟了，因此LiveData + 协程也是一个不错的MVVM的实现方式。

现在，我重新组织自己的语言，移除LiveData的原因应该是：因为项目中使用RxJava作为异步代码的组织者（而不是协程），因此暂时移除了LiveData。😃

liveData最重要的其实是生命周期.使用他可以减少太多内存泄漏了

[walkthehorizon]

不知道楼主是否有关注最新的compose Ui，我越来越坚定的认为目前的什么基于Activity的开发方式后面都会被干掉，转而走向与React、Vue一样响应式的组件化开发，mvvm这一套也注定是一个时期过渡品，在接触了Web的开发之后，我发现app的开发思路很多都是从web借鉴过来的，目前React和Vue的开发(Flutter同)方式真的非常优越

[walkthehorizon]

你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情：
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 ：
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;

rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ，最后我发觉协程确实可以解决很多问题 。

你好 最近的 一些思考 希望能一起交流
我目前的框架改造成这样
1 rxandroid +okhttp =负责获取数据 同时 负责监听view生命周期 在销毁的时候 不会发出请求
2 用携程的AutoDispose 解决rx 的泄漏问题
3 然后在自己的viewmodel 做了以下事情：
1 首先按照页面或者 功能模块来划分 职责 比如首页 HomeViewModel 会员 MermViewModel
2 最开始 我的viewmodel 就是一个普通的类
3 用于功能的函数入参和调用 比如login 同时我 在接受回来的参数的采用了消息机制来进行数据的更新通知 之前是用的evenbus 现在采用 liveeventBus 有点类似 livedata 的角色功能 但是不仅仅是
因为我有时候需要跨组件进行通知
4 因为用了databing 的原因 我还在viewmodel 里面封装了一些参数的改造和逻辑的处理 。但是我是在页面上接受到参数 在去调用 viewmodel 的DataChange() 然后返回处理进行databing 的set
5 如果我的viewmodel 真的要做数据的持有我大可不必用官方的
4 一些问题 ：
1 不管是 什么消息的发送 传递数据 那么页面上不可避免的会在view 上进行很多注册接受消息的地方
目前我有一个页面 写了8个消息注册和处理 用的是eventbus 感觉不好 但是这部分代码又无法省略
2 databing 没有想象的那么强大和好 他只是帮你省略了一些工作我感觉 比如在控件上的显示隐藏 我会引入工具类 来进行判断 和settext 背景 样式 但是如果说我需要根据不同的状态显示不通的图片 你只能吧这个代码写到view 里面 然后如果你用只能用3元表达式进行一些比较简单的判断 其他的 我暂时我还没感受到
3 至于其他的 RxPermissions 感觉还是不错 rxbin 感觉有点不能满足需求
4 至于dagge2 我目前看不到他有很大的必要使用在我的项目 ;
rx 的就感觉像Promise 很像 一个一个任务的数据流水线的去执行 也可以任务失败就终止 ，最后我发觉协程确实可以解决很多问题 。

rx适合多任务处理的场景，看业务需求，一般项目里协程就能解决的场景可能要多些，我觉得可以尝试两者搭配着来

dagger是为了减少模板代码，以及方便测试用的
rx的线程切换只是基操，好用的地方还是各种操作符，写成简单易用，但是你要做个比如500ms内最新的一次搜索，你想想用协程好做么，要写多少样板