GWT应用经验小结

 

1. pendingSrc

问题描述：Image的setUrl方法在第二次使用的时候，会出现“pendingSrc”的问题，导致图片无法显示。

原因分析：可能是GWT的bug，具体原因不详。

解决办法：通过DOM.setElementProperty()来设置src的值。

2.内存泄露

问题描述：刷新页面容易导致复杂的ui出现内容泄露。

原因分析：编码实现中很容易是的对象间出现循环引用，例如添加监听器的时候等，部分浏览器（尤其是IE）对此循环引用无法进行资源的释放。而在不断的刷新中，老的循环引用链没有正确断开，新的循环引用链又伴随着新对象的产生而产生，后果很严重。

解决办法：

• a) GWT自身提供了一套机制来解决这个问题。简单来说，就是在Widget（或其子类）的对象在被拆卸（detach）时，注销所有自身的所有事件监听，若自身实现了HasWidget接口，则会断开与它关联的其它Widget对象的关联。值得注意的是，若是应用在采用了GWT对第三方js库的封装，我就不能确定这种机制是否依然有效了。可以肯定的是，若是第三方js库内部就存在内存泄露的问题，那就算用GWT也避免不了。
• b) 对于除了Widget之外的其他自定义类实例若是也存在这种可能，建议解决策略是，将这些自定义对象暴露释放资源的方法（如clear，dispose或是destroy），并由Widget对象持有它们的引用，覆写Widget的onUnload方法，在其中调用它们的资源释放方法，这样就把自定义对象生命周期与Widget绑定在一起，即当Widget被销毁时，回调onUnload释放它们的资源。

3. 延迟加载

问题描述：复杂UI在初始化的过程中往往是很耗时的，而延迟加载是最常用用来应对它的一种模式。但延迟加载采用什么方式，以及什么时机加载确实难题。

解决办法：抛开必要的初始化预载外，可将延迟加载的时机放在页面部件被显示的时候再进行初始化。基于这个时机，在GWT中的解决模式是，覆写Widget或其之类的onLoad方法，因为这个方法会在Widget装载到页面时回调，将涉及后台数据请求或是页面的耗时计算的初始化逻辑放在onLoad中，就可以实现延迟加载。

4.事件与状态

问题描述：UI复杂度直接体现在各个子部件之间的复杂对象关联，这种关联基触发事件或是传递状态所必要的。但是，这也带来许多棘手的问题，如循环引用、高耦合度、复用性和维护性差等。

解决方法：

• a) 首先，暴露一个全局可访问的数据区，可以无障碍的共享数据；其次，设计一个统一的机制来控制数据区的数据写入，避免写数据发生的冲突；最后，暴露数据写入的监听回调接口，利于状态被改变时可以触发事件。这样，大部分的页面部件可以集中依赖这个全局数据区来触发事件或传递状态，降低复杂的网状关联。此外，可以全局数据区进行集中初始化和销毁，使得资源被合理和可见的控制；
• b) 利用Gwt提供的History，建立自己的消息传递机制。因为History提供的都是静态方法可全局访问，通过newItem来写自己的消息串，比如模仿Url传参(abc?k=v&n=l)；再通过想History注册监听，在onHistoryChanged的回调中对消息串进行解析，并调用其他逻辑。

二者比较起来，各有优势，根据具体情况选用或混用。History优势在于可通过地址携带状态，很轻量，不用操心初始化和销毁；劣势是状态必须是字符串，编码和解码是个麻烦事，当状态信息很多时，url自然会很长，所以...。

5. 页面数据刷新

问题描述：很多时候，我们希望在程序中控制页面部件装载（attach）和拆卸（detach），以刷新数据显示。而GWT这方面的方法（如onAttach，onDetach，onLoad，onUnload）都是保护可见的。

解决办法：

• a) 通过集成Widget或子类，改写上述方法的可见性，暴露给其他控制类调用；
• b) 很多Panel类提供了setWidget方法，这个方法会用新的对象替换老的，这个过程会先触发老的对象进行拆卸（detach），此后会装载（attach）新的对象。若是新老对象是同一个对象即可实现对象的更新。

 

评论

1 楼 wangying95599 2010-08-03  

1. pendingSrc

解决办法：通过DOM.setElementProperty()来设置src的值。

如果项目编译成支持多个浏览器，如
<set-property name="user.agent" value="ie6,ie8,gecko,gecko1_8,safari,opera"/>
这个方法图片也不能正常显示

如果是一个浏览器
<set-property name="user.agent" value="ie8"/>
就正确