Android单向数据流——Side Effect
前言
背景知识：
Android单向数据流——MvRx核心源码解析
Unidirectional data flow on Android using Kotlin
本文讨论一个问题，Android单向数据流中的Side Effect（副作用），看看MvRx是如何实现Side Effect的，经典的单向数据流Redux又是如何实现Side Effect的？为什么说MvRx是简化的Redux，MvRx又有哪些问题呢？
Side Effect
什么是Side Effect？我们知道，单向数据流的核心是StateStore中的Reducer，Reducer负责根据接收到的Event/Action/Intent/Wish，别管怎么叫吧，总之根据接收到的数据以及当前的State生成一个新的State，这样才能驱动整个单向数据流流动起来。
这里有两层隐藏的含义：
- State必须是“不可变”（Immutable）的
- Reducer执行的函数必须是“纯函数”（pure function）
如果State是可变的，那么我们很可能无意间就直接修改了State，那么新旧State也就无从对比，这会降低State的传输效率；更关键的一点是，这会引起多线程修改State的并发问题，大大增加State管理的复杂度。
如果Reducer执行的函数不是纯函数，也就是说这些函数带有副作用，那么单向数据流就无从谈起了，我们可以通过“副作用”去修改State，Reducer还有什么存在的意义。
所以说，“不可变性”和“纯函数”是Reducer的应有之意。
Reducer体现的其实就是函数式编程的思想，但是函数式编程总是要解决的一个问题就是如何处理“副作用”。“副作用”是无处不在的，典型的副作用就是IO操作（文件读写、数据库操作、网络请求），显然这些都是避免不了的，函数式编程给出的方案是，将“副作用”打包成函数去执行。
我们不去管这些概念，来看看单向数据流中的副作用如何处理。理想状态下，Action1会生成State1，Action2会生成State2，没有副作用，但这是不可能的，假设Action1是网络请求，Action2是数据库查询，Action1、Action2都是无法直接执行的，但是我们可以这么做，Action1触发Side Effect1，Action2触发Side Effect2，Side Effect1/2去执行这些副作用，执行结束后，返回Action1'，Action2'，这时候Action1'，Action2'就是纯函数了，可以在Reducer中继续执行。
以上就是典型的Redux单向数据流的流程，总结起来就是，只有Action可以改变State，而Action可能会触发Side Effect，Side Effect执行完成后再次发送Action到Reducer。
MvRx Side Effect
Side Effect被称为副作用有点名不符实了，对于Reducer而言的确是Side Effect，但对于业务逻辑而言，这些Side Effect才是真正的“作用”，而Reducer中进行的State更新才是所谓的“副作用”。Side Effect（例如网络请求、数据库操作）对于应用而言是如此的重要，把它看作是Action触发的副作用有点主次颠倒了，因此MvRx并没有采用经典的Redux模型，而是采用了简化的Redux：
- 没有所谓的Action，既然Reducer的核心就是
f(State)=State，那就直接向Reducer提供State.()->State类型的元素，省略从Action到f(State)=State的映射。并且Debug模式下，State.()->State会连续运行两遍，尽量保证State.()->State是纯函数。 - 没有所谓的Side Effect，对于明确要进行的网络请求、数据库操作、文件读写就先进行这些Side Effect（使用RxJava Observable进行包装），拿到结果后再提供给Reducer；还可以使用
withState的方式，先获取State状态，再根据State触发相应的Side Effect。总之，不需要通过Action来触发Side Effect。
总结起来就是，Action、Side Effect与f(State)=State的统一，省略Action、Side Effect这些概念，突出Reducer的核心功能。这么做或许会降低一些复用性，例如，如果存在Action和Side Effect，我们可以建立起Action、Side Effect与f(State)=State多对多的对应关系，增加Action、Side Effect、f(State)=State复用的可能性，抽象层次更高，解耦更加彻底。但是，MvRx以更低的抽象层次，换来了概念上的简化，逻辑上的连续，或许会牺牲一些复用性，但是现实中，真的没有那么多可复用的东西，逻辑上的连续往往比所谓的解耦更加重要。
MvRx的问题
就像上一篇文章说的那样，每个StateStore都会新建一个线程用于执行reducer，也就是上图中的flushQueue方法，这避免了多线程状态下State的同步。单线程执行reducer没有问题，但是否每一个reducer都需要一个单独的新线程呢？正如我们前面说的那样，MvRx没有Action、Side Effect这些概念，flushQueue执行的就是一些State.()->State纯函数，这些纯函数一般而言就是Kotlin Data Class下的copy方法，众所周知，copy方法实现的是浅拷贝，一般不会有什么性能问题。因此，我认为为每一个StateStore分配一个新的线程来执行flushQueue有点多余，可以让所有StateStore共用同一个线程，这样既保证了单线程执行flushQueue，又减少了线程创建销毁的开销。（我给MvRx提过issue，但是他们并不接受）
以上是我认为MvRx中存在的一个问题，我认为MvRx还存在以下一些问题：
-
MvRxViewModel实现依赖注入不友好，需要在每个MvRxViewModel的companion object中实现特定的接口，简直累死。根本问题在于MvRx没有提供自定义ModelViewFactory的方式，当然，MvRx是为了保证State与MvRxViewModel的一致性，因为初始State对于MvRxViewModel而言是很重要的。 - 过多的反射，初始
State的创建必须通过反射，即使在大多数情况下，我们可以为初始State提供默认值；通过@PersistState保存State也必须通过反射（使用简单但是效率低），不如使用ViewModel SavedState，ViewModel SavedState使用也很简单，并且不使用反射，效率更高（之所以这样也是有原因的，因为先有的@PersistState，然后才有的ViewModel SavedState）。MvRx使用反射的地方太多了，有些是合理的，有些我觉得有点过度了。
虽说MvRx源码比较简单，想自己修改这些问题也不是什么难事，但是与官方版本脱节也不是一件好事。
