java - 通过扩展 BaseActivites 来划分职责是不好的做法吗？

Question

我划分了 MainActivity 的职责，并尝试通过扩展 BaseActivities 来保持它的清洁和可读性，例如 MainActivity extends AdBaseActivity extends LocationBaseActivity extends FullScreenActivity extends Activity。

每个 Activity 仅负责它们被命名为执行的操作，同时保持 MainActivity 设置布局和 View 并运行任务的主要对象，例如 GameSurfaceView 或它应该运行的主类。这种糟糕的编程实践是否涉及耦合和内聚、难以测试或来自任何其他设计原则方面？

是否使用一个类，例如 LocationController 以及所有需要和实例化的生命周期方法，或者与依赖注入(inject)一起使用，比扩展 BaseActivities 更好？

我想知道如何在需要权限时使用 Activity 所需的回调来维护管理器类，例如应该填充 DialogFragment 或任何其他 View ，或者返回另一个 Activity 的结果？这些管理器类可以是其他类的成员，对 Activity 有更深的引用可能会导致内存泄漏，如果这种情况只能 当管理器类处于阻止 Activity 引用不被释放的特定状态时发生。

Answer 1

TLDR；

是也不是!

继承和所有 OOP 原则对于可读性和代码管理非常有效，但由于您正在开发移动应用程序，太多的类可能会降低内存和性能。

---

我明白你想做什么以及为什么。不久前，我在编写一个相当大的 Android 应用程序时遇到了同样的问题。

因为它基本上是一个包含 4 个 Fragments 的单个 Activity 应用程序，所以我最终在我的 MainActivity 中包含了太多代码，即使是委托(delegate)一些代码到我的 Fragments。

然后我更改了我的 MainActivity 并通过组合使其拥有以下 Manager 类:

• 位置管理器
• ApiVendorManager
• UIManager
• BackgroundJobManager
• AppFunctionalityManager
• StageTransitionManager
• ...

每个包含 800+ 行代码和生命周期回调(onCreate()、onPause()、...)。

在那之后，我的 MainActivity 非常干净且井井有条，我为自己感到自豪，但我注意到性能急剧下降。

然后我偶然发现了这个 documentation page上面写着:

However, abstractions come at a significant cost: generally they require a fair amount more code that needs to be executed, requiring more time and more RAM for that code to be mapped into memory.

我最后所做的是通过仅维护 4 个 Manager 来在抽象 和性能 之间找到一些平衡。

我会说:继续抽象，直到您注意到性能问题。那时您应该考虑限制继承和组合，甚至可能重新合并一些以前扩展的类。

同样的原则也适用于扩展您的 Activity 类。