Вы не можете знать апплет

JavaScript Апплет WeChat

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

1. Ограничение стека страниц — до 10 слоев.

Во-первых, давайте взглянем на рисунок ниже.Архитектура апплета выглядит следующим образом:

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

Что же делать, если содержимое страницы слишком сложное, а память взрывается в пределах 10-слойного стека страниц? Внутри апплета есть механизм рециркуляции, если памяти мало, часть WebView будет перезапущена.

Многим может показаться, что 10-слойного стека страниц в принципе достаточно, и нет необходимости обращать внимание на это ограничение.

Однако если есть циклическая ссылка и пользователь несколько раз щелкает мышью, стек легко разнести.. Как показано ниже:

Поэтому перед разработкой очень важно заранее разобраться с переходами между страницами и использовать navigator, redirectTo, navigationBack...

Конечно, как программист, я не хочу обращать внимание на то, правильные ли у меня ссылки и есть ли более 10 слоев стека страниц при переходе. Полностью можно инкапсулировать прыжок апплета.

Поскольку только wx.navigateTo сделает стек страниц + 1, нам нужно выполнить только слой восходящей обработки для этого метода. Следующий код:

const PAGE_LIMIT = 10
const pages = getCurrentPages()
if(pages.length >= PAGE_LIMIT) {
  // 使用 wx.redirectTo 方法
}

Таким образом, вы можете прыгать вверх и вниз, как вам нравится.

2. JsCore

Логический уровень апплета работает в JsCore. Ограничения следующие:

  • Без объектов Window и Document некоторые DOM-библиотеки использовать нельзя, решения пока нет.

Начнем с картинки:

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

  1. Необходимо очистить таймер setTimeout или setInterval страницы самостоятельно.
  2. Если страница должна иметь самые свежие данные каждый раз, когда она появляется, логика вытягивания данных должна выполняться в onShow, а не в onload.
  3. Если вы преследуете «экстремальный опыт», когда пользователь переключается на следующую страницу, вы можете прервать интерфейс, который не был успешно запрошен в onHide, и удалить setData для обработки, что может уменьшить логику последней страницы и сделать последняя страница отображает самый быстрый экспонат.

3. Высочайший уровень нативных компонентов

Компоненты, такие как холст, видео, ввод, карта, сборщик ...... компоненты, официальное использование собственных компонентов напрямую, метод рендеринга выглядит следующим образом:

Из приведенного выше рисунка легко увидеть, что компоненты Navtive находятся на самом высоком уровне, поэтому простое изменение z-индекса не позволит другим компонентам перекрыть нативные компоненты. К счастью, чиновник дал решение:

  • Используйте обложку с изображением обложки, чтобы обернуть компоненты, которые должны быть выше по уровню, в «родные компоненты».

4. Уникальный сетевой запрос, локальное хранилище

  1. Уникальное хранилище
    • Из-за изоляции широты пользователя A не может получить доступ к данным пользователя B на том же устройстве.
    • Постоянный кэш будет удален только тогда, когда пользователь закроет апплет.Если места недостаточно, будет выполнено LRU, то есть область кэша данных апплета, которая не часто используется, будет полностью очищена.
    • Пробная версия, версия для разработчиков и онлайн-версия имеют один набор и не будут изолированы.
    • нет печенья
  2. Запрос на загрузкуЗагрузка файлаФайл до 10 одновременных запросов
  3. Поддерживает только HTTPS WSS

Если в прошлом на мобильном терминале интерфейс ПК использовал файлы cookie для некоторой обработки, было бы неудобно использовать этот интерфейс в апплете.

Следовательно, мы также можем смоделировать Cookie в апплете, как показано ниже:

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

let cookie = (function(){
    return wx.getStorageSync('cookies');
}())
const Cooke = {
  getCookie(){}, //从内存中获取cookie
  setCookie(){}, // 设置cookie
  setCookieInHeader(){}, //根据response的Header设置cookie
  removeCookie() {},  //删除cookie
  isExpired() {} //判断是否过期
}

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

  1. Параллельная обработка запросов

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

class Request {
    constructor() {
        this.maxLimit = 10;
        this.requestQueue = []; // 请求队列
        this.requestIng = 0; //当前并发数
    }
    request () {
        // 判断是否超出并发数
        if(this.requestIng >= this.maxLimit) {
            // 推入请求队列
        }else {
            this.requestIng ++;
            // 执行成功后 - 1 ,从 requestQueue 中取出重新请求
        }
    }
}

5. установить данные

Итак, давайте начнем с картинки Очевидно, мы видим, что каждый setData является потоком связи.

Потоковое общение дорого и требует много времени, поэтому официальный совет четко дан:

  1. Объединение нескольких вызовов setData в один вызов
  2. Только значение, измененное объектом setData
data: {
    array: {
        changeData: '我改变了',
        noChangeData: '我没有改变'
    },
},
this.setData({
    'array.changeData':'changed data'
})
  1. Не помещайте в данные поля, не связанные с отрисовкой интерфейса
data: {
    view: '与界面相关的数据'
},
noRelaView: '与界面无关'

@автор: лист

Категории