企业官网建设流程全解析

做Eclipse RCP开发的人应该都清楚，e4是一个分水岭。从Eclipse 4.0开始，UI层从原来基于Workbench的繁杂事件系统，改成了基于应用模型（Application Model）的声明式架构。视图的实例化方式、生命周期、布局管理，全部围绕Application.e4xmi这个核心模型展开。很多从e3迁移过来的兄弟，第一步就卡在“明明我的视图类写好了，为什么启动后就是不显示？”或者“动态创建了一个视图，却总是被并成一个标签页，位置完全不受控制。”这篇博文就专门解决这两类问题：e4视图到底是怎么被实例化的，以及如何用模型和API去控制它的显示位置和布局。适合正在做Eclipse RCP插件开发、OSGi容器集成，或者打算从e3往e4迁移的同学参考。

1. e4视图实例化背后的应用模型

1.1 为什么e4要搞一个Application.e4xmi

Eclipse 3.x时代，Workbench窗口、编辑器、视图都是靠一堆类加plugin.xml扩展点拼起来的。程序一启动就开始创建各种Part，布局写死在代码里，想动态挪位置很难。e4把这些全部拆开：先用一个Application.e4xmi描述整个界面的树形结构，代码只是模型上的“贡献”。模型文件是EMF模型，可以在运行时被EModelService任意读取和修改。以前要改布局，你可能会在createPartControl里new一个CTabFolder，然后把视图的Composite塞进去；现在直接在模型层面维护PartStack和Part，视图类本身不知道自己在哪个Stack里面。这是架构上最核心的改变。

还有一个好处是序列化。e4xmi本质上是一份XML，也是模型持久化后的产物。你可以把当前工作台的布局状态保存下来，下次启动原样恢复，这在e3时代很痛苦。我做过的一个日志分析工具，需要记住用户把“日志详情”视图放在左边还是右边，放到底部还是堆叠，改前非常麻烦，改后只要在启动时从model中读一下布局节点，设置回来即可。

1.2 视图实例化的完整链路

我们写一个简单的视图类，它不需要继承任何类，只是个普通Java类：

package com.example.rcp.views; import javax.annotation.PostConstruct; import org.eclipse.swt.widgets.Composite; import org.eclipse.swt.widgets.Label; public class SampleView { @PostConstruct public void create(Composite parent) { Label label = new Label(parent, 0); label.setText("Hello e4 View"); } }

在Application.e4xmi中，把这个类绑定到一个MPart上，给定一个唯一ID和ContributionURI：

<add xsi:type="basic:Part" xmi:id="_..." elementId="com.example.rcp.view.sample" contributionURI="bundleclass://com.example.rcp/com.example.rcp.views.SampleView" label="示例视图"/>

真正打开视图的瞬间，e4会做三件事：第一，根据ContributionURI找到对应的bundle和类；第二，用ContextInjectionFactory创建并填充依赖，比如把当前窗口的MWindow、EPartService、IEclipseContext注入进去；第三，调用@PostConstruct方法，并把父容器Composite传进去。如果没找到ContributionURI所指向的类，不会在启动时报错，而是会在视图第一次需要显示时才抛出ClassNotFoundException。这一点和e3很容易混淆——e3启动时扫描扩展点并实例化，e4是延迟到使用点。

1.3 实例化时机与生命周期钩子

e4中“不一定所有Part都在启动时创建”这个特性对布局控制影响很大。你在e4xmi的Window里加了很多PartStack，每个Stack下有Part，不代表启动时都会创建。只有被用户打开、被布局恢复逻辑需要显示、或者代码调用showPart，才会真正执行@PostConstruct。所以你的视图类可以放心地把重量级数据库连接放到@PostConstruct里，只要用户不打开，就不占资源。

生命周期上，除了@PostConstruct，还有@Focus和@PreDestroy。@Focus控制在视图获得焦点时要做什么，一般用来把焦点给到内部某个控件；@PreDestroy用于释放资源。要注意，用户关闭视图并不等于销毁MPart，除非这个MPart配置了“closeable”且从模型中移除了。很多坑都出在这里：视图被关闭后再次打开，@PostConstruct又执行了一遍，但上一次的旧实例可能还挂在内存里。所以一次典型生命周期是：create -> focus -> ... -> focus（切换） -> destroy。对象是同一个还是新的，取决于Part模型是否被销毁。

