Оптимизация для низкой пропускной способности
Мне поручено разработать веб-приложение, отображающее очень большие географические данные. И одно из требований состоит в том, что он должен быть оптимизирован, чтобы ПК, все еще подключенный к коммутируемым линиям, распространенным в пригородах моей страны, также мог его использовать.
Теперь мне разрешено использовать Flash и / или Silverlight, если это поможет с ограниченным временем разработки и пользовательским интерфейсом.
Большая часть географических данных разбита на фрагменты и загружена как фрагменты карты в Google Maps, но это означает, что мне нужно много HTTP-запросов.
Должен ли я использовать только javascript + HTML? Могу ли я получить более быстрое приложение для Flash / Silverlight? Поскольку я могу выполнить сложный алгоритм на этих двух технологиях (например, DeepZoom). Однако о развертывании настольного приложения не может быть и речи, так как у нас не так много средств на обслуживание.
Просто нужно быть быстрым ... очень быстрым ...
p.s. быстрее означает "быстрее скачивать"
Ответы 5
Я не думаю, что вы обнаружите, что Flash или Silverlight слишком сильно помогут в этом приложении. В любом случае вы будете использовать мозаичные изображения, и изображения будут одинакового размера в обоих сценариях. Использование Flash или Silverlight может позволить вам добавить в приложение некоторую аккуратную анимацию, но все, что вы получите здесь, будет дополнительными накладными расходами для ваших клиентов при коммутируемых соединениях. Я бы придерживался простого Javascript / HTML.
Допустимо ли что-то вроде Шестерни? Это позволит вам хранить данные локально, чтобы ограничить повторные запросы.
Я бы также отказался от flash и Silverlight и сразу перешел на javascript / AJAX. jQuery - это огромное удовольствие.
Я предлагаю вам изучить Silverlight и DeepZoom
Я считаю, что Microsoft Морской дракон - ваш ответ. Однако я не уверен, доступно ли это разработчикам.
Похоже, что некоторые из них попали в Silverlight
Вы также можете посмотреть на асинхронную загрузку ваших плиток через одну из доступных библиотек Ajax. Допустим, ваш пользователь может просматривать 9 плиток за раз и прокручивать / масштабировать. Загрузите те 9 плиток, которые они могут видеть, плюс все, что нужно для обработки масштабирования этих плиток при первой загрузке; тогда вам нужно будет поиграть со стратегиями кэширования для асинхронной предварительной выборки другой информации.
В одном месте, где я работал, движку правил требовалось слишком много времени, чтобы вернуть результат, поэтому они решили предоставить пользователю экран «Подтвердить это». Несколько секунд, которые потребовались пользователям, чтобы просмотреть и нажать «Далее», было более чем достаточно, чтобы вернуть результаты. Это сделало приложение более быстрым для пользователя, хотя на самом деле это заняло немного больше времени. Вы должны помнить, что восприятие пользователем производительности в некоторых случаях так же важно, как и фактическая производительность.