许多 Android 应用都包含自己的 BaseActivity 类，应用中的所有 Activity 都会扩展该类。这很有用，因为它提供了一个中心位置来放置大多数/所有活动中通用的功能。拥有 BaseActivity 的主要缺点是您无法使用任何 Activity 子类(ListActivity 等(。
一种替代方法是有一个活动委托。这为功能提供了一个中心位置，同时仍然允许您使用 Activity 子类。也可以说它更易于测试，因为它使用组合而不是继承。
这两种解决方案都可能导致大量的意大利面条代码，当BaseActivity/ActivityDelegate变得太大和复杂时。对此的一种可能的解决方案是使用委托模式，但将功能拆分为许多不同的委托。这减少了代表中的意大利面条代码，但随后活动变得更加复杂 - 他们现在尝试将他们的 on* 方法转发给许多不同的代表，而不仅仅是一个。
所有这些问题的可能解决方案是使用委派管理器。代表管理器会跟踪应用程序中的所有较小代表。活动将其 on* 方法转发给委托管理器，后者将其转发给所有单独的代理人。这将完成以下所有操作：
- 重复数据删除代码 - 所有常用功能都放入其中一个委托中
- 允许使用活动子类
- 所有活动中的简单代码 - 所有 on* 方法仅转发到一个类
- 易于测试 - 在单元测试中模拟委托和委托管理器周围的所有内容很简单
以前有人尝试过使用这种模式吗？如果是这样，情况如何？
据我了解，您谈论的是整个应用程序的一个 DelegateManager 对象。如果是这种情况，您可以使用 registerActivityLifecycle Callbacks，请参阅 http://developer.android.com/reference/android/app/Application.html#registerActivityLifecycleCallbacks%28android.app.Application.ActivityLifecycleCallbacks%29
如果您使用的是 API 级别 14
registerActivityLifecycleCallbacks允许您挂钩到 XXX 生命周期方法上的活动。
这样做当然具有您描述的所有好处：
- 解耦仅在您实际需要重复行为时才可用，这对于 Activity 的工作方式绑定在一起的控制器+视图逻辑来说 很少见。
- 如果您有可以重用的活动，删除继承是很好的 - 但我以前从未这样做过。但我想一个好的用例是你处理设置的自制活动或需要应用程序范围的 L&F 和行为的类似活动。
在我的头顶上，我可以想到这些缺点：
- 到
- 处使用侦听器可能会模糊应用程序活动/调用层次结构的路径，并使代码难以理解。这适用于所有侦听器/调度程序类型的编程。这是一个强大的工具，但要小心处理它。
- 如果您所做的只是传递给生命周期侦听器/委托，它可以引入很多(如您所提到的(样板/意大利面条代码。
- 您有责任向
Application.unregisterActivityLifecycleCallbacks注销自己。我认为没有办法绕过它，
就我个人而言，我在生命周期中没有太多使用这种设计模式，但对于某些用例来说，这可能是值得的。例如：
- 应用程序生命周期记录器：每次创建/恢复/暂停时...一个活动，你 logcat 或其他东西使调试生命周期变得容易一些。 例如，
- 如果有人由于某种模型状态(例如，响铃警报 ->无法进入 AlarmEditActivity 而进入他/她不允许进入的活动(，您可以在那里执行 finish((。
- 跨活动边界传递对象状态，而不更改 Parcelable：s 和屏幕旋转。通常，这是通过应用程序中的映射或某处的某个静态字段实现的。您可以通过让委托人保持状态来执行此操作。
另外，看看：在 Android 中对活动进行子类化时，是否有一种设计模式可以减少代码重复？
我希望这是有帮助的=(