我试着了解osgi的工作原理 . 我编写了我的第一个hello-world bundle，它在执行bundle activator类的start方法时提供了一些控制台输出 . 现在，我已经阅读了关于延迟启动机制的内容，并将此标志放入我的捆绑清单中 . 然后，我启动了equinox控制台，安装了我的软件包并启动了它 . 但现在我希望我的包被标记为'开始' . 但它已经调用它的start方法并被标记为活动 . 我对懒惰的启动机制有什么不妥吗？
如果您有其他捆绑包依赖于捆绑包中的捆绑包和类，则会使用lazy-start标志 .
假设您有两个捆绑A和B，其中
A导出C类
B取决于A.
B包含引用C的D类
B束被激活后会发生什么？
如果没有延迟加载标志，则首先加载并激活A包 .
使用延迟加载标志，在D类需要引用类C之前，不会加载或激活A包 .
这可以在激活配置文件中产生很大的差异，因为捆绑包的加载和激活被延迟发生，使用延迟加载标志尽可能晚，因此捆绑包的初始响应非常快......
相反，这个标志也使得很难推断B中方法的执行时间，因为这可以随时加载和激活bundle来拦截....
您说，您已经在安装后启动了捆绑包 - 如果您手动启动捆绑包，则无论延迟激活策略如何都会激活它 .
根据the OSGi specification，以下情况适用于激活：
延迟激活策略表示捆绑一旦启动，在从其加载类之前不得激活它;在正常的类加载期间或通过Bundle loadClass方法 . 资源加载不会触发激活 . 默认急切激活策略的此更改将反映在捆绑包及其事件的状态中 . 使用延迟激活策略启动捆绑包时，必须执行以下步骤：为捆绑包创建捆绑包上下文 . 捆绑状态将移至STARTING状态 . LAZY_ACTIVATION事件被触发 . 系统等待捆绑的类加载发生 . 正常的STARTING事件被触发 . 捆绑包已激活 . 捆绑状态将移至ACTIVE . STARTED事件被触发 . 如果由于Bundle Activator start方法抛出异常而导致激活失败，则必须停止该bundle而不调用Bundle Activator stop方法 . 这些步骤如图4.29中的流程图所示 . 该流程图还显示了正常急切激活和延迟激活的激活策略的差异 .
Update ：因为我不能说我在编写答案的时候打开了哪个版本的规范（但是，我相信它是4.2或4.3），我已经检查了当前的v5.0规范和4.4节 . 6.2包含实际的，语义上等效的地方 .
2 回答
如果您有其他捆绑包依赖于捆绑包中的捆绑包和类，则会使用lazy-start标志 .
假设您有两个捆绑A和B，其中
A导出C类
B取决于A.
B包含引用C的D类
B束被激活后会发生什么？
如果没有延迟加载标志，则首先加载并激活A包 .
使用延迟加载标志，在D类需要引用类C之前，不会加载或激活A包 .
这可以在激活配置文件中产生很大的差异，因为捆绑包的加载和激活被延迟发生，使用延迟加载标志尽可能晚，因此捆绑包的初始响应非常快......
相反，这个标志也使得很难推断B中方法的执行时间，因为这可以随时加载和激活bundle来拦截....
您说，您已经在安装后启动了捆绑包 - 如果您手动启动捆绑包，则无论延迟激活策略如何都会激活它 .
根据the OSGi specification，以下情况适用于激活：
Update ：因为我不能说我在编写答案的时候打开了哪个版本的规范（但是，我相信它是4.2或4.3），我已经检查了当前的v5.0规范和4.4节 . 6.2包含实际的，语义上等效的地方 .