eclipse软件体系结构论文

1、基于OSGi的Eclipse插件体系结构的研究马晟，张渊，刘德钢（清华大学，软件学院，北京 100084）摘要：EclipseAEB一个开放源代码的是基于插件机制开发的软件开发项目，专注于为高度集成的工具开发提供一个全功能的、具有商业品质的工业平台。Eclipse3.0选才OSGi 服务平台规范为运行时架构。本文以研究 Eclipse 体系结构为目的背景，介绍了插件技术原理，阐述了 OSGi 规范，分析了 Eclipse 的插件体系结构，并对基于 OSGi 和 EclipseRCP 对 Eclipse 的插件扩展开发进行了研究。 最后我们对比介绍了 Firefox 的插件机制。研究表明 Ecl

2、ipse 平台的体系结构是一个成熟的、精心设计的并且可以很容易扩展的体系结构。关键词：OSGiEclipse,插件，体系结构Abstract:Eclipseisanopensourcesoftwaredevelopmentprojectbasedontheplugindevelopingmechanism.Itconcentratesonsupportingafullfeaturedcommercialindustryplatformtobuildhighlyintegratedtools.Eclipse3.0usesOSGiServicePlatformStandardastheruntim

3、earchitecture.AfterlearningthearchitectureofEclipse,thispaperinstructstheplugintechnologytheory,showstheOSGistandard,analysisthearchitectureofEclipsebasedonplug-inmechanismandmakesastudyonthedevelopmentofEclipseplug-insbasedonOSGiorRCP.Finally,weintroducetheplug-inmechanismofFirefoxaccordingtothecom

4、parison.TheStudypresentsthatthearchitectureofEclipseplatformisamature,welldesignedarchitecturethatiseasilyextended.Keywords:OSGiEclipse,Plugin,Architecture目录1.Eclipse 体系 Z构 31.1.插件技术原理 31.1.1.插件概念说明 31.1.2.插件接口的认识 41.1.3.程序结构及其运行机制 41.2.OSGi 体系结构 41.2.1.OSGi 概述 41.2.2.OSGi 框架 51.2.3.OSGi 小结 91.3.Ecl

5、ipse 的插件机制体系结构 91.3.1.Eclipse 发展历程 91.3.2.Eclipse 体系 Z构 91.3.3.Eclipse 平台运行时与 OSGi 容器 101.3.4.插件扩展机制 111.3.5.插件的生命周期 131.3.6.插件的依赖性 141.3.7.插件间通信 142.Eclipse 插件机制应用 182.1.常用的 Eclipse 插件 182.2.基于 OSGi 的插件体系结构设计与实现 19演示的功能 19体系结构设计 20实现原理 21运行示意 212.3.Eclipse 插件机制扩展一一 RCP 应用 223.Eclipse 体系结构与其他才 f 件结构

6、比较 233.1.MozillaFirefox 体系结构 233.2.MozillaFirefox 扩展分析 24install.rdf25chrome 目录 25chrome.manifest 文件 254.结束语 255.附录 26Eclips 啾系结构插件技术原理670插件概念说明插件是一种遵循统一的预定义接口规范编写出来的程序，应用程序在运行时通过接口规范对插件进行调用，以扩展应用程序的功能。在英文中插件通常称为 plug-in、plugin 或者plugin 。 插 件 最 典 型 的 例 子 是 Eclipse 开 发 平 台 ， Microsoft 的 ActiveX 控 件 和

7、 COM（ComponentObjectModel,部件对象模型）实际上 ActiveX 控件不过是一个更高继承层次的 COM 而已。此外还有 Photoshop 的滤镜（Filter）也是一种比较常见的插件，还有就是 MozillaFirefox,Foobar 等等也遵循着插件机制。插件最吸引人的地方当然就是其所实现“运行时（Run-time）”功能扩展。这意味着软件开发者可以通过公布插件的预定义接口规范，从而允许第三方的软件开发者通过开发插件对软件的功能进行扩展，而无需对整个程序代码进行重新编译。运行时是相对于编译时（Assembly-time）而言的。一般来说，软件开发者对软件功能更新时

