持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第20天，点击查看活动详情

关于反应式编程

反应式编程（Rx）“是计算机中一种面向数据流和变化传播的编程范式。这种范式允许用户轻松指定静态（例如，数组）或动态（例如，事件发射器）数据流，以及表明相关执行模型内部存在推断的依赖关系，从而允许自动传播修改后的数据流。” 

反应式编程是 observables、observers 和 scheduler 的结合。

observables

简单地说，observables 就是数据流。可以将一个线程传输到另一个线程的数据存储在可观察对象中。本质上是定期发送数据或在其生命周期内仅发送一次数据，具体取决于如何设置。

observers

本质上是消费者，observers（观察者)使用之前注册的可观察对象发出的数据流。

scheduler

简而言之，这是线程管理。 因为我们在谈论异步编程，所以线程管理变得很简单。结论解释，调度程序指示observables和observers使用哪些线程。

什么时候适合使用响应式编程？

我们现在明白了为什么要创建响应式编程以及它是什么，但是我们什么时候使用它呢？在处理异步数据流时，它是一种很好的选择。即使用例中的微小变化也可能成为我们决策的决定性因素。

以下是使用反应式编程的一些示例：

使用响应式编程开发移动应用程序

由于移动设备的功能不足以处理繁重的工作，因此经常需要在活动期间或任务之后从后台线程更新主线程上的用户界面。结果，我们在服务器上执行繁重的工作和复杂的计算。因此，我们需要网络活动的异步工作，这就是反应式编程发挥作用的地方。

在 iQIYI API 中与 RxJava 一起使用响应式编程

为了成功减少网络常规交互，需要使用 RxJava 服务器端并发在 iQIYI API 中进行反应式编程。由于来自设备的每个网络请求自动与其他网络请求并行运行，因此如果服务器不支持并发执行，则单个“重要”客户端请求可能不会比几个“普通”客户端请求更好。即使考虑到网络延迟，如果一个压缩的“重要”请求的服务器端处理没有达到相同程度的同时执行，它可能会比许多“普通”请求慢。

外呼服务

底层协议是对外部服务的阻塞和同步调用，因为现在许多后端服务都是 RESTful（即，它们使用 HTTP）。也许不是明显的 FRP 地形，但它是一个非常丰富的领域，因为此类服务的开发经常需要联系其他服务，然后根据第一次调用的结果调用甚至额外的服务。在进行如此多的 IO 时，在发出下一个请求之前等待一个呼叫完成可能会导致某些可怜的客户在做出响应之前被丢弃。

因此，优化外部服务调用，特别是跨调用的复杂依赖关系编排，是一个聪明的想法。FRP 支持此类活动背后的逻辑的“可组合性”，使调用服务的开发人员更容易编写。

高并发消息消费者

大量并发消息处理的消费者是典型的企业用例，尤其是在高度同步的情况下。反应式框架喜欢通过测量微基准来吹嘘他们每秒可以在 JVM 上处理多少条消息。

这些统计数据很棒（每秒数千万条消息并不难产生），但它们可能有点偏差：如果他们说他们正在对基本的“for”循环进行基准测试，你就不会这么想了。但是，不应该过早地放弃它，很明显，当涉及到性能时，应该感谢它做做出的贡献。

当涉及到特定类型的高负载或多用户应用程序时，响应式是一个出色的解决方案。游戏、社交媒体和聊天室是用于音频和视频的应用程序（主要用于流媒体），但应该记住，在没有真正需要的情况下使用响应式技术会增加不必要的复杂性，从而对应用程序造成严重破坏。

整合 Rx

要将 Rx 集成到您的应用程序中，请遵循以下三个简单步骤。

第 1 步：创造一个 Data-Emitting Observable

产生数据的数据库是可观察的：在这种情况下，它发出字符串。just()是一个函数，它只是一个一个地发出参数中提供的数据。

第 2 步：创造一个Data-Consuming Observer

Observer使用数据库 observable 生成的数据。它接收数据并处理它，以及处理错误。

第 3 步：调节并发性

在最后一步，我们定义我们的并发调度器。

Oservable 被告知在后台线程中通过subscribeOn(Schedulers.newThread()). 

Observer被告知在主线程上通过observeOn(AndroidSchedulers.mainThread()). 

总结

这篇文章描述了反应模式的趋势，并示例了几种实际使用场景中。对于 Java 虚拟机，有几个反应式库或框架正在积极开发中，它们有很多类似的功能，但由于反应式编程，它们变得越来越兼容。