Android 架构设计——如何正确实现？

Question

18

一个好的Android应用程序架构是什么样子的？所有的“工作/业务逻辑”都应该在后台服务中完成，Activity 仅与服务通信以从某个地方（本地/远程）查询/获取数据吗？

应该将Activity调用的“服务”实现为真正的Android服务吗？还是作为POJO单例来执行工作（可能使用后台线程）。或者在您的Activity中实例化后台线程进行耗时的操作（查询Web服务）。

如何正确抽象您的数据访问？你会使用ContentProvider来访问/抽象你的数据吗？应该如何查询它？Activity？服务？..？

我试图搜索一个好的应用程序架构设计，但我只找到了Android的架构是什么样子的，而不是Android应用程序应该是什么样子的。

那么你对此有什么看法？Android 应用程序的哪些组件应该相互通信以确保最佳的可扩展性/封装性...？

- KL4711

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rich · Accepted Answer

针对这个问题，没有一个通用的答案。好的面向对象设计并不特定于Android。我的建议是：如果框架提供了适合您需要的高级别对象（例如，在Android中是Service），请使用它。如果您发现自己在做一些与框架提供的相同内容的POJO实现，则应该使用框架。

至于关注点分离，这是标准的面向对象方法。不要将任何不属于Activity职责范围内的东西放入Activity类中。过度填充Activity的方法和属性，即Activity需要但不是Activity职责的东西，这是不好的——会使您的Activity意图难以理解。

我通常会将应用程序中的内容分成子包。

等等。

至于应用程序内部的通信...

我总是有一个自定义的Application类，将其注册到清单中。这样，当我需要控制器和辅助程序成为“单个实例”时，我不必进行所有那些疯狂的线程安全单例的工作...我只需要保留一个全局副本。

RoboGuice是一个依赖注入框架，可以更轻松地实现这一点...绝对值得一试。如果您感兴趣，RoboGuice的Google Group非常好，里面有框架的创建者，他们可以回答您的任何问题。

至于应用程序内部的通信，我使用我的单个实例控制器和状态类来保存状态和执行常见任务，并且通常使用BroadcastIntents从服务向Activity发送消息。