ToB企服应用市场:ToB评测及商务社交产业平台

标题: Vue3 核心源码解析 [打印本页]

---

作者: 梦应逍遥    时间: 2024-10-4 20:21
标题: Vue3 核心源码解析
Vue 发展进程

   虚拟DOM 为后续做服务端渲染以及跨端框架位置提供根本。 
  相对应地缺点：

  

  （1）源码优化：

对于 Vue.js 框架本身开辟的优化。
目的：让代码更易于开辟和维护 
源码的优化主要体现在使用 monorepo和TypeScript 管理和开辟源码。
这样做的目的是提拔自身代码可维护性 

①更好的代码管理方式: monorepo 

相对于 Vue.js 2.x的源码组织方式，monorepo 把这些模块拆分到不同的 package 中，每个 package 有各自的 API、类型界说和测试。
这样使得模块拆分更细化，职责划分更明确，模块之间的依赖关系也更加明确开辟职员也更容易阅读、明白和更改全部模块源码，提高代码的可维护性。 
例：package(比如 reactivity 响应式库)是可以独立于 Vue.js 使用的。
这样用户如果只想使用 Vue.js 3.0的响应式能力，可单独依赖这个响应式库。而不消去依赖整个 Vue.js，减小了引用包的体积巨细，而 Vue.js2.x是做不到这一点的 
 
②有类型的 JavaScript: TypeScript

——>更有利于代码的维护 

 

• 因为它可以在编码期间帮你做类型检查  避免一些因类型题目导致的错误
  
• 有利于它去界说接口的类型，利于IDE（集成开辟环境  常见的IDE有Visual Studio、Eclipse、IntelliJ IDEA等）对变量类型的推导
  

   

• Flow 是 Facebook出品的 JavaScript 静态类型检查工具，它可以以非常小的成本对已有的JavaScript 代码迁入，非常机动，这也是Vue.is 2.0 当初选型它时一方面的考量。
  
• Flow 对于一些复杂场景类型的检查，支持得并不好。（在看 Vue.js 2.x源码的时候，在某行代码的注释中看到了对 Flow 的吐槽）
  
  
  

  因此就选用了 TypeScript  举行整个项目的重构，TypeScript 提供了更好的类型检查，能支持复杂类型的推导。源码接纳TS编写，也省去了维护所在TS文件的麻烦。
 

---

（2）性能优化：

对于 Vue.js 2.x 已经足够优秀的前端框架 它的性能优化可以从哪些方面举行突破呢? 
 
①源码体积优化： 

   原理：JS包体积越小， 即网络传输时间越短，JS引擎解析包的速度越快。
  

 

 
   原理： 未被引入的square模块被标志，压缩阶段会使用压缩工具真正删除没用到的代码。
  

 
②数据劫持优化： 

Vue.js 区别于 React.js 的一大特色是Vue的数据是响应式的。 

DOM 是数据的一种映射， 数据发生变化后可以自动更新DOM，用户只需要专注于数据的修改，没有别的的性质负担。但是这样子的功能实现必须需要劫持数据的访问与更新。
   当数据改变后，为了自动更新 DOM，那么就必须劫持数据的更新。
  也就是说当数据发生改变后能自动实行一些代码去更新 DOM。 
  Vue.js 怎么知道更新哪一片 DOM 呢?
因为在渲染 DOM 的时候访问了数据，我们可以对它举行访问劫持。
这样就在内部创建了依赖关系，也就知道数据对应的 DOM 是什么了 。内部需要依赖watcher的数据结构做依赖管理

Vue1 和 Vue2  通过 object.defineProperty 举行数据劫持：

   缺陷：必须知道要拦截的key是什么，因此不能检测对象的属性的添加和删除。 
  

  如果要劫持内部深层次的对象变化，就需要递归遍历这个对象，通过Object.defineProperty把每一层对象的数据都变成响应式的。——> 响应式数据过于复杂，就会有相称大的性能负担。
  

劫持了一整个对象，因此对对象属性的增长和删除都能够检测到。 