8、，是在源代码级别进行更新，然后对整个程序进行重新编译，进而发布应用程序的新版本，这就是编译时的软件更新。插件的本质在于不修改程序主体（或者程序运行平台）的情况下对软件功能进行扩展与加强，当插件的接口公开后， 任何公司或个人都可以制作自己的插件来解决一些操作上的不便或增加新的功能， 也就是实现真正意义上的“即插即用”软件开发。从这种意义上讲，USB 接口可以很形象地描述插件的应用模式。对于任何计算机外部配件，移动光驱，鼠标硬盘等等，都可以实现即插即用，虽然部分也需要安装驱动程序，但是在应用上，它们都是即插即用的。“平台+插件软件结构”是将一个待开发的目标软件分为两部分，一部分为程序的主体或主框架

9、，可定义为平台，另一部分为功能扩展或补充模块，可定义为插件。在进行软件开发之前，是否采用“平台+插件软件结构”进行软件开发，还要依据具体的软件需求情况进行确定，但一般来讲，使用“平台+插件软件结构”进行软件设计会给所开发软件增加新的生命力。当确定“平台+插件的软件结构”之后，就要分析哪些部分功能由主体完成（即平台的基本功能），哪些部分功能由插件完成（即需要扩展的插件功能）。平台所完成的功能应为一个软件系统的核心和基础，这些基本功能即可为用户使用，也可为插件使用，就是又可以把平台基本功能分为两个部分，内核功能和插件处理功能。平台的内核功能是整个软件的重要功能，一个软件的大部分功能因由内核功能完成

10、。平台的插件处理功能用于扩展平台和管理插件，为插件操纵平台和与插件通信提供标准平台扩展接口。插件所完成的功能是对平台功能的扩展与补充，一般插件完成系列化功能，例如：EclipseIDE 是Eclipse 的运行主体平台。你要编辑 c/c+程序，你可以应用 CDT 插件；使用 SVN,你可以安装 SVNRepositoryExploringo在后续章节中，我们将会列出 Eclipse 的常用插件。为了实现平台+插件结构的软件设计需要定义两个标准接口，一个为由平台所实现的平台扩展接口，一个为插件所实现的插件接口。这里需要说明的是：平台扩展接口完全由平台实现，插件只是调用和使用，插件接口完全由插件实

11、现，平台也只是调用和使用。平台扩展接口实现插件向平台方向的单向通信，插件通过平台扩展接口可获取主框架的各种资源和数据，可包括各种系统句柄，程序内部数据以及内存分配等。插件接口为平台向插件方向的单向通信，平台通过插件接口调用插件所实现的功能，读取插件处理数据等。平台插件处理功能包括插件注册、管理和调用，以及平台扩展接口的功能实现。插件注册为按照某种机制首先在系统中搜索已安装插件，之后将搜索到的插件注册到平台上，并在平台上生成相应的调用机制，这包括菜单选项、工具栏、内部调用等。插件管理完成插件与平台的协调，为各插件在平台上生成管理信息以及进行插件的状态跟踪。插件调用为调用各插件所实现的功能。平台插

12、件处理功能实现的另一部分功能为平台扩展接口的具体实现。670插件接口的认识开发支持插件功能的应用程序必须解决一个问题：如何在主程序与插件间正确地互相通信。为了在主程序与插件之间能正确地互相通信，应该先制定一套通信标准，这套通信标准就是接口，主程序与插件只能通过制订好的接口进行通信。软件开发中，接口只是定义功能并规定调用功能的形式，而不包含功能的实现。接口实质上是软件模块的调用规范。在后续章节中我们将会介绍 Eclipse 开发的插件中，常用的几种通讯方式。就开发支持插件功能的应用程序而言，一般来说由主程序的开发者来制订接口，如果希望其他的开发人员能开发相关的插件，只要公开相关接口即可。接口功能

