Как создать полную оценку для опыта мини-программы - Практика оптимизации мини-программы Jingxi

задний план

Experience Score Audits — это встроенная функция инструментов разработчика WeChat, которая будет проверять в режиме реального времени работу апплета, анализировать некоторые области, которые могут привести к негативному опыту, обнаруживать проблемы и давать некоторые предложения по оптимизации.

Как стратегический бизнес Jingdong, мини-программа Jingxi имеет десятки миллионов входов трафика.После длительного периода бизнес-итераций логика кода стала очень сложной и раздутой, и существует острая необходимость в оптимизации производительности. Поэтому, в сочетании с функцией подсчета опыта и использованием домашней страницы Jingxi в качестве пилотного проекта, мы провели оптимизацию подсчета опыта. Цель состоит в том, чтобы изучить индексные принципы оценки опыта мини-программы: как должна выглядеть мини-программа с 100 баллами; в то же время я надеюсь предоставить больше идей для оптимизации проекта.

Я представлю его в соответствии с идеей «понимания статус-кво оценки домашней страницы, анализа правил вычетов и решения вычетов», давайте начнем ~

Статус рейтинга домашней страницы Jingxi

Откройте Инструменты разработчика мини-программ — Отладчик — Аудиты, нажмите «Выполнить», немного прокрутите страницу операции и нажмите «Конец».

Результаты подсчета очков будут варьироваться в зависимости от содержания страницы оценки, привычек работы и наличия кэша.Следующее изображение представляет собой оценку на домашней странице Jingxi: общая оценка составляет 68, и есть вычеты за производительность, опыт, и лучшие практики, всего 8 выводов. Элементы, мы проанализируем эти элементы вычетов один за другим позже.

Анализ и оптимизация статей вычетов

1. Используется чрезмерное количество узлов WXML

Критерии оценки: на странице менее 1000 узлов WXML, глубина дерева узлов менее 30 уровней, количество дочерних узлов не более 60.

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

Существует более 2500 существующих узлов.Если вы хотите оптимизировать, вам сначала нужно понять распределение количества узлов в каждом модуле страницы.

Как посчитать количество узлов в каждом модуле? Вы можете использовать «метод управляющей переменной», чтобы использовать способность инструмента оценки производительности отображать общее количество узлов, когда количество узлов превышает 1000. Мы можем скрыть один модуль за раз, когда общий индекс превышает 1000:

​ Количество узлов целевого модуля = исходное общее количество узлов - текущее количество узлов

(Количество измеряемых узлов будет колебаться в небольшом диапазоне, а среднее можно измерить 3 раза)

Схема модульного анализа главной страницы выглядит следующим образом:

(первый экран) (второй экран)

Упрощенные данные выглядят следующим образом:

Из списка наблюдения можно получить две части информации: домашняя страница разделена на первый экран и второй экран с взаимоисключающими состояниями отображения, количество узлов в модуле списка самое большое.

Таким образом, мы получаем два направления оптимизации:

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

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

Второй элемент оптимизации, который приходит на ум в первую очередь, — это уменьшение значения страницы интерфейса списка, например, запрос 20 фрагментов данных за раз вместо запроса 5 фрагментов данных. Но если интерфейс не поддерживает настраиваемое разбиение на страницы, можно ли реализовать меньшие запросы на разбиение на страницы?

Тогда сами напишите прокси для метода пейджинга~

Идея заключается в следующем:

Верхняя часть — исходный запрос, каждый раз по 20 фрагментов данных, а нижняя часть — реализация прокси-запроса, каждый раз возвращается 5 фрагментов данных. Серый пунктирный прямоугольник — это реальное действие запроса данных. При сохранении полного объема данных, какая страница необходима для получения какой страницы, это пример кода:

С помощью двух вышеупомянутых оптимизаций количество узлов страницы на домашней странице может быть успешно уменьшено, и, наконец, мы успешно достигли цели не более 1000 узлов wxml в целом.

2. Изображение слишком большое, а полезная площадь дисплея мала.

Критерии оценки: произведение ширины и высоты изображения

Простое понимание состоит в том, что размер изображения слишком велик, а размер экрана слишком мал, что приводит к трате времени сетевых запросов и ресурсов памяти.

Решение: поставщики услуг CDN обычно поддерживают получение изображений разных размеров с помощью параметров.Внешняя часть может обернуть общедоступный метод для извлечения изображений соответствующего размера в соответствии с размером элемента страницы.

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

