android - 为什么我不应该使用消息总线而不是加载器和服务？

Question

在典型的 Android 项目中，我们需要以干净的方式从某处(REST、SQL、缓存等)将数据拉入 UI，我们通常使用 Loader、Service 或(可能是 yuk)AsyncTask，但我发现由于以下几个原因，所有这些方法都不能令人满意:

• 它们很丑陋，尤其是具有令人震惊的 API 结构的加载器
• 太容易被线程缠住，踩到 UI 线程
• 我们的表示层代码被 Android 代码和样板代码污染了。我们经常将 Android 对象(例如 Cursors)直接传递到 UI 层，这使得几乎不可能实现干净的架构。这迫使我们将特定于业务领域的代码(理想情况下是纯 Java 对象)与 Android 平台代码混合在一起——这对于可读性、维护、测试或 future 开发的灵 active 都不是很好。在实践中，我们经常会遇到庞大而凌乱的 Activity/Fragment 类。

我被这些文章中概述的想法所吸引: http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/ http://antonioleiva.com/mvp-android/ http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

在成功开始使用 MVP 将 Activity/fragment/ View 分解为更小/更干净的部分后，我现在认为解决上述问题的方法可能是依赖消息总线(Otto、EventBus 等)服务或加载程序或与域数据交互的任何内容。

所以在实践中，这意味着不是使用(例如)CursorLoader 从数据库中加载游标，而是使用消息总线发送消息来请求数据，数据在后台线程上加载响应该消息，然后在响应数据通过 UI 线程上的消息到达时对其进行处理。对我来说至关重要的是，我更喜欢将数据结构排除在业务领域之外，而不是 Android 领域，因此我更喜欢一组业务对象，而不是光标。

这种工程总是需要权衡取舍，尽管这似乎提供了更清晰的关注点分离，但加载器/服务样板更少，有什么缺点？

• 理解代码可能更难(尤其是对于新开发人员)
• 有必要确保在正确的线程上发送和接收消息(Otto 似乎在这里可能有限制)
• 有必要避免将所有内容都作为消息来实现，这最终会适得其反
• 传递业务对象集合的效率可能低于使用像游标这样的对象。尽管在许多情况下，这在实践中是否存在问题？
• 我不知道 Otto/EventBus 是否仅设计用于传递非常小的消息，或者是否适合传递更大的对象(例如业务对象数组)。

我的问题是，有什么根本原因不采用这种基于消息的方法来处理 Android 应用程序吗？

Answer 1

any fundamental reasons NOT to take this message-based approach with Android apps

我猜没有。在我的实践中，我使用了诸如 Loaders 和 AsyncTasks 之类的“库存”东西(我不会将 Services 放在这一行，因为它的责任要广泛得多)。然后总线的事情被实现了，你猜怎么着？生活变得更容易和更可预测，脱钩增加了。一旦我完全转向 Rx，工作不仅变得更容易，而且更有趣!但是，没有什么可以使您免于处理生命周期。

所有这些都只是实现细节，更重要的是保持全局的清晰。当您谈论清洁架构时，事情是从 UI 层( Activity 、 fragment 、 View ......)隐藏对象如何以及从哪里来的。一旦你将这个特定的工作封装在用例中，使用哪个工具就不是什么大问题了:加载器、总线或 Rx - 你的 UI 层应该只坚持用例提供的接口(interface) - 回调、事件或 observables

我要指出两点:

1. 任何层对用例实现的了解越少越好。
2. 如果您选择了一种特定的实现工具，请在任何地方使用它。不要为同一项工作混合使用多种工具。