PreRender
Концепция предварительного рендеринга предстоящего компонента, чтобы пользователь не ждал.
Понимание PreRender
Подумайте о просмотре Tinder для пролистывания изображений. Скажем, эти изображения огромны по размеру в несколько мегабайт. Теперь, если вы хотите отобразить каждое изображение после того, как пользователь провел по текущему, изображение будет загружаться в течение нескольких секунд, прежде чем отобразить его на самом деле (например: 2 секунды для каждого изображения, которое будет отображаться). Любой пользователь потеряет терпение из-за такого медленного рендеринга.
<img src={current_image} />
Как я могу решить эту проблему?
Используйте два места для изображений вместо одного. Сначала загрузите данные первого изображения и выполните рендеринг в первом слоте как обычно. А вот и второй трюк. Вместо того, чтобы ждать, пока пользователь проведет пальцем по экрану, а затем загрузить изображение, начните рендеринг изображения сразу после того, как первое изображение будет назначено на слот один.
Поступая таким образом, мы не блокируем отображение текущего изображения, а вместо этого заранее визуализируем следующее. Теперь мы скрываем предварительно визуализированное изображение от пользователя, используя hide className или устанавливая высоту 0 пикселей в случае React Native.
Рассматривая данные как массив из двух элементов и отслеживая активный индекс, мы можем решить, какие данные извлекать, а какие отображать.
onSwipe() { // make pre-render the active image const availableSlot = this.state.active; if (this.state.active === 0) { this.setState({ active: 1 }); } else { this.setState({ active: 0}); } // now start fetching the next image and assign it to the availableSlot const images = this.state.images; images[availableSlot] = newImage; this.setState({ images }); } render() { return ( <div> { this.state.images.map((image, index) => { return (<img src={image} key={index} style={{ height: this.state.active === index ? '100%' : 0 }} />); }); } </div> ); }
Если вы присмотритесь, на самом деле мы используем возможность реакции, чтобы избежать повторного рендеринга компонента, когда ключ остается таким же для того же набора данных. Итак, мы установили key = {index}, хотя это не предлагается.
Эффективность
Ранее предполагалось, что рендеринг каждого изображения занимал t секунд, а пользователь просматривал изображение в течение x секунд. Общее время, затрачиваемое только на ожидание обработки n изображений, составит n * t секунд.
Но с предварительным рендерингом пользователь должен просто подождать t секунд, которое было для первого изображения и загрузки всех остальных изображений в течение времени просмотра, равного x секунд.
Независимо от количества изображений у нас всегда будет время отрисовки t, учитывая, что пользователь просматривает каждое изображение дольше, чем время отрисовки (x ›t).
Примечание: это не обязательно должны быть изображения, которые должны быть предварительно обработаны. Любой компонент, данные которого известны заранее, может быть предварительно обработан.
Обновление
Масштабируя массив до n элементов, мы также можем поддерживать несколько слотов, из которых вы можете выбрать один для отображения следующим. например: имея три слота и в зависимости от направления движения выберите активный слот и доступные слоты для замены данных.
вы также можете поддерживать обратный / предыдущий способ таким образом, без повторной выборки и рендеринга данных с сервера. Очевидно, есть лучшие алгоритмы предварительного рендеринга, но это дает основную идею.
Замечательно ❤, теперь мы добились высокопроизводительных пользовательских интерфейсов. У нас есть аналогичные варианты использования в просмотрах продуктов в электронной коммерции, изображениях в фотогалереях и т. Д.