侦探 WebSphere Studio

让我们以一个如何使用 Runtime Spy 来诊断和纠正启动代码错误的例子来开 始。如您将看到的，这些修正不会在绝对意义上“提高”启动性能，而是延迟了 启动开销，这样会让用户感觉产品整体上更快。底层的 Eclipse 产品在这一点 上做得非常好，它会随着您的使用而将启动开销分解为小块分阶段进行。这是 Eclipse 的延迟插件加载策略的基础。

为对情况进行第一次观察，让我们启动 Studio 时只打开 Runtime Spy 透视 图。这样应该会加载几乎最少的插件并以最快的速度启动，如图 2 所示。

图 2. 启动时激活最少数目的插件

提示：快速查看新激活的插件

按下 按钮不会改变 Activated Plugin 列表中的已作出的选择。如果您想 查看特定的动作激活了哪些插件：

在列表中选择所有条目 (Ctrl+A)。

执行您期望激活一个或更多插件的动作。

选择 按钮来更新列表。

没有被选中的条目就是新激活的插件；被选中的那些是在动作之前就已经被 激活的。另外一种方法是，您可以记下 Order列中最后加载的插件的编号，执行 动作，然后对 Order 列重新排序，查看哪些插件出现于先前（已经激活）的最 后一个插件之后。

注意插件名末尾的星号。这些插件是在负责启动 Eclipse 的插件被激活时加 载的，那个插件名为 application plug-in。这个插件提供了一个实现 org.eclipse.core.runtime.applications 扩展点的 IPlatformRunnable 接口 的类。默认地，Workbench UI 插件提供对这个接口的一个实现，来创建工作台 窗口，收集对主菜单栏、工具栏等等的动作贡献 (action contributions)，一 般情况下还要为事务处理准备好 Eclipse 工作台用户界面。

实际上消耗的时钟时间将会比 Activated Plugins 视图中显示的 Startup time 列的和要多。这是因为后者不包括 Platform Runtime 加载之前 JVM 的运 行时间或者插件启动之外的 CPU 运行时间。在图 2 所示的例子中，从启动配置 启动 Run-time Workbench 时起实际上的启动时间大约是 13 秒。其中还包括启 动配置本身为构建插件列表等任务而引入的程序调试时间 (development-time) 开销。

即使加上这些开销，启动时间还是非常少，不是吗？

Workbench 启动扩展点的结果

让我们按下 按钮来更新活动的插件列表。就是那样！图 3 中是我们的第一个困 惑。

图 3. org.eclipse.ui.startup 扩展点激活的插件

被选中的那些插件是初始化时激活的。那么另外 11 个插件呢？或许有一些 是因 Runtime Spy 透视图而加载的。更为有趣的是，图 3 中有一些看起来可疑 的 Studio 插件。列表顶部显示的是“cheatsheet”和“internet”。它们是什 么？为什么现在被加载？回到用户界面，我们在 Help下拉菜单下找到了与第一 个插件相关的选项，如图 4 所示。

图 4. org.eclipse.ui.startup 激活的插件可以不被激活吗？

用Runtime Syp调整Eclipse的启动性能，第2部分 - 成功的骗局(3)

一般只有新用户才会去选择 Cheat Sheets菜单选项，所以我们为什么还要在 启动时为加载它们的相关插件而付出代价呢？ Workbench > Startup首选参 数页提示了答案，如图 5 所示。

图 5. 为 org.eclipse.ui.startup 扩展点作出贡献的插件

org.eclipse.ui.startup 扩展点可能是版本 2.0 一直有争议的 API 之一。当工作台窗口打开时它可以全权要求 Workbench UI 激活插件，而不受延迟加载 策略限制。如果一个插件的清单定义了这一扩展点，那么它的插件类必须实现 IStartup.earlyStartup 方法。

有对这个 API 的合法使用。由于文章长度有限，不能尽述这个列表中每一个 条目。所以让我们来考虑如上面图 5 所示添加的两个插

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!