• Есть много статей о выборе типов изображений Как выбрать jpg/png/gif и webp? сначала поставь картинку из гугла

  

  На этой картинке webp не рассматривается, а конкурентоспособность других типов webp мгновенно недостаточна. Скорость поддержки мобильного андроида в основном доступна, и вы можете рассмотреть возможность ее использования постепенно в зависимости от типа устройства:

  

• Используйте некоторые методы сжатия для сжатия изображений, рекомендуется pngtinypng.com/, размер сжатия немалый, но мало влияет на качество отображения картинки.

3. Область ответа с кликабельными элементами слишком мала

Критерии оценки: Ширина и высота кликабельных элементов не менее 20 пикселей.

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

• padding
• прозрачныйborder
• box-shadow

4. Сделайте необходимое кэширование для сетевых запросов

Стандарт оценки: один и тот же запрос URL не появляется дважды в течение 3 минут с одним и тем же содержимым размером более 128 КБ.

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

Метод оптимизации:

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

5. Слишком много запросов за короткий промежуток времени

Критерии оценки: успешноwx.requestКоличество одновременных запросов, инициация которых занимает более 300 мс, не превышает 10.

В отличие от предыдущего пункта, этот фокусируется на количестве параллелизма интерфейсов:

• wx.request(HTTP-соединения) максимальное ограничение параллелизма составляет 10
• wx.connectSocket(соединения WebSocket) максимальное ограничение параллелизма составляет 5

Метод оптимизации:

• Логика расчета перемещена назад, а интерфейс агрегирован
• Для сетевых запросов со схожими обязанностями лучше всего использовать метод дросселирования, сначала собирать данные в течение определенного интервала времени, а затем объединять их в тело запроса и отправлять на сервер.

6. Есть переменные, не привязанные к wxml

Критерии оценки:setDataВсе входящие данные имеют зависимости в рендеринге шаблона

Этот пункт исследует проблему избыточности данных.Апплет разработал двойной поток, который разделяет рендеринг и логику, и две стороны взаимодействуют черезevaluateJavascriptПреобразование строк и последующее их объединение требует большой осторожности в отношении объема данных, передаваемых между двумя потоками. Следовательно, переменные, не привязанные к wxml, лучше оптимизировать, чтобы не использоватьsetData.

В зависимости от сценария использования можно выполнить следующие оптимизации:

• Внутренние переменные, не связанные с отображением страницы, могут быть смонтированы в экземплярах компонентов, например, поддержаниеthis.privateDataобъект
• Используйте «поле чистых данных», поддерживаемое новой версией апплета: это поле не будет передано в wxml, конфигурация регулярно определяет его диапазон соответствия, и его можно использовать в обычном режиме.setDataметод, см. документацию для конкретного использования:Developers.WeChat.QQ.com/mini программа…

Но что, если вы, как и я, столкнулись со сценарием, который не может быть описан вышеописанными стратегиями?

• Старый код нуждается в модификации, а регулярный эффект от настройки чистых полей данных слишком велик.
• Домашняя страница Jingxi использует Таро для многоконечной адаптации.После того, как Таро скомпилирует массив сложной логики, появится «теневая переменная», представляющая логику, а исходная переменная массива будет накладной, что приведет к вычету баллов.

Тогда есть окончательный хак:

Таким образом, будет сочтено, что список имеет связанные узлы, и баллы не будут вычтены.

7. Инициируйте слишком много запросов изображений

Критерии оценки: не более 20 одновременных запросов изображений с одним и тем же доменным именем, занимающих более 100 мс.

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

Метод оптимизации:

• Спрайт

• Ленивая загрузка изображения: апплетImageПоддержка компонентов через конфигурациюlazy-loadпараметры для реализации ленивой загрузки (Developers.WeChat.QQ.com/mini программа…), конкретная логика решения заключается в том, что картинка начинает загружаться, когда она попадает на три верхних и нижних экрана. Если вам нужна более управляемая реализация, вы можете создать свои собственные компоненты для ее обработки.

Суммировать

После завершения этих оптимизаций снова проверьте оценку опыта:

Вышеизложенное является практическим содержанием домашней страницы Jingxi в аспекте оптимизации подсчета очков опыта мини-программы.

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

использованная литература

[1] Документ по разработке мини-программы:Developers.WeChat.QQ.com/mini программа…

[2] Images: Your easiest page speed win: поисковая система land.com/images-ahas…

[3] Tiny Png: tinypng.com/