我正在创建一些OSGi包 . 他们注册服务，并获得（当然也使用）彼此的服务 .
我决定使用 ServiceTracker 而不是声明服务 .
在我搜索有关这方面的信息时，我找到了两种跟踪服务的方法 .
第一个是为每个服务创建一个自己的跟踪器类， extends ServiceTracker 类并覆盖需要重写的方法 . 然后在激活器类中创建此跟踪器类的新实例，为其提供捆绑上下文并打开它以进行跟踪 .
另一种方法是为每个服务创建一个跟踪器类， implements ServiceTrackerCustomizer 接口并覆盖需要重写的方法 . 然后在activator类中创建 ServiceTracker 类的新实例，为其提供bundle上下文，需要跟踪的服务名称 and 我们的定制器类的新实例 . 然后打开它进行跟踪 .
这两种方法之间有什么不同吗？我会说不 . 在ServiceTracker javadoc中我可以看到 ServiceTracker 类也实现了 ServiceTrackerCustomizer 接口 .
你能告诉我两种方法的利弊吗？提前致谢 .
2 回答
以下是我的理由：
子类ServiceTracker if
您想要对超类的构造函数参数进行硬编码 . 例如：硬编码类型或过滤器 . 在这种情况下，如果所有用户都应该知道跟踪器应该被实例化的过滤器，那就不好看了
您想要覆盖（换行）ServiceTracker的打开，关闭或其他功能
您想扩展ServiceTracker的功能 . 例如：通过具有基于Java Generics相等性预过滤服务对象的实现
如果实现接口：
您希望将来切换到其他ServiceTracker实现 . ServiceTracker是OSGi核心的附加组件，它只是5.0.0以来核心规范的一部分 . 将来可以创建其他更有效的实现
您不希望决定要覆盖哪些构造函数，因为从业务逻辑的角度来看，参数是灵活的 . 未来可能会有更多标准ServiceTracker类的构造函数 . 如果对它进行子类化，则您的类将不支持这些构造函数
您希望在ServiceTrackerCustomizer的实现中从另一个类中进行子类化
如果，请不要直接使用ServiceTracker
在使用OSGi开发的12年多的时间里，我认为我从来没有写过一篇
ServiceTrackerCustomizer. 恕我直言，直接子类ServiceTracker并保留定制器参数null更方便 .一个简单的原因是_931184需要提供
modifiedService方法的实现，这很少需要 .但从功能上来说，结果是一样的，所以这是个人偏好 .