13、一般由插件方实现。因为插件的实现也要调用主程序的功能，所以接口功能也可能由主程序来实现。也就是说，主程序与插件的信息流可能是双向的。接口的调用规范与功能实现互相分离有一个很大的优点：尽管不同的插件开发者对同一个接口的具体实现不同，但是在主程序中对这些插件的调用方式是一样的。如果有主程序实现的接口，在不同的插件中也可以用相同的使用方式调用主程序的功能。这极大的提高了应用程序的灵活性。670程序结构及其运行机制主程序中，插件管理部分用于管理插件的安装和删除，并将所有安装插件的信息保存到适合的地方，例如保存到注册表或配置文件中。主程序启动时，根据插件的配置信息加载插件模块，然后获得插件的输出函数或输

14、出类的指针并加以保存，如果需要的话，可以向主程序增加界面接口元素，如菜单、工具条按钮等。在主程序中当点击与插件相关联的接口元素时，就会触发插件调用函数， 在插件调用函数中使用主函数中所保存的插件信息调用插件中实现的功能。 在调用插件输出函数时也可以把主程序中实现的接口传递给插件方。OSGi体系结构670OSGi概述OSGi(OpenServiceGatewayInitiative)最初的目的是为嵌入式设备，提供一个通用的软件运行平台。也就是一个隐藏了设备操作系统和硬件细节的中间件平台。OSG?联盟成立于 1999 年 3 月，致力于为网络和本地设备建立开放的网络管理服务规范，并制定下一代互联网

15、向住宅、汽车、移动电话、电脑、小型办公室等提供服务的标准。OSGi 服务平台规范是一个开放的一般性架构，主要为供应商如服务提供商、开发者、软件提供商、网关运营商和设备提供商等开发、部署和管理服务提供一种一致的协作环境。由于该规范对服务部署的自适应性和可管理性，使得智能设备有了全新的用武之地。本规范的目标是机顶盒、服务网关、调制解调器、消费类电子设备、计算机、工业电脑、汽车、移动电话等众多产品，通过 OSGi 规范技术的实施将使服务提供商如：电信、电话公司等能提供更具有吸引力服务。各种数字和模拟的机顶盒、服务网关、有线电视电缆调制解调器、消费类电子产品、PC 工业计算机、汽车等都可以使用 OSG

16、i 来接入网络。OSGi 技术是一些规范的集合，这些规范形成了一个基于 java 的动态组件系统。由此形成了一个开发模式，在这个模式上应用可以由许多不同的可复用组件组成。OSGi 规范使得组件间相互隐藏了实现细节，并通过服务来通信。这些服务是专门用来在组件间通信的共享对象。这个令人惊奇的简单模式已经影响到了几乎软件开发进程的所有的方面。OSGi 是第一个真正成功实现组件系统的技术，它解决了软件开发中很多实际的问题。采用 OSGi 技术，可以显著减少几乎所有方面的开发复杂度。编码更加容易书写和验证，重用增加开发系统变得更加容易，调度更容易管理，系统缺陷更早的发现，运行时提供的各种监视机制可以更好

17、的监督正在运行的程序。最重要的是，OSGi 已经被广泛采用，并且被 Eclipse 和 Spring 等广受欢迎的应用程序所验证。开发 OSGi 技术的目的是要建立一个合作的软件环境，而不希望在单一虚拟机上运行多个应用，因为应用服务器已经实现了这个功能。这里的主要问题是，希望一个应用可以融合不同的可重用组件，而组件之间独立。更进一步说，希望一个应用动态的整合一组组件。例如，你有一个家庭服务器可以管理灯光和家用电器。一个组件可以让你通过网页控制灯光的开关，另一个组件允许你通过短信控制家用电器。 目的是允许各种不同的应用组件所实现的功能， 在不需要了解相互间细节的情况下，独立地添加进现有系统。67

