在跟踪OSGi服务时，扩展ServiceTracker类和实现ServiceTrackerCustomizer接口之间有区别吗？

Question

我正在创建一些OSGi包。他们注册服务并获得（当然也使用）彼此的服务。

我决定使用ServiceTracker而不是声明服务。

在我搜索有关此信息时，我发现了两种跟踪服务的方法。

第一个是为每个服务创建一个自己的跟踪器类，扩展 ServiceTracker类，并覆盖需要重写的方法。然后在激活器类中创建此跟踪器类的新实例，为其提供捆绑上下文并打开它以进行跟踪。

另一种方法是为每个服务创建一个跟踪器类，实现 ServiceTrackerCustomizer接口，并覆盖需要重写的方法。然后在激活器类中创建ServiceTracker类的新实例，为其提供捆绑上下文，需要跟踪的服务名称和我们的定制器类的新实例。然后打开它进行跟踪。

这两种方法之间有什么不同吗？我会说不。在ServiceTracker javadoc我可以看到ServiceTracker类也实现了ServiceTrackerCustomizer接口。

请您告诉我两种方法的优缺点？提前谢谢。

Answer 1

以下是我的理由：

子类ServiceTracker如果

• 您想要对超类的构造函数参数进行硬编码。例如：硬编码类型或过滤器。在这种情况下，如果所有用户都应该知道应该使用
实例化跟踪器的过滤器，那就不好看了。
• 您想要覆盖（换行）ServiceTracker
的打开，关闭或其他功能
• 您想扩展 ServiceTracker 的功能。例如：通过具有基于Java泛型相等性预过滤服务对象的实现

在以下情况下实施界面：

• 您希望将来切换到其他 ServiceTracker 实施。 ServiceTracker 是OSGi核心的附加组件，它只是5.0.0以来核心规范的一部分。其他更有效的实施可以在未来创建
• 您不希望决定要覆盖哪些构造函数，因为从业务逻辑的角度来看，参数是灵活的。未来可能会有更多标准ServiceTracker类的构造函数。如果您对它进行子类化，则您的类将不支持这些构造函数
• 您希望在 ServiceTrackerCustomizer
的实现中从另一个类中进行子类化

如果

，请勿直接使用 ServiceTracker

• 声明服务或其他Component Model可帮助您编写更清晰，更稳定的代码

Answer 2

在使用OSGi开发的12年多的时间里，我不认为我曾写过一篇async.waterfall()。恕我直言，直接子类ServiceTrackerCustomizer并离开自定义程序参数ServiceTracker会更方便。

更容易进行子类化的一个简单原因是，您不需要提供null方法的实现，这很少需要。

但从功能上来说，结果将是相同的，因此它非常符合个人喜好。