如何分析 OSGi 部署的执行情况？
我正在开始为应用程序开发 OSGi 捆绑包，该应用程序将部署在具有某些硬件限制的设备中。我想知道如何分析该捆绑包的执行情况，以始终确保它符合最终设备中的依赖关系。最好有一个分析器来了解每个包使用了多少内存，定位瓶颈并比较同一服务的不同实现。
是否有适用于 OSGi 部署的分析器，或者我应该使用通用 Java 分析器？
为了进行开发，我使用 Pax runner 和 Apache felix 来运行捆绑包，并使用 Maven 来管理项目依赖项和构建。
I'm starting the development of an OSGi bundle for an application that will be deployed in a device with some hardware limitations. I'd like to know how could I profile the execution of that bundle to be always sure that it's going to fit with its dependencies in the final device. It would be nice to have a profiler to know how much memory is each bundle using, to localize bottle necks and to compare different implementations of the same service.
Is there any profiler for OSGi deployments or should I use a general Java profiler?
For developing I'm using Pax runner with Apache felix to run the bundle and maven to manage project dependencies and building.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的公司为嵌入式设备开发 OSGi 应用程序。不幸的是，我不知道有任何工具具有您正在寻找的所有功能。我可以告诉您我们如何处理您正在寻找的问题。
1）安装在设备上：我们在Eclipse中开发并使用Equinox进行部署。我们在 Eclipse 中使用 .product 文件进行构建。通过这样做，我们可以清楚地了解我们的程序将在设备上占用的磁盘/ROM 空间量。
2）对于分析，我们通常使用YourKit。还有其他优秀的 Java 分析器，但我们发现这个非常适合我们。
您可以采取的一项好技术是构建充当真实服务代理的服务版本。代理是插入计时代码的好地方，这样您就可以计算对每个服务方法的调用次数并确定每个调用的时间。您还可以通过这种方式根据参数对计时进行分类，以找到性能不佳的边缘情况。然后，当您准备好部署时，您可以删除代理。
祝你好运。
My company develops OSGi applications for embedded devices. Unfortunately, I'm unaware of any tool that has all the capabilities that you are looking for. I can tell you what we do to deal with the kind of issues you are looking for.
1) Fitting on the device: We develop in Eclipse and deploy using Equinox. We build using .product files in Eclipse. By doing this, we get a firm idea of the amount of disk/ROM space that our program will take on the device.
2) For profiling, we generally use YourKit. There are other good Java profilers out there, but we've found that this one works well for us.
A good technique that you can do is to build a version of the services that acts as a proxy to the real service. The proxy is a great place to insert timing code, so that you can count how many calls are made to each service method and determine the time for each call. You can also categorize the timings based on the arguments this way to find badly performing edge cases. Then when you get ready to deploy, you can take out the proxies.
Good luck.