18、0OSGi框架OSGi 按功能分层如下图所示ServicesLifeCycleModulesIExecutionEnvironmentJavaVMNativeOperatingSystemOSGi 框架功能分层示意图OSGi 服务平台标准的核心是提供一个通用、安全并且可管理的 Java 框架，该框架支持可扩展部署和下载的应用程序（称之为 bundle）。OSGi 设备可以下载和安装 bundle,并且可以在不需要的时候将其移除，在一个 OSGi 环境中，bundle 的安装、更新由框架统一动态管理，为此，需要框架对服务和 bundle 之间的依赖细节进行管理。由于 Java 平台的独立性和和动

19、态代码加载能力，bundle 的开发者可以很容易的开发出在嵌入设备上也能大规模部署的程序。表：OSGi 分层模型相关概念模型概念名称模型概念描述Bundles开发者开发出来的 OSGi 组件Services服务层为普通 Java 对象提供一种“发布-寻找-绑定”的模式，动态连接 bundlesLife-Cycle建立启动停止，更新和卸载 bundles 过程的接口Modules定义了 bundle 如何导入和导出代码Security安全控制ExecutionEnvironment定义了指定平台上可以运行的方法和类框架从功能上分为下面几个层次：安全层（Security）模块层（Modules）、

20、生命周期层（LifeCycle）、服务层（Services）。1）各层及其关系简介安全层基于 Java2 的安全机制，但是增加了一些限制，并且弥补了 Java 标准的一些不足。模块层定义了一个模块化的 Java 模型，它针对 Java 部署模式的一些缺点进行了改进，对bundle 或者隐藏包与其他 bundle 之间共享包有严格规定，模块层独立于生命周期层和服务层，使用时可以不需要生命周期层和服务层。生命周期层提供了对模块层的 bundle 进行管理的 API,而服务层提供了 bundle 之间的通信模型。生命周期层为 bundle 提供了生命周期管理的 API,为 bundle 提供了一个运

21、行时的模型，定义了一个 bundle 如何启动、停止、安装、卸载等，另外，生命周期层也提供全面的事件机制 API,允许管理 bundle 去控制和操作服务平台。服务层为 Javabundle 开发者提供了一个灵活、简单并且一致的编程模型，简化服务 bundle 的开发和部署，并以非耦合的服务标准（Java 接口）来实现。这个模型允许 bundle开发者使用他们自己的接口规范来绑定服务。这样就可以在运行时根据具体情况或需求选择接口的不同的实现。一致的编程模型可以帮助 bundle 开发者应对扩充的问题，因为在很多情况下，框架需要运行在各种各样的硬件设备上，一致的接口可以确保软件稳定的运行。在框架

22、中，bundle 可以在运行时通过框架服务注册中心选择一个可用的实现，bundle 可以注册新服务、接受关于服务状态的通知或者查找适合当前设备的服务等。框架可以支持动态安装新的 bundle,支持对一个已经部署后的 Bundle 进行更改、更新而不需要重新启动系统。2）安全层OSGi 安全层是 OSGi 服务框架的一个可选的层。它基于 Java2 安全体系结构，提供了对精密控制环境下的应用部署和管理的基础架构。安全层有三个要点：一是精密控制（finegrained）,在 OSGi 框架下的应用控制必须达到精细粒度的控制。二是可管理性，安全层本身没有定义 API 来控制应用，对安全层的管理交由生

23、命周期层。三是可选性，安全层是可选的。安全层的框架安全模型基于 Java2 规范。如果运行安全检查，那么需要遵循 Java2 安全架构规范。安全层涉及的内容有：代码验证、数字签名JAR 文件等。3)模块层模块性，简单来说，就是做尽可能少的假设，使事物保持本地性，使得事物之间不共享。模块 T是 OSGi 规范的核心，并且被应用到 bundle 的概念中。用 Java 的术语来说，bundle就是一个 JAR 文件。OSGi 隐藏了所有的 JAR 中的细节。Bundle 如果想使用其他 JAR 必须明确指出它需要引入的部分。默认情况下，bundle 之间没有共享。Java 平台只提供了对打包、部署

