用 Runtime Spy 调整 Eclipse 的启动性能，第 1 部分：开始

核心提示： 对 org.eclipse.ui.actionSets 扩展点动作设置的贡献隐式地依赖于定义插件，即 Workbench UI 插件（org.eclipse.ui），用 Runtime Spy 调整 Eclipse 的启动性能，第 1 部分：开始(8)，Workbench 插件会去读取插件注册表

对 org.eclipse.ui.actionSets 扩展点动作设置的贡献隐式地依赖于定义插件，即 Workbench UI 插件（org.eclipse.ui）。Workbench 插件会去读取插件注册表，那里包含了对它的 org.eclipse.ui.actionSets 扩展的这一贡献，并创建相应的动作设置。 SampleAction 类将不会在这里被加载，因此包含它的插件也不会被加载。取而代之的是，Workbench 插件定义了一个委派动作来代表用户界面中的选择，这个委派动作会等待，直到用户真正选择它才创建 SampleAction 的一个实例来处理响应。

为创建 SampleAction 的一个实例，动作代表（action delegate）调用插件注册表实例 IConfigurationElement 的 createExecutableExtension 方法，对应于我们的例子清单文件中指定的 <action class="hello.actions.SampleAction" ...> 标签。虽然那样不错，但是有时在栈记录结果中不容易看出来。让我们来仔细看一个比“Hello, Eclipse”按钮选择更难的例子。图 6 显示了一个由可执行扩展处理而导致的典型（插件）激活。现在让我们用 Stack Trace 视图来确定其原因，步骤同前。

图 6. Stack Trace 视图显示了可执行扩展的启动

在这个例子中，我们从栈记录高亮部分的底部可以看出，这些都是源于 PDE 的 Plug-ins 视图中的一次双击。默认的动作处理者负责处理请求 Workbench 打开 Plug-in Manifest 编辑器的动作，随后激活 org.eclipse.ui.editors 插件。栈记录的高亮部分只是显示了扩展点处理器的代码，因为它对 Workbench 插件类 (org.eclipse.ui) 的引用是间接的。通过六次类似的栈记录，您将识别出对 IConfigurationElement.createExecutableExtension 调用前后重要的部分，并很快看出是谁启动了它以及结果是什么。您可以再次选择 按钮来更新加载的类并重新按加载顺序排序，以更好地了解插件启动后发生了什么事情。