My<cod/>.net
Оптимизация для низкой пропускной способности
Мне поручено разработать веб-приложение, которое отображает очень большие географические данные. И одно из требований заключается в том, что он должен быть оптимизирован, чтобы PC все еще на наборах, распространенных в пригородах моей страны, мог использовать его.
Теперь мне разрешено использовать Flash и / или Silverlight, если это поможет с ограниченным временем разработки и пользовательским опытом.
Тяжелая часть географических данных разделена на плитки и загружена, как плитки карты в Google Maps, но это означает, что мне нужно много запросов HTTP.
Должен ли я пойти только с javascript + HTML? Я бы в конечном итоге с более быстрым приложением относительно Flash/Silverlight?, так как я могу сделать какой-то сложный алгоритм на этих 2 технологиях (например, DeepZoom). Развертывание настольного приложения, хотя, не может быть и речи, так как у нас нет столько средств на техническое обслуживание.
Это просто должно быть быстро... действительно быстрый..
p. s. быстрее в смысле "download faster"
Я не думаю, что вы найдете Flash или Silverlight собирается помочь слишком много для этого приложения. В любом случае вы будете использовать плиточные изображения, и изображения будут иметь одинаковый размер в обоих сценариях. Использование Flash или Silverlight может позволить вам добавить некоторые аккуратные анимации в приложение, но все, что вы получите здесь, будет дополнительной накладной для ваших клиентов при коммутируемых соединениях. Я бы придерживался простого Javascript/HTML.
Вы также можете посмотреть на асинхронную загрузку плиток через одну из доступных библиотек Ajax. Предположим, ваш пользователь может просматривать 9 плиток одновременно и scroll/zoom. загружать эти 9 плиток, которые они могут видеть, плюс все, что необходимо для обработки масштабирования этих плиток при первой загрузке; тогда вам нужно будет поиграть со стратегиями кэширования для предварительной выборки другой информации асинхронно.
В одном месте я работал с механизмом правил, который слишком долго возвращал результат, поэтому они решили представить пользователю экран "confirm this". Несколько секунд, которые потребовались пользователям, чтобы просмотреть и нажать кнопку Далее, было более чем достаточно времени, чтобы вернуть результаты. Это заставило приложение выглядеть молниеносно для пользователя, когда на самом деле это заняло немного больше времени. Вы должны помнить, что восприятие пользователем производительности так же важно в некоторых случаях, как и фактическая производительность.