24、和对 Java 应用和组件检验的最小支持。因此，很多基于 java 的项目，如 JBossNetBeans,常常借助于专用的类加载器来创建用户模块层，以实现打包、部署和对 Java 应用和组件检验。OSGi 框架提供了对 java 模型化的一般和标准的解决方案。框架定义了模型化单元，称之为一个 bundle。一个 bundle 由 java 的类和其他资源组成，可以为终端用户提供功能。通过良好定义的方式，Bundle 可以和导入(importer)及导出(exporter)Bundle 之间共享 Java 包。在 OSGi 服务框架中，bundle 是仅有的需要部署的 Java 应用实体。Bu

25、ndle 以 JAR 文件的方式进行部署。JAR 文件使用 ZIP 的格式存储应用程序以及所需的资源。一个 bundle 是一个如下的 JAR 文件：(1)拥有提供服务所必须的资源。这些资源可以是 java 的 class 文件，或者是其他的数据如 HTML文件，帮助文件，图标文件等。一个 bundleJAR 文件也可以嵌入其他 JAR 文件作为资源，但是不支持多层嵌套的 JAR(2)有一个 manifest 文件描述 JAR 文件内容和 bundle 的信息。该文件处于 JAR 的头部，提供框架需要的安装和激活bundle所需的信息。 例如， 它对其他资源如JAR文件的依赖这种状态信息必须在

26、bundle运行之前加载。(3)可以在 OSGI-OPTt 件夹提供可选的文档信息，该文件夹可以位于 JAR 文件根目录或者它的子文件夹中。OSGI-OPT 文件夹中的内容都是可选的。例如，可以在其中保存 bundle 的源代码。管理系统可以删除该文件夹内容，以便于节约 OSGi 服务平台的存储空间。当一个 bundle 开始运行，通过 OSGi 服务平台，它开始对安装在平台内的其他 bundle 提供功能和服务。模块层涉及的内容有：运行环境、类加载机制、元数据处理、约束处理、解析过程、运行时类加载、本地代码加载、本地化、bundle 有效性、可选项、bundle 的需求、bundle 片段、

27、bundle 的扩展、安全等。4)生命周期层生命周期层提供了 bundle 的生命周期管理和安全控制的 API。本层是建立在在模型和安全层之上。生命周期层有四个要点：一是完整性，生命周期层必须提供包括 bundle 安装、启动、停止、更新、卸载和管理的所有状态的 API。二是深入性，API 必须要提供深入到框架实际状态的视点。三是安全，通过使用小粒度的权限来实现的安全环境下，API 必须可以在这样的环境下使用。但是安全必须要是可选的。四是可管理性，必须可以对远程平台的服务进行管理。在 OSGi 框架中，bundle 表现为 JAR 文件的形式。在模块层中说明了类加载这方面的含义。但是，模块层没

28、有定义 bundle 是如何安装、更新和卸载的，而生命周期操作对这些进行了定义。对于 OSGi 框架中安装的每一个 bundle,都有一个关联的 bundle 对象。 这个对象就用于 bundle 的生命周期管理。通常是由一个管理代理（Agent,也是一个 bundle）来完成。通过使用 BundleContext 对象来实现框架和安装的 bundle 之间的关系。 一个 BundleContext 对象描述了 OSGi 服务平台中一个 bundle 的执行上下文环境，作为框架之下的一个代理。与普通 bundle 相比，框架本身也是一个 bundle。这些 bundle 称之为系统 bundl

29、e。通过系统 bundle,框架可以注册供其他 bundle 使用的服务。例如包管理和权限管理服务。生命周期层涉及的内容有：bundle 实体、bundle 上下文环境、系统 bundle事件、框架的启动和关闭、安全等。5）服务层OSGi 服务层定义了一个和生命周期层紧密结合的动态协作模型。服务模型包括发布、查找和绑定模型。一个服务（service）就是一个通过服务登记来注册到一个或者多个 Java接口下的 Java 对象。Bundle 可以注册服务，查找服务和监听服务。任意数量的 bundles 可以注册同一类型的服务，任意数量的 bundles 可以得到同样的服务。如下图所示seivjce

