Советы по оптимизации производительности в очень вялом приложении GWT для мобильных браузеров - PullRequest
4 голосов
/ 12 октября 2010

Его,

Может быть, некоторые из вас могут поделиться своим опытом разработки мобильных приложений на GWT?

Мы разрабатываем симпатичный интерактивный веб-сайт с множеством интерактивных панелей / кнопок и испытываем огромную медлительность браузера. Это виртуальный запрет, переход на следующую страницу занимает больше минуты.

Это может быть слабостью архитектуры: каждый элемент - это представление, возможно, содержащее подпредставления. И каждое представление поддерживается DTO, который приходит с сервера. Может быть, такой глубокий объектный граф слишком велик, но мы пытаемся сконцентрироваться на оптимизации эффективности рендеринга представлений, так как идея разделения всего на компоненты нам так дорога :) Вот некоторые моменты, которые меня беспокоят, но, вероятно, есть больше.

  • Как показывают видео из конференции по вводу-выводу Google 2010, я пытался создавать виджеты с помощью UiBinder. Но это не принесло значительного улучшения скорости. Мы используем множество панелей - HTMLTable, HTMLPanel, VerticalPanel, - поскольку каждое представление, в котором размещены другие представления, должно каким-либо образом присоединять их. Может ли замена их новым CellList принести пользу или простая горизонтальная панель уже достаточно легкая?

  • На странице потеряны интерактивные виджеты. И хотя общая рекомендация заключается в сокращении виджетов, нам нужны все они для обработки событий onMouseDown. Какой компонент с наименьшей нагрузкой на процессор будет активен - VerticalPanel с обработчиком MouseDown, Button и т. Д.

  • Как только пользователь нажимает кнопку, выдается запрос PRC. Я заметил, что если PRC-вызовы останавливаются на некоторое время, тогда стиль рендеринга нажатых кнопок происходит намного быстрее, чем если бы RPC-вызов выполнялся сразу после нажатия кнопки. Существует ли шаблон, который диктует, как вызывать вызов RPC, который не мешал бы стилевой визуализации.

  • Профилирующие отчеты (Firebug и Speedtracer) указывают, что setInnerHTML () и add () вызывают учетную запись для большей части нагрузки. add () должен вызываться, когда представления привязаны к их родителям, и я не знаю, почему setInnerHTML занимает так много времени (согласно видео-презентациям они должны быть очень быстрыми). Есть ли разумный способ оптимизировать вызовы add ()? Я действительно не могу придумать, как это сделать.

Я ценю каждое предложение. Благодарю.

1 Ответ

4 голосов
/ 17 октября 2010

Из того, что вы сказали, add и setInnerHTML называются много. Мне кажется, что вы просматриваете большое количество объектов и добавляете их в пользовательский интерфейс. В этом случае вы можете использовать IncrementalCommand (устарело в GWT 2.1) или Scheduler.RepeatingCommand (GWT 2.1), чтобы позволить браузеру дышать, пока вы добавляете много элементов.

Кроме того, если вы пытаетесь отобразить информацию в формате сетки, вы смотрели на новые ячейки на основе ячеек в GWT 2.1?

Еще один полезный совет - стараться избегать использования виджетов как можно чаще. Вы упомянули, что пытались использовать UiBinder, но без особого успеха. Но вы все еще используете Label и панели для макета? Хорошее эмпирическое правило - следовать диаграмме Келли Нортона «МОЖЕТ БЫТЬ HAZ WIDGET» из Мера в миллисекундах: Советы по повышению эффективности для Google Web Toolkit talk (слайд 27). Он также ссылается на букмарклет инспектора виджетов , чтобы помочь вам отследить избыточное использование виджетов. Идея заключается в том, что большая часть вашего макета и надписей будет выполняться с использованием стандартных HTML и CSS.

...