它还被用于在移动端带来额外的中间件和应用程序的可移植性。移动端可用于WinMo, Symbian, Android等。一旦与设备功能集成，就会出现碎片化。

我使用OSGi已经有8年左右的时间了，我不得不说，只有当你有业务需要在运行时更新、删除、安装或替换某个组件时，你才应该考虑使用OSGi。这也意味着您应该有一个模块化的心态，并理解模块化的含义。有一些争论说OSGi是轻量级的——是的，这是真的，但也有一些其他的框架是轻量级的，更容易维护和开发。同样的道理也适用于安全java等等。

OSGi需要一个可靠的体系结构才能正确使用，而且在没有任何OSGi参与的情况下，很容易使OSGi系统成为一个独立可运行的jar。

我还不是OSGi的“粉丝”…

我一直在财富100强公司使用企业应用程序。最近，我们使用的产品已经“升级”为OSGi实现。

启动本地cba部署… [2/18/14 8:47:23 727 EST] 00000347 CheckForOasis

最终部署，“以下包将暂停，然后重新启动” 00000143 AriesApplicat I CWSAI0054I:作为应用程序更新操作的一部分

51分钟……每次代码改变…以前的版本(非osgi)在旧的开发机器上部署不到5分钟。

在一台有16g内存和40g空闲磁盘和Intel i5-3437U 1.9 GHz CPU的机器上

The "benefit" of this upgrade was sold as improving (production) deployments - an activity that we do about 4 times a year with maybe 2-4 small fix deployments a year. Adding 45 minutes per day to 15 people (QA and developers) I can't imagine ever being justified. In big enterprise applications, if your application is a core application, then changing it is, rightly so (small changes have potential for far reaching impacts - must be communicated and planned with consumers all over the enterprise), a monumental activity - wrong architecture for OSGi. If your application is not an enterprise application - i.e. each consumer can have their own tailored module likely hitting their own silo of data in their own silo'd database and running on a server that hosts many applications, then maybe look at OSGi. At least, that is my experience thus far.

至少，OSGi让您考虑到模块化、代码重用、版本控制以及项目的一般管道。

在它的官方网站上已经有了一个很有说服力的声明，我可以引用

OSGi技术如此成功的关键原因是它提供了一个非常成熟的组件系统，实际上可以在数量惊人的环境中工作。OSGi组件系统实际上用于构建高度复杂的应用程序，如ide (Eclipse)、应用服务器(GlassFish、IBM Websphere、Oracle/BEA Weblogic、Jonas、JBoss)、应用程序框架(Spring、Guice)、工业自动化、住宅网关、电话等等。

至于开发商的利益?

开发人员:OSGi通过为当今大规模分布式系统和小型嵌入式应用程序提供模块化体系结构来降低复杂性。从内部和现成的模块构建系统可以显著降低复杂性，从而降低开发和维护费用。OSGi编程模型实现了基于组件的系统的承诺。

请参阅使用OSGi的好处。

如果基于Java的应用程序需要添加或删除模块(扩展应用程序的基本功能)，而不需要关闭JVM，则可以使用OSGI。通常，如果关闭JVM的成本比较高，那么仅仅是为了更新或增强功能。

例子:

Eclipse:为插件的安装、卸载、更新和相互依赖提供了平台。 AEM: WCM应用程序，其中功能更改将由业务驱动，无法承担维护停机时间。

注意:Spring框架停止支持OSGI Spring包，认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。我个人是不会考虑OSGI的，除非绝对必要，比如在构建平台这样的大项目中。