Введение
В этой статье я расскажу, как настроить среду сборки для гибридной разработки (сторона Hybird h5).
Содержание включает в себя следующие моменты:
(1) Особенности и требования гибридной разработки на стороне страницы h5
(2) Как использовать webpack4 для сегментации кода с несколькими записями, чтобы добиться лучшего использования кеша
(3) Как оптимизировать для первого рендеринга экрана
(4) Как использовать webpack4 для одновременного вывода пакетов ES next (современный) и es5 (обратно совместимый)
(5) Клиент упаковывает ресурсы h5 в стратегию упаковки
репозиторий кодаwebpack-esnext-cli, вы также можете понять, читая код, конечно, лучше всего собрать его самостоятельно
Во-вторых, характеристики и требования смешанной разработки боковых страниц h5.
Каковы характеристики смешанной разработки боковых страниц h5?
Вход сложный, на некоторых страницах только копирайтинг, требуется быстрая скорость отрисовки первого экрана, скорость использования некоторых страниц невысокая, скорость зависит от сети
(1) вход сложный
Сложная запись на самом деле означает, что ваш внешний проект должен быть создан с несколькими записями в качестве отправной точки.Например, в веб-пакете вы можете настроить запись и написать скрипт для получения записи js каждой страницы во время создания.Множественные записи означают что вы должны учитывать. Как извлекать модули, совместно используемые между страницами, для достижения оптимального использования модулей, мы подробно обсудим это в следующем разделе статьи.
(2) Некоторые страницы написаны только копирайтингом, и коэффициент использования невысок.
На самом деле, если вы занимались смешанной разработкой, вы, естественно, обнаружите, что есть некоторые страницы, на которых есть только копирайтинг без какого-либо взаимодействия с js.Такие страницы, как пользовательские соглашения, часто задаваемые вопросы и другие страницы копирайтинга, имеют низкий уровень использования, и они не подходят для первого экрана.Если есть требование, мы можем написать html в файле html, и нам не нужно использовать фреймворк, такой как vue, чтобы написать виртуальный DOM, чтобы полагаться на фреймворк для рендеринга, что может сэкономить время, необходимое для запуска и рендеринга сценария запроса и фреймворка, а также обеспечить быстрое появление текста на странице.
(3) Более быстрый рендеринг первого экрана и скорость сети
Поскольку наша страница h5 больше зависит от сети мобильного телефона, это не означает, что ресурсы клиента упакованы в локальную сеть, хотя 4G сейчас популярен, но пользовательская сеть во многих случаях не очень хороша.Скорость открытия страницы имеет определенные проблемы.С инженерной точки зрения, можем ли мы упаковать ресурсы, необходимые для h5, в локальный, такой как клиент? Ответ, конечно, да, и я расскажу об этом позже.
3. Как использовать webpack4 для разделения кода
Согласно характеристикам страницы и требованиям, упомянутым во втором пункте выше, наш многостраничный общий модуль должен быть следующим:
1. Пакеты, которые каждая запись в основном должна использовать, должны кэшироваться в течение длительного времени (значение хеша остается неизменным)
2. Общие фрагменты можно свободно делить
3. На общие фрагменты можно ссылаться в конфигурации страницы.
Тогда давайте посмотрим, какие средства мы можем использовать для обеспечения трех вышеуказанных пунктов в webpack4.
Например, в проекте Vue каждая наша запись в основном зависит от vue.js, и размер ресурса, занимаемого Vue в пакете, который мы набираем, также относительно велик, и именно эту часть нам нужно кэшировать на долгое время. Об этом пункте я в другой своей статьестатьяупоминается в. Здесь, в webpack4, мы упакуем vue в вендор как базовый пакет проекта для введения страницы (конечно, можно упаковать и остальные модули)
...
optimization: {
splitChunks: {
...
'vendor': {
test: /node_modules\/vue/,
name: 'vendor',
chunks: 'all',
enforce: true,
priority: 2
},
...
}
},
plugins: [
// 稳定moduleId,避免引入了一个新模块后,导致模块ID变更使得vender和common的hash变化后缓存失效
new webpack.HashedModuleIdsPlugin(),
]
...
После упаковки vue только в вендор мы можем обеспечить стабильность базового модуля, но нам также нужна некоторая гибкость.Например, у нас есть несколько сложных страниц, которые можно превратить в отдельные страницы.На данный момент нам нужно представить vue- роутер, vuex и другие инструменты.
Вы можете сказать, почему бы не упаковать эти пакеты в вендор? Т.к. в гибридной разработке заход на страницу очень сложен, если пользователь открывает обычную страницу, то достаточно положиться только на vue, а так как vue-router тоже запакован при распаковке, то пользователь скачивает один и он может использовать Это также влияет на скорость рендеринга других страниц, поскольку пакет js слишком велик, время загрузки слишком велико, а отдельная упаковка может играть роль добавочной загрузки.
На данный момент мы добавляем конфигурацию spa-vendor в splitChunks:
optimization: {
splitChunks: {
...
// 项目基础包
'vendor': {
test: /node_modules\/vue/,
name: 'vendor',
chunks: 'all',
enforce: true,
priority: 2
},
// 单页面需要引入vue-router, vuex,这里单独分割出来
'spa-vendor': {
test: /node_modules\/vue-router/g,
name: 'spa-vendor',
chunks: 'all',
enforce: true,
priority: 10
},
...
}
},
Хорошо, пока что мы отделили некоторые относительно большие и нечасто изменяемые пакеты проекта независимо друг от друга и кэшировали их на постоянной основе.Для остальных пакетов, которые не такие большие, мы можем позволить веб-пакету идти в соответствии с размером и частотой ссылок.Автоматическая упаковка, здесь мы добавляем конфигурацию пакета commons
optimization: {
splitChunks: {
...
// 项目基础包
'vendor': {
test: /node_modules\/vue/,
name: 'vendor',
chunks: 'all',
enforce: true,
priority: 2
},
// 单页面需要引入vue-router, vuex,这里单独分割出来
'spa-vendor': {
test: /node_modules\/vue-router/g,
name: 'spa-vendor',
chunks: 'all',
enforce: true,
priority: 10
},
// 剩余chunk自动分割
'commons': {
name: 'commons',
minChunks: 5, // 引用次数大于5则打包进commons
minSize: 3000, // chunk大小大于这个值才允许打包进commons
chunks: 'all',
enforce: true,
priority: 1
}
...
}
},
Когда вы увидите здесь, вы увидите, что приоритет каждого чанка в splitChunk разный, а приоритет общих ресурсов самый низкий, потому что он не будет извлечен из общих ресурсов, пока не будет завершено извлечение спа-вендора и вендора.
После завершения выходной пакет выглядит следующим образом
продавец (60k):
spa-vendor (23k, все еще относительно большой):
достояние:
Мы уже добились бесплатной сегментации и долгосрочного кеширования, а остальное — чанки свободно внедряются в страницу. В написанном мной webpack-esnext-cli я использовал механизм шаблонов nunjucks для импорта ресурсов страницы и использовал таблицу ресурсов, выводимую плагинами webpack4 и webpack-manifest-plugin после упаковки, чтобы свободно настраивать ресурсы для страницы. .
Например, если необходимо ввести одну страницу spa-vendor, мы введем манифест, vendor, spa-vendor, пакет commons и запись страницы js (бизнес-файл) по умолчанию.
<!DOCTYPE html>
<html lang="en" bgc-f7f7f7>
<head>
...
</head>
<body>
<div id="app"></div>
<!-- 以注释的方式添加模板语法,addAssets方法可以注入对应模块组(按顺序) -->
<!-- {{ 'js' | addAssets(['manifest', 'vendor', 'spa-vendor', 'commons']) }} -->
</body>
</html>
Если это просто обычно и должно быть основано только на vue, мы введем манифест, поставщик, общие ресурсы (метод addAssets здесь передает пустой массив, чтобы ввести эти фрагменты по умолчанию), так что нам не нужно загружать spa- поставщик при открытии страницы, чтобы достичь роли модульной избыточности
<!DOCTYPE html>
<html lang="en" bgc-f7f7f7>
<head>
...
</head>
<body>
<div id="app"></div>
<!-- 以注释的方式添加模板语法,addAssets方法可以注入对应模块组(按顺序) -->
<!-- {{ 'js' | addAssets([]) }} -->
</body>
</html>
Конечно, вы можете различить, как ваши куски должны быть разделены более подробно, здесь просто демонстрация.
В-четвертых, используйте webpack4 для вывода пакета следующего синтаксиса ES.
PHILIP WALTONВ этой статье объясняется принцип вывода es next.В то время я был очень увлечен, поэтому нашел время реализовать набор
Давайте поговорим об идее здесь, вы можете сами посмотреть код хранилища для реализации кода.
При упаковке нам нужно вывести два набора пакетов
На самом деле принцип заключается в том, чтобы позволить Babel компилировать пакеты с другим синтаксисом, изменив broswerList.
современный (es6):
наследие (es5):
После создания пакета синтаксиса es6 нам нужно вывести файл записи es5.Чтобы избежать перекрытия выходных таблиц ресурсов, нам нужно переименовать запись es5.
Среди них a.js — это наша запись сборки es6, а a-legacy.js, созданный скриптом, — наша запись сборки пакета es5.Содержимое выглядит следующим образом:// a-legacy.js
import './a.js'
При упаковке мы генерируем соответствующий html-файл в соответствии с записью js, а затем выбираем ресурсы для вставки в соответствии с таблицей ресурсов, созданной каждой упаковкой.
Лист ресурсов:
Как показано на рисунке выше, таблица ресурсов соответствует исходному пути и выходному пути ресурса.При выводе html вы можете выполнить сопоставление ресурсов в соответствии с путем.
Выходной html выглядит следующим образом (файл манифеста современного пакета встроен):
Браузеры, поддерживающие синтаксис type=module, будут автоматически загружать пакеты с синтаксисом es6, а браузеры, не поддерживающие его, будут загружать пакеты обратной совместимости es5.
На самом деле, выгоды от этого очень велики.Следующие цифры взяты из двух статей PHILIP WALTON.
Видно, что выходной пакет es6 лучше, чем пакет грамматики es5, с точки зрения размера и скорости синтаксического анализа, а эффект ускорения для мобильного терминала по-прежнему очень велик.
5. Ускорение первого экрана и упаковка ресурсов h5 в клиент
Что сделать, чтобы ускорить первый экран? Просто чтобы контент появился как можно скорее.
Ранее мы улучшили использование и размер ресурсов, а также скорость разбора кода за счет сегментации модулей и вывода пакетов es next, теперь следует подумать, как использовать возможности клиента для оптимизации.
Ускорение первого экрана - не более чем ускорение скорости запуска веб-просмотров и уменьшение времени загрузки пакета, поскольку большая часть скорости первого экрана заключается в том, что страница заблокирована из-за скачивания ресурсов.
Представьте, если веб-просмотр может перехватывать наши запросы ресурсов, то можем ли мы упаковать статические ресурсы, такие как js и css нашей страницы, в клиент, и после того, как клиент откроет веб-просмотр, перехватить URL-адрес для выполнения обработки на локальных ресурсах. URL-адрес совпадает, локальный файл читается при попадании, и файл снова извлекается с сервера по истечении срока его действия.Сервер даже может сделать push-сервис для обновления файла ресурсов, так что страницу h5 можно открыть за считанные секунды. на стороне клиента.Это также может снизить нагрузку на сервер, и оптимизация очень очевидна в случае слабой сети.
Конечно, вы также можете предварительно отрендерить часть html в html-файл, создав первый экран, который рассматривается в другой моей статье.--Как сделать предварительный рендеринг в webpack, чтобы уменьшить пустое время первого экрана, тут больше нет
6. Резюме
Конструкция Hybrid h5 на самом деле больше основана на потребностях. Использование веб-пакета — это только один из способов. Что еще более важно, я думаю, что это понимание и применение загрузки и кэширования ресурсов. Не говори, не говори, пора двигать кирпичи. Любые вопросы или предложения приветствуются.