我在2年前读过有关UiBinder性能的答案https://stackoverflow.com/a/3755675/1067931 并决定对其进行测试。
我构建了一个非常复杂的布局，其中包含许多按钮，而面板则在另一个内部。 版本1 的布局完全以UiBinder xml构建，而版本2 纯粹以编程方式构建。
我将两个版本部署到App Engine并运行两个版本，同时在每次运行之前清除浏览器缓存。 版本1 （UiBinder）在 ~12秒之后加载，而版本2 在 ~3秒之后加载，所以它真的劝阻我不要使用UiBinder。你有不同的印象吗？
答案 0 :(得分：2)
UiBinder，就像任何GWT生成器一样，生成Java代码。首先，阅读生成的内容并将其与您手动编写的内容进行比较（将-gen选项传递给GWT编译器或DevMode，使其将生成的代码写入磁盘）。
UiBinder闪耀的地方是HTMLPanel和I18N，因为它使代码比用Java编写时更具可读性。
GWT 2.5还引入了IsRenderable和RenderablePanel作为实验性功能，但是可以在某些条件下提升你的性能（它们用于提升Orkut的性能）。同样，UiBinder使其易于使用（IsRenderable否则需要以适当的顺序调用其方法，并在适当的时间获得最大的性能; UiBinder使其透明化。遗憾的是，除IsRenderable之外没有其他RenderablePanel小部件，因此只有在您创建自己的实现IsRenderable的小部件时才会有所帮助。 IsRenderable的运作水平非常低。
一般来说，UiBinder的执行速度不应低于手写代码（当然，对于小部件的等效排列）。当人们说UiBinder表现更好（在IsRenderable之外）时，它鼓励你使用HTMLPanel而不是面板进行布局。例如，包含HTML HTMLPanel或集合<table>的{{1}}执行速度比<div>或一堆FlexTable更快（假设您赢了）不需要动态修改布局。
答案 1 :(得分：1)
对我而言，UiBinder-Code可能会导致更长的启动时间。这就是为什么：
想象一下，您正在尝试在视图中定义20个按钮。在声明性布局中，您将明确声明每个按钮，而在命令式布局中，您很可能使用for循环。似乎这会导致命令式布局的JS大小变小。
同时考虑到在实际应用中，这种差异可能是微不足道的，因为视图通常是项目中最小的部分。
documentation of UiBinder似乎暗示，它更多的是关于运行时性能，所以如果你有兴趣减少加载时间我建议你看看
Code Splitting，
HTML5 Appcache
and general performance tips（虽然有点过时，但仍非常有用！）
感谢您提出这个问题，我搜索了一个针对GWT功能的广泛性能测试套件（比如UiBinder），但是空白了。