2. e4中视图实例化的常用方式与选型

2.1 静态声明：直接维护e4xmi节点

如果你的视图数量固定、布局也稳定，静态声明是最简单的方式。操作过程并不复杂：打开Application.e4xmi，在Window的Children里右键Add Child -> PartSashContainer，或直接在某个PartStack下Add Child -> Part。新加Part后，设置ElementId、Label、IconURI、ContributionURI。如果希望启动后默认显示，就把该Part作为当前Stack的Children之一，并把Stack设置成当前active部分；不想默认显示，可以放到Window的Shared Elements元素中，让其他地方通过Placeholder引用。

静态声明的优点是用“Application.e4xmi可视化编辑器”能直接看到布局，拖拽分割条调整比例，改动立刻生效。缺点是多人协作时模型文件冲突频繁，而且如果你用了版本控制，xmi的diff可读性很差。我一般建议静态布局只放核心框架，业务视图都走动态创建。

2.2 动态创建：用EModelService生成MPart

当你要根据用户操作动态增加一个“任务列表”时，静态声明就不够了。最典型的场景是“多个同类型视图”：例如打开一个监控页，每次打开都能创建一个新的视图实例，互不干扰。此时就应该动态创建MPart，再插入到目标布局中。

MPart part = modelService.createModelElement(MPart.class); part.setElementId("com.example.rcp.view.monitor." + System.currentTimeMillis()); part.setLabel("监控-" + index); part.setContributionURI("bundleclass://com.example.rcp/com.example.rcp.views.MonitorView"); part.setCloseable(true); MPartStack stack = modelService.findElements(window, "com.example.rcp.stack.right", MPartStack.class, null).get(0); stack.getChildren().add(part); partService.showPart(part, PartState.ACTIVATE);

这里创建的就是普通的MPart，不是占位引用。需要注意：elementId要唯一，否则EPartService在查找时会找到旧的，导致新视图没有实例化。showPart的第三个参数是PartState，一般用ACTIVATE创建并激活，或VISIBLE创建但不聚焦。这个API既可以通过ID查找已有Part，也可以直接把刚才new出来的MPart传进去。如果传给showPart的MPart还没挂到模型上，它会先尝试在模型中查找，找不到可能报错，所以先把part加到stack再show。

2.3 通过PartDescriptor实现“同类型多实例”

e4还有一个设计容易被忽略：PartDescriptor。它有点像模板，描述了某个Part的类、图标、标签，但它不直接出现在布局里。需要时通过EPartService.createPart(descriptorId)得到新的MPart，再插入对应Stack。这种方式特别适合“动态编辑器”或“多实例视图”。比如从文件管理器双击一个日志文件，你会创建一个新的日志视图实例来展示不同文件。假设我们在Application.e4xmi里定义了PartDescriptor：

<descriptors xsi:type="advanced:PartDescriptor" elementId="com.example.rcp.log.view" contributionURI="bundleclass://com.example.rcp/com.example.rcp.views.LogView" label="日志查看" allowMultiple="true"/>

代码里：

MPart part = partService.createPart("com.example.rcp.log.view"); part.setLabel("日志-" + fileName); MPartStack targetStack = ...; targetStack.getChildren().add(part); partService.showPart(part, PartState.ACTIVATE);

这里有个关键属性：allowMultiple是否允许多实例。如果设为false，createPart会返回已有Part；设为true则会每次创建新的。视图实例化控制到这里才算真正完整：设计时用Descriptor定义“我能开这种视图”，运行时用createPart生成“这个视图的一个实例”，布局控制用EModelService决定“这个实例放到哪个Stack、什么位置”。

2.4 兼容e3视图：还能用org.eclipse.ui.views吗

