halo, всем привет, меня зовут 132, всем уже давно не дешево!
В последнее время я был очень занят в классе, и у меня очень мало времени для написания кода::>_<:: voe>
Но нет...
voe — это низкоуровневая структура апплета.
Это означает, что он реализует двойной поток апплета, использует «песочницу» для изоляции веб-среды и защищает возможности dom.
Далее мы представим основные идеи в сочетании с апплетом WeChat:
Цель
Абсолютный контроль означает, что пользователь не может управлять домом, не может использовать веб-API, не может использовать полный jsx и html, не может... Во всяком случае, ничего!
Точно так же, как роль sm, s имеет абсолютный контроль и злоупотребление m, а m может только подчиняться приказам и злоупотреблять
Поэтому я называю двухпотоковую архитектуру апплета, также известную как[Архитектура ведущий-ведомый]
песочница
dom нельзя манипулировать в апплете не потому, что он блокирует dom API или блокирует событие, это нецелесообразно делать
Все ищут недомовую среду как песочницу, типа v8, типа worker, типа нативную, типа wasm
Все вышеперечисленное в порядке, я думаю, апплет WeChat и другие подобные песочницы также используются
voe использует web worker в качестве песочницы
Почему бы не использовать v8 или родной?
Это сугубо личный выбор, не выбирать v8 или натив следует, но лично я предпочитаю первое, вычислительная мощность веб-воркеров лучше, чем v8 или натив по умолчанию (тот же аппаратный уровень), но у v8 тоже есть преимущества, например, узел может использовать файлы cookie, а затем имеет расширенный API
Разделить кадр на два разных потока
Суть в том, как организовать работу фреймворка в два потока?
Есть несколько принципов:
- Пользовательская логика должна работать в воркере, а основной поток вообще нельзя трогать.
- Максимально вложить логику вычислительной мощности в воркеры
Итак, получается вот так:
Затем возникает трудность, пропасть между песочницей и основным потоком возникает из-за элемента dom и функции события, которые нельзя передать
Я ломал голову и нашел полное решение
Сохраните то, что нельзя передать в свой поток, и постройте карту, передайте индекс в другой поток.
Например, события доставляются так:
let handlers = new WeakSet()
if (props) {
for (const k in props) {
if (k[0] === 'o' && k[1] === 'n') {
let e = props[k]
let id = handlers.size + 1
handlers.set({ id: e })
props[k] = id
}
}
}
Сохраните событие в карте, а затем передайте идентификатор в основной поток.Когда событие основного потока срабатывает, возвращайте параметры идентификатора и события рабочему потоку.
for (const k in props) {
if (k[0] === 'o' && k[1] === 'n') {
let id = props[k]
props[k] = event => {
// 不能传太多，此处省略对事件的简化操作
worker.postMessage({
type: EVENT,
event,
id
})
}
}
}
Затем в воркере по индексной карте находим соответствующее событие и запускаем его
Да, верно, этот метод всемогущ, как и наш метод diff
Поскольку diff не может передать dom, мы передаем индекс dom
if (oldVNode ==null||oldVNode.type!==newVNode.type) {
parent.insertBefore(createNode(newVNode), node)
}
Например, в этом методе и родитель, и узел являются элементами dom, которые нельзя передать, мы просто передаем их индекс, может быть так:
[ [0,'insertBefore',1] ]
дом такой:
<div id="root" index="0">
<ul index="1">
<li index="2" />
<li index="3" />
</ul>
</div>
Если мы хотим удалить узел с индексом 3 в это время, соответствующая сгенерированная структура должна быть такой:
[ [1,'removeChild',3] ]
Sting не впечатляет, мы успешно нашли идею, которая может реализовать разные алгоритмы diff.
Знаешь, апплет WeChat не нашел похожей идеи, у них diff это еще древний deep traversal virtual-dom, а производительность кода оставляет желать лучшего...
Точно так же мы можем передать параметры функции основного потока основному потоку в рабочем потоке.
Например, если мы имитируем метод предупреждения, мы можем сделать это:
function alert(text){
postMessage({
name:'alert',
text
})
}
Затем основной поток получает параметры и выполняет
worker.onmessage = {data} => window[data.name](data.text)
Итак, идеально, чтобы мы могли выборочно использовать методы и переменные основного потока в рабочем потоке.
Таким образом, выше представлены основные идеи двухпоточности, которые применимы не только к данной структуре, но и к другим кросс-энд сценариям.
vue 3
Давайте кратко поговорим здесь о vue 3. Ну, как видите, имя и API voe похожи на vue 3. На самом деле, я скопировал ядро vue 3, включая сбор зависимостей, отзывчивость, обновление состояния, комбинированную функцию. …
Это всего лишь вопрос удобства.На самом деле, по сравнению с основной идеей voe, API ничто.
Потому что почти все компании, если они хотят разрабатывать свои небольшие программы, могут прийти только к идеям, и тогда API, скорее всего, будет соответствовать WeChat.
Поэтому я думаю, что API vue 3 достаточно прост, чтобы ослабить API.
Просто скопировал...
Вы можете использовать voe как наименьшую реализацию vue 3, а также очень хорошо помогает читать исходный код!
Двойной поток против асинхронного рендеринга
Не по теме, вы все должны знать фреймворк fre.js, который я написал ранее, и вы также должны иметь некоторое представление о механизмах асинхронного рендеринга, таких как параллельный (разрез времени) и приостановка.
Теперь я здесь, чтобы снова заняться веб-воркерами, потому что их идеи похожи, а сценарии одинаковы.
- Разбивка по времени заключается в использовании задач макросов для помещения задач с низким приоритетом, таких как diff, в очередь задач макросов, что имитирует двойные потоки и не блокирует пользовательский интерфейс.
- Двойная многопоточность — это использование веб-воркеров для выполнения задач высокой вычислительной мощности, таких как diff, в воркеры, чтобы не блокировать рендеринг пользовательского интерфейса основного потока.
Обе сцены также представляют собой визуализацию, анимацию с высокой частотой кадров, большие объемы данных и расчеты...
Жаль, что спрос на такого рода сцену слишком мал, поэтому команды preact и vue высказались, мол, не хотят и не надо это делать ::>_<::>
Но что касается меня, то мне все равно, используется ли кем-то фреймворк, и это не касается бизнеса, я больше склоняюсь к технологическим инновациям, поэтому с этой точки зрения, пока это новый идея, она всегда будет иметь свою ценность.
Суммировать
Уф~ Наконец-то я закончил писать, я пишу в Наггетс, это должно быть долго
Наконец, поместите github voe:
Добро пожаловать, чтобы подписаться и звездить!
Кроме того, была создана фронт-группа для обмена различными новыми идеями: 813783512