这样的利益是真正访问到的内部对象才会变成响应式，而不是无脑递归这样无疑也在很大程度上提拔了性能。
 

---

（3）编译优化：Block tree

 响应式过程发生在new Vue到 init 阶段。

   虽然 Vue.js 2.x 的数据更新并触发重新渲染的粒度是组件级的:，虽然Vue能保证触发更新的组件最小化，但是在单个组件内部，依然需要遍历该组件的整个 windows 树。
  

代码只有一个动态节点，很多的 diff 和遍历其实是不需要的，导致Windows 性能与模板巨细正相关，跟动态节点的数目无关。当一些组件整个模板只有少量动态节点时，这些遍历都是性能的浪费。 
理想状态只需要 diff  这个绑定 message 动态节点的p标签即可 

   Block tree
  

• Blocktree 是一个将模版基于动态节点指令切割的嵌套区块，每个区块内部的节点结构是固定的每个区块只需要以一个 Array 来追踪自身包罗的动态节点。
  
• 借助 Block tree，Vue.js 将vnode 更新性能由与模版整体巨细相关提拔为与动态内容的数目相关
  

  

 

---

（4）语法API优化: Composition API

①优化逻辑组织 

   Options APl
  

• OptionsAPl的设计是按照 methods、computed、data、props 这些不同的选项分类
  
• 当组件小的时候，这种分类方式一清二楚; 但是在大型组件中，一个组件大概有多个逻辑关注点当使用 Options API的时候，每一个关注点都有本身的 Options
  
• 如果需要修改一个逻辑点关注点，就需要在单个文件中不停上下切换和寻找
  

  

按照逻辑关注点做颜色编码， 当使用Option API 编写组件时，逻辑关注点都黑白常分散的。

开辟项目变得复杂时，免不了需要抽象出一些复用逻辑。 

 
 鼠标位置监听的例子：

 如果有大量的Mixin就会有定名冲突和数据泉源不清楚。
   

• 首先每个 mixin 都可以界说本身的 props、data，它们之间是无感的所以很容易界说雷同的变量，导致定名冲突。
  
• 对组件而言，如果模板中使用不在当前组件中界说的变量，那么就会不太容易知道这些变量在哪里界说的，这就是数据泉源不清楚
  

  但是Vue.js 3.0 设计的 Composition APl，就很好地资助我们办理了 mixins 的这两个问
  

   Composition APl
  

• 除了在逻辑复用方面有优势，也会有更好的类型支持
  
• 因为它们都是一些函数，在调用函数时，自然全部的类型就被推导出来了。不像 Options API 全部的东西使用 this
  
• 别的，CompositionAPl 对 tree-shaking 友好，代码也更容易压缩
  

   

---

②引入 RFC:

使每个版本改动可控

 

过渡期： 

 

---

 
组件渲染

 在 Vue.js 中，组件是一个非常重要的概念，整个应用的页面都是通过组件渲染来实现的
 编写组件开始，到最终真实的 DOM 又是怎样的一个变化过程呢?

组件： 

①应用步伐初始化：

一个组件可以通过 “模板加对象形貌” 的方式创建，组件创建好以后是如何被调用并初始化的呢?
因为整个组件树是由根组件开始渲染的。
为了找到根组件的渲染入口，需要从应用步伐的初始化过程开始分析 

   本质：把 app 组件挂载到 id 为 app 的DOM节点上。
  createApp 是一个入口函数，Vue对外暴露的函数
  createApp 主要是：

  

• 创建 app 对象；
  
• 重启 app.mount 方法
  

  

  ensureRenderer() 用来创建一个渲染器对象
  渲染器：为跨平台渲染做准备（包罗平台渲染核心逻辑的JS对象）
  

  优点：用户只依赖响应式包的时候，就不会创建渲染器，可以通过 tree-shaking 移除核心渲染逻辑相关的代码
  

• 在整个 app 对象创建过程中，Vue.js 使用 闭包和函数柯里化 的本事，很好地实现了参数保留
  
• 比如，在实行 app.mount 的时候，不需要传入 渲染器render（因为在实行 createAppAPI的时候渲染器 render 参数已经被保留下来了 ）
  