有些老项目还留着一堆ViewPart子类，到e4里不用重写。可以在plugin.xml里继续声明org.eclipse.ui.views扩展点，然后在Application.e4xmi中用一个“Legacy Part”绑定。准确说，e4兼容层会通过E4Workbench把e3扩展点转换为模型中的Part，但前提是应用用到了org.eclipse.ui.e4兼容层。如果你的RCP完全是纯e4应用，不带IDE兼容层，建议还是迁移成普通Java类加@PostConstruct。不要以为所有e3的IViewPart都能无缝在纯e4上跑。迁移步骤通常是三步：把createPartControl里的代码挪到@PostConstruct；把setFocus里的代码挪到@Focus；删除IViewPart接口，改成普通类。这样最能利用e4依赖注入，避免兼容层维护成本。

2.5 实例化方式对比

选型上我的经验是：能被静态声明覆盖的就别动态创建，动态创建能解决的别上Descriptor。因为Descriptor虽然灵活，但会让布局控制多一层查找逻辑，出错时更难排查。老项目迁移则优先走兼容层，稳定后逐模块替换。

3. 布局控制核心模型与API

3.1 布局元素的树形结构

e4布局是一个树：根是MWindow，Window里可以放MPartSashContainer、MPartStack、MPart、MTrimBar等。MPartSashContainer负责分栏，每个分栏里可以放PartStack或另一个SashContainer；PartStack是一个带标签页的容器，Part是具体视图或编辑器。可以理解为：SashContainer是“墙上的隔断”，PartStack是“一组标签”，Part是“页面内容”。一个视图要出现在哪里，核心就是把它挂到哪一层、哪个PartStack下。

所有模型元素都是MUIElement，都有elementId、visible、toBeRendered、containerData等属性。containerData是字符串形式的权重，比如“30”表示这个区域占剩余空间的比例。调整窗口分割比例，本质就是修改SashContainer两个子节点的containerData。如果你在代码里直接改动这个字符串，记住要成对改，否则会出现一个区域无限压缩。

3.2 用e4xmi编辑器拖布局

Eclipse IDE里双击Application.e4xmi，会打开一个可视化编辑器。左边是树，右边是实时预览。你可以拖拽PartSashContainer、PartStack到窗口里，然后在属性面板设置拆分方向和比例。注意：这个编辑器不是万能的，模型文件一旦出现引用错误，预览区可能空白，但不影响代码运行。很多新手看到编辑器渲染不出东西就以为模型错了，其实可能是某个ContributionURI类不存在，或者某个Placeholder引用了不存在的Part。运行时提示的bug只在创建视图时可见。

我整理了一个简单的经验：调整静态布局时，尽量在“Source”视图里直接改XML，可视化编辑器容易生成一些无用节点。特别是当你要加一个带一定初始大小的Stack时，直接在<window>下写：

<children xsi:type="basic:PartSashContainer"> <children xsi:type="basic:PartStack" elementId="left.stack"> <children xsi:type="basic:Part" elementId="view.a" contributionURI="..."/> </children> <children xsi:type="basic:Part" elementId="view.bottom" contributionURI="..."/> </children>

注意直接放Part不进Stack也可以，e4会把裸Part自动包装？不完全，它会把Part作为独立标签显示在Root？其实不好。还是建议所有视图都放在PartStack中，否则拖拽、标签化都会出问题。

3.3 运行时用EModelService移动视图

代码控制布局的最核心API是EModelService。它有三个高频方法：findElements、move、insert。findElements从模型某节点往下找指定类型的元素；move把元素从一个父节点移到另一个父节点；insert把元素以相对位置插入到某个参考元素附近。

示例：把某个视图从左边Stack移动到右边Stack：

MPart part = modelService.findElements(window, "view.a", MPart.class, null).get(0); MPartStack targetStack = modelService.findElements(window, "right.stack", MPartStack.class, null).get(0); modelService.move(part, targetStack); partService.showPart(part, PartState.ACTIVATE);

注意move并不是总能成功。如果part处于当前显示状态，它必须先脱离原UI容器再移动到新容器。如果模型仍在启动阶段，没问题。如果你在UI线程执行，可能会有短暂的闪烁。更平滑的方式是先新创建一个Part，然后删除旧Part，但这样会丢失状态。最好的办法是让视图类自身状态绑定到可持久化的对象，而不是保存在Part实例中。

insert方法用于创建新分栏：

MPartStack newStack = modelService.createModelElement(MPartStack.class); modelService.insert(newStack, existingStack, SWT.RIGHT, 0.3f); MPart newPart = ...; newStack.getChildren().add(newPart); partService.showPart(newPart, PartState.ACTIVATE);

