跟踪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

• 声明式服务或其他组件模型可帮助您编写更简洁，更稳定的代码

Answer 2

在使用OSGi进行开发的12年里，我认为我从未编写一个ServiceTrackerCustomizer 。 恕我直言，直接子类化ServiceTracker并将customizer参数保留为null更加方便。

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

从功能上讲，结果是相同的，因此非常个人喜好。