Анализ - Task-slice реализует мобильную загрузку Taobao

предисловие

После выхода предыдущей статьи, благодаря всеобщей поддержке, я занял первое место в списке горячих поисковых запросов Nuggets.Я хотел бы поблагодарить всех за вашу поддержку.

Конечно, есть и большие ребята, которые нашли некоторые из этих проблем и дали мне соответствующие задачи в git.Спасибо, у всех много вопросов, и все они надеются получить демо, чтобы продемонстрировать и увидеть реальный эффект. Здесь я буду использовать свой реальный проект, чтобы настроить его в соответствии с вашими сомнениями, чтобы увидеть, действительно ли существует проблема, которую вы рассматриваете.

Если у вас есть друзья, которых вы до сих пор не знаетеPerformance, то можете заглянуть сюда, так будет проще увидеть следующую картинку:Оптимизация производительности — Производительность (инструменты и API)

инструмент git

гит-адрес: срез задачи срез задачи

Если вы считаете, что эта статья полезна для вас, я надеюсь, что вы можете помочь больше.star

вопрос

Вопрос 1: Будет ли это на холостом ходу

Это будет холостой ход, и это действительно будет холостой ход, но у холостого хода есть роль, двеwhileСотрудничатьgeneratorдостигатьчасть задачиэффект, эта демонстрация покажет вам позже

Эффект холостого хода естьпространство для временипроцесс

Вопрос 2: Эффекта ускорения нет, но количество кода увеличивается

Здесь мне нужно подчеркнуть особенность, о которой я упоминал в предыдущей главе, а именноотклик, мы улучшили не только общую скорость, мы можем уменьшить общую скорость рендеринга, которая не будет сильно отличаться от предыдущей

Однако мы поднялиоткликСкорость, что это означает, означает, что пользователи могут максимально быстро отреагировать на поведение при посещении нашего веб-сайта в кратчайшие сроки.

Например:

До: Мы хотим загрузить веб-сайт, предыдущий ресурс загрузки2s, рендеринг потребностей500ms(5 компонентов), значит, мы находимся в2500msПосле этого можно выполнять рисунок, т. е. пользователю необходимо2500msКонтент можно будет увидеть позже

Сейчас: то же время загрузки ресурса2s, то же время рендеринга500ms, те же 5 компонентов, но после использования таск слайсинга каждый из наших компонентов рендерится и отрисовывается независимо, то есть мы находимся в2100ms, вы можете позволить пользователям увидеть наш первый фрагмент контента

общая проблема

В общем, самый главный вопрос для всех — зачем использоватьwhileзацикливаться столько разyield, Вместо того, чтобы использоватьif,пройти черезperformanceНа самом деле вы можете увидеть это только поwhileчтобы завершить нарезку, в этом и смысл, поэтому я используюwhile, Вместо того, чтобы использоватьifпричина

полная демонстрация

demoположи этоgithubup, фреймворк используетvue, Написал очень простоdemoВстретить всех понимать потребности инструмента

Как мы обрабатывали данные раньше

Прежде мы должны реализовать обновление данных, например:

// before
var arr = [0,1,2,3,4,5,6,7,8,9] //模仿接口请求返回的数据
this.arr = arr

После того, как мы получим данные, мы обновим данные непосредственно в соответствующем массиве ответов, затемvueВнутри весь массив будет пройден и отрендерен напрямую.

Согласно рисунку ниже, мы можем видеть, что способ, которым мы визуализировали ранее, на самом деле очень прост.demo, наш фактический проект будет иметь не только такой простой макет, но и не будет такого простого содержания.

Как мы обрабатываем данные после использования слайсов задач

// after
TaskSlice.init({
  sliceList: 10,
  callback: i => {
    this.arr.push(i)
  }
})

Мы можем интуитивно почувствовать, что есть большая разница в рендеринге контента.

ПучокMainПосле увеличения мы видим, что мы вырезали каждую задачу, затем рассчитали стиль, выполнили рисунок напрямую и поставилиdomПоместите его прямо на страницу, чтобы пользователи могли видеть контент в первый раз.

Как сделать реальную оптимизацию производительности

Некоторые оптимизации производительности на самом деле отличаются от того, что вы себе представляли.

Непонимание оптимизации производительности

Многие для оптимизации производительности знают про уменьшение запросов, быстрый рендеринг и т.д. Конечно с этим проблем нет

Однако, учитывая нынешний спрос интернет-рынка, у нас есть много дел, и этот метод не обязательно лучший, нам нужно внести определенные изменения, чтобы добиться реальной оптимизации.

Например

var count = 5
for (var i = 0; i < count; ++i) {
    var div = document.createElement('div')
    document.body.appendChild(div)
}

Предполагая, что когда мы захотим оптимизировать производительность, мы обнаружим, что так писать нехорошо, потому что она будет продолжать перерисовываться и перекомпоновываться, а производительность точно не самая лучшая, поэтому многие люди думают об API:document.createDocumentFragment

использоватьdocument.createDocumentFragmentМы можем создать фрагмент документа, который помещает всеdivПоместите их все во фрагмент документа, а затем выполните их в концеbodyизappendChild:

var count = 5
var fragment = document.createDocumentFragment()
for (var i = 0; i < count; ++i) {
    var div = document.createElement('div')
    fragment.appendChild(div)
}
document.body.appendChild(fragment)

Многие подумают, что это хорошо, нет проблем, так что нам не нужно постоянно перерисовывать и перекомпоновывать, и мы используем способ создания фрагментов документа, и мы не будем создавать лишниеdom

скажи всем, что черезperformanceИзвестно, что такой общийскорость рендерингаНе существует прямого способа создать Куай! ! !

На самом деле, для некоторых простых потребностей такая идея не является проблемой, потому что контент небольшой, а интерфейс простой, нам не нужно выполнять нарезку задач, а также нам не нужно делать слишком сложную обработку, прямой рендеринг будет быстрее

Итак, вопрос в том, если у нас есть 1000dom(включая иерархический дом), а тут очень сложные стили и много обработки интерфейса, так хорош ли этот метод?

Скажу прямо, не просто плохо, а все же плохо, так что надо подождатьcss treeа такжеdom treeВсе загружено, затем объединено, рассчитаны стили и, наконец, отрисованы на странице, очень медленно, очень медленно, если мы используем нарезку задач, предполагая, что у нас так многоdom, мы также порежьте их и оказываем часть в течение определенного периода времени, чтобы пользователи могли видеть в кратчайшие срокиdom, или точка:Мы улучшаем отзывчивость для пользователей, а не общую скорость рендеринга.

Суммировать

Эта статья предназначена для всех, чтобы ответить на сомнения, давайте перейдем к лучшему пониманию этого инструмента, и помочь вам применить их к реальным проектам

Если вы сомневаетесь, пожалуйста, внимательно прочитайте эту статью иАктуальный бой - как добиться такой же модульной загрузки, как у мобильного терминала Taobao (task-silce), и объединитьdemoПерейдите к исходному коду, чтобы узнать, может ли он решить вашу проблему. Если вы не можете решить ее, вы можете своевременно задавать вопросы. Я отвечу, когда у меня будет время.

И все, не смотрите просто на код и не тестируйте его, иногда то, что вы видите и думаете, может не совпадать с реальным эффектом.