这里的0.3f是分割比例，表示新Stack占右侧30%宽度。SWT.RIGHT决定了分割方向。这个方法比手工构建SashContainer简单得多，也是最推荐的动态布局方式。

3.4 多窗口与Perspective布局

e4的Window并不只一个。一个RCP应用可以定义多个Window，每个Window有自己的布局。Perspective切换在e4里其实是切换Window内的一组布局。可以在模型里创建多个Perspective，每个Perspective内部包含自己的PartSashContainer、PartStack，还可以通过Placeholder引用Window的Shared Elements。这样切Perspective时，视图实例不会销毁，只是重新排列显示。

这里最常见的需求是“把一个视图放在所有Perspective共用的位置”。做法是把该Part放到Window的Shared Elements区域，然后在各个Perspective中通过Placeholder引用它。Placeholder有个ref属性指向Shared Element的Part。当Perspective激活时，Placeholder对应区域会显示Part内容。这个机制和e3的ViewSite有相似之处，但更干净。

4. 实战：实现一个可动态显隐、可调整位置的视图布局

4.1 场景描述

假设我们在做一个数据分析平台，主窗口左侧有一个“导航”视图，右边是一个“结果”视图，底部有一个“日志”视图。用户希望点击按钮后，能把“日志”视图弹出来，并停靠在右侧下方；再点一次可以最小化或关闭。切换过程中视图实例不能重复创建，日志内容要保留。这个场景覆盖了视图实例化、动态布局、显隐控制三个核心。

4.2 关键代码实现

在视图中注入EPartService和EModelService：

public class ToolbarContribution { @Inject private EPartService partService; @Inject private EModelService modelService; @Inject private MWindow window; @Execute public void toggleLogView() { MPart logPart = modelService.findElements( window, "com.example.rcp.view.log", MPart.class, null) .stream().findFirst().orElse(null); if (logPart == null) { logPart = createLogPart(); } if (logPart.isVisible()) { partService.hidePart(logPart, true); } else { partService.showPart(logPart, PartState.ACTIVATE); } } private MPart createLogPart() { MPart logPart = modelService.createModelElement(MPart.class); logPart.setElementId("com.example.rcp.view.log"); logPart.setLabel("日志"); logPart.setContributionURI("bundleclass://com.example.rcp/com.example.rcp.views.LogView"); MPartStack bottomStack = modelService.findElements( window, "bottom.stack", MPartStack.class, null) .stream().findFirst().orElse(null); if (bottomStack == null) { bottomStack = modelService.createModelElement(MPartStack.class); bottomStack.setElementId("bottom.stack"); modelService.insert(bottomStack, modelService.findElements( window, "main.sash", MPartSashContainer.class, null).get(0), SWT.BOTTOM, 0.25f); } bottomStack.getChildren().add(logPart); return logPart; } }

4.3 代码背后的细节

上面代码有几个关键点：findElements返回List，要处理空列表。如果找不到Part，说明还没创建；如果找不到Stack，说明模型里还没这个容器，需要动态insert。hidePart(logPart, true)中的true表示把Part从模型中移除。如果传false，只是隐藏，但以后重新show还能找到原实例。这里用true可以清理模型，避免“伪残留”。如果希望下次保留状态，建议用false，或者把Part移到Shared Elements而不是销毁。

containerData权重：insert的第三个参数ratio就是权重比例。但是如果你通过模型已有多个Stack，这个ratio不一定严格生效，因为SWT布局还要考虑最小尺寸，特别是窗口太小时，Sash会做妥协。所以不要指望用户每次拖动后的比例都按你的数值恢复，这是正常的。

还要注意，动过模型后，除非模型已经持久化，否则重启后布局会回到e4xmi定义的样子。如果想记住用户布局，要自己保存并恢复。e4有MApplication的持久化状态，但比较底层；我一般会把感兴趣的stack/part的elementId和containerData序列化到Preference，启动时再重放。

4.4 布局快照与恢复的简单实现

