我们已经在eclipse rcp框架上构建了一个大规模的应用程序。如果选择了大量的对象,比如4000或5000个对象,我们将在整个应用程序中面临这个问题。在这种情况下,后续操作需要时间,UI处于Not Responding状态。1.选择和右键单击上下文菜单显示2. 保持选择,更改视图并返回到先前的视图。3.保持选择,更改应用程序(如excel, word),然后返回查看。
我的分析表明,eclipse rcp需要花费时间来评估当前选定对象的菜单贡献和处理程序。我们也使用Property tester嵌套在迭代表达式中,我认为这需要时间来评估。痛苦的是,每次我切换视图时,它都会进行评估,并且不会缓存结果。
我需要你的意见:其他人以前遇到过这个问题吗?是否有好的方法来处理处理程序中的大选择,菜单贡献,这将提高性能。
提前感谢。普拉萨德~
可能主要问题出在你的属性测试器上,因为每次在你的应用中出现一些视觉变化时,这些测试器都会被评估:新外壳(如菜单,对话框,向导等)被打开,某些面板被展开/折叠,或者你切换视角或视图/编辑器,或者你切换应用程序。
可以作为第一步,您可以尝试禁用它们(或使它们为虚拟并且不做任何操作/或恒定操作),以查看它是否影响应用程序的性能。如果是这样,那么您可能会考虑重新设计您的应用程序,并用org.eclipse.ui.AbstractSourceProvider
和org.eclipse.ui.contexts.IContextService
的组合来替换属性测试器。
我不确定,当然,关于你的实际用例,但这里有一些想法:
- 源提供商也可以在plugin.xml中作为变量使用。
-
然后你可以注册一堆上下文(我不确定,当然,关于真实的用例,只是在这里建议),可以在某些条件下以编程方式激活:
final IContextService contextManager = (IContextService) activeWorkbenchWindow.getService(IContextService.class);contextManager。activateContext("你的上下文id");
-
另一个步骤是注册上下文激活侦听器:
final IContextService contextManager = (IContextService) activeWorkbenchWindow.getService(IContextService.class); contextManager.addContextManagerListener(new IContextManagerListener() { @Override public void contextManagerChanged(ContextManagerEvent contextManagerEvent) { if (!contextManagerEvent.isActiveContextsChanged()) { return; } [process context changes: possibly notify source providers about context changes] } });
让你的SourceProvider监听上下文的变化和刷新状态,当某些东西已经被实际改变了:
@Override public void contextActivated() { fireSourceChanged(getSourcePriority(), refreshState()); }
如果不是这种情况,或者在您的应用程序中不可能,那么,可能是,一些其他的解决方案将是在源提供程序中引入缓存或提高您的算法性能,例如,通过在多线程上并行执行一些长时间运行的操作。如果您使用的是Java 8,这应该相当容易。
当然,总有一种情况,SWT本身重绘所有小部件的速度很慢——在这种情况下,您可能应该考虑使用性能更好的标准SWT小部件的替代品。例如,使用natable代替默认的SWT/JFace查看器。
我希望这能给你一些启发