30、raglatargMlisten服务示意图服务层有六个要点：一是协作性，服务层必须为 bundle 提供一种机制来发布、查找和绑定 bundle之间的服务，而无需事先知道 bundle 的信息。二是动态性，服务层机制必须能够处理外界或者是子结构的变化。三是安全，必须能够限定对服务的访问。四是深入性，对服务层的内部状态可以进行完全控制。五是版本控制，提供对 bundle 以及对它们服务更新的控制。六是持久性，在框架重启过程中提供方法来跟踪服务。在 OSGi 服务平台下，bundle 建立在一系列的相互协作的可用服务之上，这些服务共享一个服务注册中心。这样一个 OSGi 服务在语义上通过它的服务接

31、口来定义，并实现为一个服务对象。在服务接口中应该尽可能少的指定实现细节。OSGi 规定了很多常用的服务接口，以后还会增加。服务对象是属于 bundle 的，而且在 bundle 之内运行。bundle 必须要将服务对象注册到框架的服务注册中心，这样，才可以在框架的控制下来为其他 bundle 提供服务。提供服务的 bundle 和使用服务的 bundle 之间的依赖关系由框架来进行管理。例如，当停止一个 bundle后，这个 bundle 在框架中注册的服务必须要自动的取消注册。框架将服务映射到框架下的服务对象，而且，框架提供了一种简单而强大的查询机制，通过使用这种机制，bundle 就可以请

32、求它需要的服务。框架也提供了一种事件机制，这样，bundle 就可以接收到服务注册、更改和取消注册的消息。服务层涉及的内容有：服务事件、过期引用、过滤器、服务工厂、服务释放、取消注册服务、多版本导出、安全等。bundlebundle670OSGi小结OSGi（OpenServiceGatewayInitiative）提供了一个通用的软件运行平台，是一个隐藏了设备操作系统和硬件细节的中间件平台。OSGi 服务平台规范是一个开放的一般性架构，开发 OSGi 技术的目的是要建立一个合作的软件环境。OSGi 框架从功能上分为：安全层（Security）、模块层（Modules）、生命周期层（LifeC

33、ycle）、服务层（Services）oOSGi 安全层是 OSGi 服务框架的一个可选的层，它基于 Java2 安全体系结构，提供了对精密控制环境下的应用部署和管理的基础架构。OSGi 框架在模块层定义了模型化单元，称之为一个 bundle。一个 bundle 由 java 的类和其他资源组成，可以为终端用户提供功能。生命周期层提供了 bundle 的生命周期管理和安全控制的 API。OSGi 服务层定义了一个和生命周期层紧密结合的动态协作模型。服务模型包括发布、查找和绑定模型。Eclipse的插件机制体系结构670Eclipse发展历程以前比较常用的是分层式体系结构，比如 Linus、TC

34、P/IR 然而现在软件的生命周期越来越短、对软件功能的要求越来越强、需求变化也越来越快，一个软件的可扩展性，将很大程度决定了该软件的生命力。因此随着时间的推移，具有可扩展性的插件体系结构也开始慢慢成熟起来，在Java 界的 Eclipse,NetBeans 等，都是采用了插件体系结构的设计。Eclipse 插件与插件之间有依赖关系的，不过这些依赖关系都被 Eclipse 运行时内核统一管理着。Eclipse 运行时内核是健壮而微小的，主要具有如下功能：定义了插件必须符合的结构以及应该具有的信息；查找、装入、注销插件；管理着一个插件的注册表，并记录各插件的配置信息，以备调入插件时使用670Ecl