先思考一下，为什么要重写 app.mount 这个方法而不把相关逻辑放在 app 对象的 mount 方法内部来实现呢? 

    标注的可跨平台的组件渲染流程：先创建Vnode，再渲染Vnode。rootCotainer可以是（DOM大概是其他平台的其他类型的值，即这些代码实行逻辑都是与平台无关的，因此需要重写方法来完满外平台下的渲染逻辑。）
  

---

 
②核心渲染流程:

创建 vnode 和渲染 vnode 

1️⃣平凡元素节点：

 

2️⃣组件节点

即不会真的在页面上渲染一个 CustomComponent 标签，而是渲染组件内部界说的 HTML 标签。
3️⃣纯文本Vnode
4️⃣注释Vnode 
 
内部还针对Vnode tag做了更详细的分类，而且把VNode类型做编码，以便在后面的配置阶段，可以根据不同的类型实行相应的处理逻辑： 

 
那么 vnode 有什么优势呢?
为什么一定要设计 vnode 这样的数据结构呢? 
 

   

首先这种基于 vnode 实现的 MVVM 框架，在每次 render to vnode 的过程中，渲染组件会有一定的 JavaScript 耗时，特别是大组件
  当我们去更新组件的时候，用户会感觉到显着的卡顿。
  虽然 diff 算法在减少 DOM 操作方面足够优秀，但最终还是免不了操作 DOM所以说性能并不是 vnode 的优势
  

   创建VNode操作：对 props 做标准化处理，对 Vnode 的类型信息编码，创建 VNode 对象，标准化子节点children 
  app.mount 内部通过实行 render 函数去渲染创建的 VNode

   

patch 函数功能：
  

• 根据 VNode 挂载 DOM
  
• 根据新旧 VNode 更新 DOM 
  

  重点关注对组件的处理、对平凡 DOM 元素 两种类型的处理节点的渲染逻辑 

主要操作：创建组件实例， 设置组件实例，设置并运行带副作用的渲染函数

初始渲染主要做两件事变: 渲染组件生成subTree（VNode对象）、把 subTree 挂载到 container 中

• hello节点渲染生成的Vnode就是hello对应的init Vnode（组件Vnode）
  
• hello组件内部的整个DOM节点对应的Vnode就是实行 renderComponentRoot 渲染生成对应的subTree，可以称之为子树Vnode 
  

每个组件都有对应的render函数 
renderComponentRoot  就是实行 render 函数，创建整个组件内部的Vnode，把这个 Vnode 再经过内部一层标准化就能得到该函数的返回效果即子树Vnode。渲染生成子树Vnode后就是大勇patch函数把子树Vnode挂载到content中。
 
对平凡DOM元素的处理流程： 

如果是其他平台比如 Weex，hostCreateElement 方法就不再是操作 DOM而是平台相关的 API了，这些平台相关的方法是在创建渲染器阶段作为参数传入的 
创建完 DOM 节点后，接下来要做的是判定如果有 props 的话给这个 DOM 节点添加相关的 class、style、event等属性，并做相关的处理这些逻辑都是在 hostPatchProp 函数内部做的 

DOM和VNode都是一棵树，而且结构和DOM逐一映射。 

处理完全部子节点后， 通过insert的方法把创建DOM元素节点挂载到content下
因为 insert 的实行是在处理子节点后，所以挂载的顺序是先子节点，后父节点
最终挂载到最外层的容器上
在 mountChildren 的时候递归实行的是 patch 函数，而不是 mountElement 函数
这是因为子节点大概有其他类型的vnode，比如组件 vnode

 

• 梳理了组件渲染的过程，本质上就是把各种类型的 vnode 渲染成真实 DOM
  
• 组件是由模板、组件形貌对象和数据构成的，数据的变化会影响组件的变化
  
• 组件的渲染过程中创建了一个带副作用的渲染函数
  
• 当数据变化的时候就会实行这个渲染函数来触发组件的更新 
  

③ 副作用渲染函数更新组件的过程

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4