保存布局时，遍历当前Window所有MPartStack和MPartSashContainer，记录每个节点的elementId和containerData，再把当前Stack的selectedElement写入Preference。恢复时，先按elementId找到对应模型节点，逐个设置containerData，再用findElements把Part找到并移到对应Stack；最后用asyncExec延迟调用partService.showPart激活目标视图。要分清楚哪些是模型里本来就有的节点，哪些是运行期动态创建的。动态创建的节点恢复前需要先创建好，再设置属性，否则findElements什么都找不到。

5. 常见问题与排查技巧实录

5.1 视图不显示，但也没有异常

这个太经典了。代码里@PostConstruct没执行，通常是Part没有被放到可见的PartStack中，或者PartStack被放到了被隐藏的容器里。排查分三步：一，在Application.e4xmi的Window节点下，确认这个Part的层级是Window的Children，而且父节点visible和toBeRendered都是true；二，检查elementId有没有重复，EPartService.showPart按ID查找时可能找到的是另一个Part；三，在视图类的构造方法或@PostConstruct里打日志，看有没有被调用。如果没有调用，就说明模型里这个Part没被实例化。

还有一种是“视图在另一个Perspective里”。如果当前Perspective的布局没有引用该Part，当然不显示。这种情况不是bug，是设计。

5.2 能显示，但窗口里只有一个标签，不能拖拽

如果你把一个Part直接加到PartSashContainer，而不是PartStack，那么它作为一个独立面板，当然没有标签页，也没有拖拽把手。老老实实让所有Part都放进PartStack里，哪怕是只有一个Part的Stack。如果你遇到了“多个视图跑到同一个Stack，我想拆成左右两个”，用EModelService.insert把其中一个Part连同它的Stack一起插到右侧，不要在同一个Stack内部做水平排列。

5.3 动态创建视图后无法拖动到其他位置

这通常是因为你创建的PartStack缺少必要的模型属性。e4视图本身支持拖拽标签。如果你的Part的containerData没有设置，或者被放在一个不允许拖拽的容器里，就会出问题。检查MPartStack的elementId是否设置，有些拖拽逻辑需要依赖elementId做上下文绑定。另一种常见原因是：你把Part直接加到了Stack，但Part没有设置closeable，用户拖拽时系统尝试先关闭再创建，结果失败。设置closeable=true可以解决。

5.4 视图数据丢失，每次打开都是新的

如果你每次显示都调用createPart或手工创建MPart，而没有复用之前的Part，那么视图实例必然重建。日志、状态等自然是空。解决方法是维护一份Map存放已经打开的Part，或者在Application.e4xmi的Shared Elements区域保留Part，用Placeholder切换。动态视图多实例场景，也要在“业务对象”里保存数据，不能依赖Part自身缓存。

5.5 启动时报“找不到或无法加载主类”

严格说这不是e4布局的问题，但我们在Eclipse运行时环境里经常碰见。比如你启动工作台时选择了某个Java Application配置，主类却指向Tomcat的Bootstrap，那必然报错。排查时先看Run Configuration的Main Type对不对，再检查JRE是不是缺失。如果是RCP应用，运行配置的main类应该是org.eclipse.e4.ui.workbench.swt.E4Application一类的类，不要设成用户自己的Main。还有一类是bundle加载不到，提示ClassNotFoundException，这时要检查plugin dependencies是否把对应bundle加入了Launch配置的Plug-ins列表。这类问题十有八九是Run Configuration里默认选中的插件不全，手动勾选需要的bundle即可。

5.6 布局恢复比预期复杂

最后分享一个小技巧：如果你的RCP需要保存用户自定义布局，别只保存MPart的位置，还要保存它是否被最小化、当前激活的是哪个Part。e4自身有MPartStack的选中项，恢复时先恢复Stack，再设置selectedElement，否则用户下次看到的是上次激活之外的视图。我记得在早期版本中有个PartState.create和activate的时序问题，如果你恢复布局时直接showPart，可能因为Part还没完成初始化就切换焦点，导致焦点丢失。稳妥做法是恢复完所有Part后，再用一个Display.asyncExec延迟调用partService.showPart。这个时序坑我踩了不止两三次。

视图实例化不是简单“new一个类”，它背后是应用模型、依赖注入、生命周期管理；布局控制也不是粗暴调用setLayout，而是研究PartStack、PartSash