35、ips嘛系结构Eclipse 类似于“软总线”的体系结构，Eclipse 的核心部分（PlatformRuntime）类似于一条“即插即用”的“总线”，它提供了许多的“插槽”（扩展点：extensionpoint）。其余的部分都可看成类似于外部设备的“插件”（Plug-in）,可随时加载和卸载。更为灵活的是每个插件又提供了“插槽”可继续安装其他的插件。图Eclipse 分为 Eclipse 平台、JDTPDE 其他的插件几个部分。其中 Eclipse 平台是整个系统的基础，Eclipse 的核心。JDT 是提供了用于编辑、查看、编译、调试和运行 Java 代码的专门插件。PDE 构建于 Ecl

36、ipse 平台和 JDT 之上，提供了专门开发插件的工具。Eclipse 平台是在其上创建插件扩展的核心框架和服务的名称，是一个通用的基础架构。平台由平台运行时、工作空间、工作台、帮助、小组、调试构成。平台在结构上大致可分为核心（core）和用户界面（UI）两层。核心是与用户界面无关的基础结构，包含平台运行时和插件管理、工作空间和资源管理以及版本和配置管理。其中平台运行时又是 Eclipse 平台的核心。670Eclipsed台运彳亍时与OSGi容器运行时相当于一个微内核，是插件的核心引擎。它位于平台核心中最低级别的部分，由org.eclipse.osgi 和 org.eclipse.core

37、.runtime 两个插件组成，其他所有的插件都依赖于这两个插1）运行时的功能：a）定义插件的结构以及它们包含的实现详细信息（bundle 和类载入器）。b）查找和执行主要的 Eclipse 应用程序以及维护插件的注册表、扩展和扩展点。c）提供实用程序（例如，记录、调试跟踪选项、适配器、首选项库和并发性基础结构）。2）运行时工作原理：运行时管理着一个插件注册表（所有插件的标识），当 Eclipse 启动时，运行时内核.先是定位 JRE 的位置.然后启动startup.jar,扫描plugins和features目录下的插件配置文件对插件进行初始化注册到OSGi中，并保存配置文件中的信息。.然后

38、查找清单文件中声明的 extensionpoint 和 extension,将二者匹配，保存插件的依赖关系。最后启动应用。运行时对插件实行“lazyload”，只有当需要使用插件时才将其调入内存。不需要时选择适当的时机清除出内存。670插件扩展机制Eclipse 是众多“可供插入的地方”（扩展点）和“可以插入的东西”（扩展）共同组成的集合体。在我们的生活中，电源接线板就是一种“扩展点”，很多“扩展”（也就是电线插头）可以插在它上面。Eclipse 整个 IDE 就是一个插件，他提供了新的扩展点供其他插件来扩展。Eclipse 的插件网络Eclipse 的插件结构如下图所示， 包含扩展实现、 新

39、扩展点。 插件本身需要实现系统中已有的扩展点，才能插入到系统中，和已有的插件集成。插件本身也可以提供新的扩展点，在此基础上可以在让其它扩展出更强大功能。I/VLL?/变理i料件瓶T住也图Eclipse 中插件间不断的扩展，就形成了以下的插件网络，该网络自顶向下构成一个拓扑图。MA=剂广电产.图在插件的扩展过程中，首先是由宿主插件定义扩展点,展点规范创建才扩展，即扩展点的规范的实现，在运行过程中，插件将其注册到插件注册表中，这样宿主插件就可以通过插件注册表查找的其扩展。扩展点的暴露一个插件通过扩展点以期实现功能扩展，扩展点就是定义给其他插件进行扩展的规范，其它插件必修遵循这些规范才可用。具体实现，扩展点被定义为一些接口和相关的 xml 文档说明。在文档说明中指明了扩展点的 id,名称以及对应的接口定义。扩展点会暴露给其他插件和框架。对于其它插件，可以通过扩展点的定义找到相应的接口定义，实现其接口。对于框架，插件再加载一个插件时，首先会解析插件的 MAINFEST.MF 文件和plug.xml 文件，接着解析