ReactiveX

距离我第一次听说 ReactiveX - An API for asynchronous programming with observable streams 已经一年多了。

最初的印象是一个并发+观察者+流模式的拓展API库,因为一直没有时间去研究以及没有机会用到这么复杂的库,所以一直没有好好去研究这个玩意。

从昨天开始,我又一次踏上了学习 ReactiveX 的旅途。

因为找到了一些比较有用的新资料以及我本身的水平相比于一年多前也有了明显的提高,这次的学习还是比较顺利的。

资料:Reactive Extensions (Rx) Koans,里面都是一些单元测试代码,利用这些小片段,很容易就能找到 Rx 的感觉,然后再结合官方的说明文档,或者是 Rx 的翻译文档,很快就能理解 Rx 的操作。

这个资料是 C# (Rx.NET) 的,要利用 Visual Studio……

用了以后发现这个库……emmmm,确实很普适很好用,很好地抽象了很多业务需求的逻辑。

Rx 提供了一套 API 来让开发者自由组合以完成业务逻辑,具体的感觉跟直接写自然语言描述一样舒服。

然而有时候,这个过程会变得特别别扭,虽然说 Rx 依然可以做到,但是仔细一想又感觉它做得特别蠢,从性能上来讲不好保证。

比如说对于支持随机访问(Random Access)的容器不友好,我现在手头的工作是量化交易模型的研发,里面肯定要用到指标(index)。

而指标是一个经常要回溯检查的对象,随处可见直接通过下标偏移来访问指标数据的操作。

而这种随机访问本身就不符合 Rx 的 Stream API 的基本设定。

诚然,如果让 Stream 中的数据是整个的随机访问容器,从性能上来说开销过大,通常会考虑使用可持久化/不可变数据结构去优化内存的使用。

这是不是太重了/太具有侵入性了……

回过头去想想 Rx 的适用场景,其实是做了非常明确的限定的:

  1. Stream 流

    通常我们可以认为流中的数据是一去不复返的,不能访问上一个数据。

  2. Asynchronous 异步

    非常复杂的异步交互场景,涉及时间、订阅/取消订阅,异步动作。

如果符合这些条件,那么 Rx 能给你带来很多便利,否则,你可能会觉得用这个东西很痛苦,所谓“削足适履”是也。