提示爲移動瀏覽器

Question

他在一個非常緩慢的GWT應用優化性能，

也許可以一些你分享他們的GWT移動開發的經驗？

我們正在開發一個漂亮的互動式網站，其中有許多可點擊的面板/按鈕，並且遇到巨大的瀏覽器遲緩問題。這是一個虛擬的不走，導航到下一頁有時需要一分鐘。

它可能是一個架構弱點：每個元素都是一個可能包含子視圖的視圖。並且每個視圖都由來自服務器的DTO支持。也許這樣的深層對象圖太多了，但我們正在努力專注於優化視圖渲染的效率，因爲拆分組件中的所有東西的想法對我們來說是非常寶貴的:)以下是我關心的一些問題，但有可能更多。

• 由於從谷歌I/O 2010大會視頻提示，我試圖用UiBinder的構建部件。但是這並沒有帶來很大的速度提升。我們使用很多面板 - HTMLTable，HTMLPanel，VerticalPanel， - 因爲承載其他視圖的每個視圖都應該以某種方式附加它們。可以用新的CellList替換它們是否有一些好處，或者是一個簡單的Horizo​​ntalPanel已經足夠輕量級了嗎？

• 頁面上可點擊小部件丟失。雖然一般建議是削減小部件，但我們確實需要它們來處理onMouseDown事件。什麼是最少的CPU密集型可點擊組件 - 帶有MouseDown處理程序的VerticalPanel，一個Button等？

• 一旦用戶點擊一個按鈕，就會發出PRC請求。我注意到，如果PRC調用停止了一段時間，那麼點擊按鈕的樣式呈現比單擊按鈕之後立即進行RPC調用要快得多。是否有一種模式指示如何觸發不會干擾樣式呈現的RPC調用。

• 性能分析報告（Firebug和Speedtracer）表明setInnerHTML（）和add（）調用了大部分負載。當視圖附加到他們的父母時應該調用add（），我不知道爲什麼setInnerHTML需要這麼長時間（根據視頻演示，他們應該非常快速）。有沒有合理的方法來優化add（）調用？我真的想不出有辦法做到這一點。

我欣賞每一個建議。謝謝。

Answer 1

從你所說的，add和setInnerHTML被稱爲很多。在我看來，你正在循環大量的對象並將它們添加到UI中。如果是這種情況，您可以使用IncrementalCommand（在GWT 2.1中棄用）或Scheduler.RepeatingCommand（GWT 2.1），讓瀏覽器在您添加大量元素的同時呼吸。此外，如果您嘗試以基於網格的格式顯示信息，您是否看過GWT 2.1中的新Cell based wigets？

另一個有用的提示是儘量避免使用Widgets。你提到你嘗試過使用UiBinder，但收效甚微。但是你還在使用標籤和麪板進行佈局嗎？一個很好的經驗法則是遵循凱利諾頓的「CAN I HAZ WIDGET」圖表，從Measure in Milliseconds: Performance Tips for Google Web Toolkit談話（幻燈片27）。他還鏈接到Widget inspector bookmarklet以幫助您追蹤多餘的Widget使用情況。這個想法是，你的大部分佈局和標籤都將使用標準的HTML和CSS來完成。