9道价值20k薪资的“VUE必备面试题”,快来围观!

关于Vue框架部分,总会涉及一些高频面试题,大多数看似非常初级。

有些纯记忆性质的面试题,我们在官方文档很容易就能查看到。


举个例子:

vue组件之间如何通信?

vue生命周期有哪些?

这类面试题在文档中就能找到答案,网络上面找到的答案也是千篇一律。大家只要使用过vue并且稍加记忆即可流畅作答。

但是,如果我们也这样回答,那就算自己真的比其他竞争者更有实力,也很难脱颖而出,更别提获得高薪offer了。

怎么才能避免这种情况呢?

很简单,其实面试官提出这类“常见问题”时,就意味着他想要听到“不常见的答案”。

我们只要将回答问题的方式、思路提升一个层级,给出标新立异的高水准解答,拿下高薪Offer就如探囊取物一般简单!

下面,我们就一起来看看,“价格不菲”的面试题,都有哪些?


(1)v-if和v-for谁的优先级最高?

当面试官提出这个问题时,显然想要考察应聘者对v-if和v-for的“基本功”,同时还想要考察应聘者如何将理论应用到操作里

基于以上两点,我们可以拓展问题:

当v-if和v-for同时出现时,我们应该怎样优化从而获得更好的性能?

得知了面试官的隐含问题,接下来我们对症下药就可以了。

首先,在源码中找答案:

compiler/codegen/index.js(☜文件中的位置)

做个测试如下:

两者同级时,渲染函数如下:

_l包含了isFolder的条件判断☝☝

两者不同级时,渲染函数如下:

先判断条件再决定是否执行☝☝

正确解答:

1、显然v-for优先于v-if被解析(把你是怎么知道的告诉面试官

2、如果同时出现,每次渲染都会先执行循环再判断条件,无论如何循环都不可避免,浪费了性能

3、要避免出现这种情况,则在外层嵌套template,在这一层进行v-if判断,然后在内部进行v-for循环

4、如果条件出现在循环内部,可通过计算属性提前过滤掉那些不需要显示的项

顺便推荐一份Vue、js等相关面试题,点击下方就能1毛钱带走,即刻get前端必学3大技能!

三天时间,能使用Vue3.0新语法开发项目,从源码层面分析Vue3.0,掌握新的响应式 vdom架构:


(2)VUE组件data为什么必须是函数

我们都知道,VUE的data实例必须是函数,那么有没有与之相反的情况呢?答案是肯定的,因为VUE的根实例就没有“必须是函数”这个限制的。

所以,我们在对这道题进行解答之前,我们还要考虑与“VUE组件data对象实例”所对应的“VUE的根实例”。

通过两者的对比论证,会让我们的答案更加清晰缜密、更有说服力。

源码中找答案:

src\core\instance\state.js - initData()

文件中的位置☝

通过源码得知:

函数每次执行都会返回全新data对象实例

测试代码如下:

然而程序甚至无法通过vue检测☟☟

正确解答:

Vue组件可能存在多个实例,如果使用对象形式定义data,则会导致它们共用一个data对象,那么状态变更将会影响所有组件实例,这是不合理的;

采用函数形式定义,在initData时会将其作为工厂函数返回全新data对象,有效规避多实例之间状态污染问题。

而在Vue根实例创建过程中则不存在该限制,也是因为根实例只能有一个,不需要担心这种情况。

(3)vue中key的作用和工作原理

为了表达的更加透彻,我们可以通过对比测试来寻找key的工作原理:

首先是在源码中找答案,它在文件中的位置是☟

src\core\vdom\patch.js - updateChildren()

测试代码如下:

本次案例代码重现的是以下过程☟☟:

在不使用Key的情况下是这样的☟☟:

如果使用Key☟☟:

// 首次循环patch A

A B C D E

A B F C D E

// 第2次循环patch B

B C D E

B F C D E

// 第3次循环patch E

C D E

F C D E

// 第4次循环patch D

C D

F C D

// 第5次循环patch C

C

F C

// oldCh全部处理结束,newCh中剩下的F,创建F并插入到C前面

正确解答:

1、key的作用主要是为了高效的更新虚拟DOM,其原理是vue在patch过程中通过key可以精准判断两个节点是否是同一个,从而避免频繁更新不同元素,使得整个patch过程更加高效,减少DOM操作量,提高性能。

2、另外,若不设置key还可能在列表更新时引发一些隐蔽的bug

3、vue中在使用相同标签名元素的过渡切换时,也会使用到key属性,其目的也是为了让vue可以区分它们,否则vue只会替换其内部属性而不会触发过渡效果。

(4)你怎么理解vue中的diff算法?

在分析diff算法之前,我们可以看一下VUE的diff算法模型图:

接下来还是先从源码入手解决问题:

源码分析1:必要性

lifecycle.js - mountComponent()

组件中可能存在很多个data中的key使用

源码分析2:执行方式

patch.js - patchVnode()

patchVnode是diff发生的地方

整体策略:深度优先,同层比较

源码分析3:高效性

patch.js - updateChildren()

测试代码如下:

正确解答:

1、diff算法是虚拟DOM技术的必然产物:通过新旧虚拟DOM作对比(即diff),将变化的地方更新在真实DOM上;

另外,也需要diff高效的执行对比过程,从而降低时间复杂度为O(n)。

2、vue 2.x中为了降低Watcher粒度,每个组件只有一个Watcher与之对应,只有引入diff才能精确找到发生变化的地方。

3、vue中diff执行的时刻是组件实例执行其更新函数时,它会比对上一次渲染结果oldVnode和新的渲染结果newVnode,此过程称为patch

4、diff过程整体遵循深度优先、同层比较的策略;两个节点之间比较会根据它们是否拥有子节点或者文本节点做不同操作;

比较两组子节点是算法的重点,首先假设头尾节点可能相同做4次比对尝试;

如果没有找到相同节点才按照通用方式遍历查找,查找结束再按情况处理剩下的节点;

借助key通常可以非常精确找到相同节点,因此整个patch过程非常高效。

(5)谈一谈对vue组件化的理解?

听到“理解”两个字我们就要注意了,看似一道开放性的问题,实际是要考察我们对VUE组件化的认知基础。

我们可以从定义、优点、使用场景和注意事项等方面展开陈述,同时要强调vue中组件化的一些特点。

始终不变的是“从源码深入解决问题,最终达到深入浅出的效果。”

源码分析1:组件定义

src\core\global-api\assets.js
(☝文件中的位置)
// 组件定义
Vue.component('comp', {
template: '<div>this is a component</div>'
})

vue-loader会编译template为render函数,最终导出的依然是组件配置对象。☟

<template>
<div>
        this is a component
    </div>
</template>

源码分析2:组件化优点

lifecycle.js - mountComponent()

☝组件、Watcher、渲染函数和更新函数之间的关系

源码分析3:组件化实现

构造函数,

src\core\global-api\extend.js

实例化及挂载,

src\core\vdom\patch.js - createElm()

正确解答:

1、组件是独立和可复用的代码组织单元。组件系统是 Vue 核心特性之一,它使开发者使用小型、独立和通常可复用的组件构建大型应用;

2、组件化开发能大幅提高应用开发效率、测试性、复用性等;

3、组件使用按分类有:页面组件、业务组件、通用组件;

4、vue的组件是基于配置的,我们通常编写的组件是组件配置而非组件,框架后续会生成其构造函数,它们基于VueComponent,扩展于Vue;

5、vue中常见组件化技术有:属性prop,自定义事件,插槽等,它们主要用于组件通信、扩展等;

6、合理的划分组件,有助于提升应用性能;

7、组件应该是高内聚、低耦合的;

8、遵循单向数据流的原则。

(6)谈一谈对vue设计原则的理解?

和上一题的思路一样,我们首先要明确:关于VUE设计原则,我们要从哪几个方面入手进行详细解答?

而在vue的官网上,就写着大大的定义和特点:

渐进式JavaScript框架

易用、灵活和高效

所以阐述此题的整体思路按照这个展开即可。

正确解答:

首先就是渐进式JavaScript框架:

与其它大型框架不同的是,Vue 被设计为可以自底向上逐层应用。

Vue 的核心库只关注视图层,不仅易于上手,还便于与第三方库或既有项目整合。

另一方面,当与现代化的工具链以及各种支持类库结合使用时,Vue 也完全能够为复杂的单页应用提供驱动。

易用性

vue提供数据响应式、声明式模板语法和基于配置的组件系统等核心特性。

这些使我们只需要关注应用的核心业务即可,只要会写js、html和css就能轻松编写vue应用。

灵活性

渐进式框架的最大优点就是灵活性,如果应用足够小,我们可能仅需要vue核心特性即可完成功能;

随着应用规模不断扩大,我们才可能逐渐引入路由、状态管理、vue-cli等库和工具;

不管是应用体积还是学习难度都是一个逐渐增加的平和曲线。

高效性

超快的虚拟 DOM 和 diff 算法使我们的应用拥有最佳的性能表现。

追求高效的过程还在继续,vue3中引入Proxy对数据响应式改进以及编译器中对于静态内容编译的改进都会让vue更加高效。

(7)对MVC、MVP和MVVM的理解

当我们面对这道考题时,往往有些摸不着头脑,因为MVC、MVP和MVVM的知识点非常广泛,很难做到说清、说透。

那要怎么才能回答的简洁有条理?让面试官眼前一亮呢?

来听我给你清晰解读一下这道题的正确思路吧!

其实在日常工作中,类似MVP、MVC这类前端程序,我们程序员甚至自己都没用过,这恰恰就反映了:

前端这些年从无到有,从有到优的变迁过程。

想到这里,我们的解题思路便慢慢浮出水面了,那就是:

按时间顺序,浅谈MVC、MVP、MVVM等系列产品的更新迭代。

Web1.0时代

在web1.0时代,并没有前端的概念。

开发一个web应用多数采用:

ASP.NET/Java/PHP编写,

项目通常由多个aspx/jsp/php文件构成。

每个文件中同时包含了HTML、CSS、JavaScript、C#/Java/PHP代码。

系统整体架构可能是这样子的☟:

这种架构的好处是简单快捷,但是,缺点也非常明显:JSP代码难以维护

为了让开发更加便捷,代码更易维护,前后端职责更清晰。便衍生出MVC开发模式和框架,前端展示以模板的形式出现。

典型的框架就是:

Spring、Structs、Hibernate。

整体框架如图所示☟:

使用这种分层架构,职责清晰,代码易维护。

但这里的MVC仅限于后端,前后端形成了一定的分离,前端只完成了后端开发中的view层。

但是,同样的这种模式存在着一些问题:

1、前端页面开发效率不高

2、前后端职责不清

web 2.0时代

自从Gmail的出现,ajax技术开始风靡全球。有了ajax之后,前后端的职责就更加清晰了。

因为前端可以通过Ajax与后端进行数据交互,因此,整体的架构图也变化成了下面这幅图☟:


通过ajax与后台服务器进行数据交换,前端开发人员,只需要开发页面这部分内容,数据可由后台进行提供。

而且ajax可以使得页面实现部分刷新,减少了服务端负载和流量消耗,用户体验也更佳。

这时,才开始有专职的前端工程师。同时前端的类库也慢慢的开始发展,最著名的就是jQuery了。

当然,此架构也存在问题:缺乏可行的开发模式承载更复杂的业务需求,页面内容都杂糅在一起,一旦应用规模增大,就会导致难以维护了。

因此,前端的MVC也随之而来。

前后端分离后的架构演变——MVC、MVP和MVVM

MVC

前端的MVC与后端类似,具备着View、Controller和Model。

Model:负责保存应用数据,与后端数据进行同步

Controller:负责业务逻辑,根据用户行为对Model数据进行修改

View:负责视图展示,将model中的数据可视化出来。

三者形成了一个如图所示的模型:


这样的模型,在理论上是可行的。但往往在实际开发中,并不会这样操作。因为开发过程并不灵活。

例如,一个小小的事件操作,都必须经过这样的一个流程,那么开发就不再便捷了。

在实际场景中,我们往往会看到另一种模式,

如图所示☟:


这种模式在开发中更加的灵活,backbone.js框架就是这种的模式。

但是,这种灵活可能导致严重的问题:

1、数据流混乱:如下图☟

2、View比较庞大,而Controller比较单薄:

由于很多的开发者都会在view中写一些逻辑代码,逐渐的就导致view中的内容越来越庞大,而controller变得越来越单薄。

既然有缺陷,就会有变革。

前端的变化中,似乎少了MVP的这种模式,是因为AngularJS早早地将MVVM框架模式带入了前端。

MVP模式虽然前端开发并不常见,但是在安卓等原生开发中,开发者还是会考虑到它。

MVP

MVP与MVC很接近,P指的是Presenter,presenter可以理解为一个中间人。

它负责着View和Model之间的数据流动,防止View和Model之间直接交流。

我们可以看一下图示☟


我们可以通过看到,presenter负责和Model进行双向交互,还和View进行双向交互。

这种交互方式,相对于MVC来说少了一些灵活,VIew变成了被动视图,并且本身变得很小。虽然它分离了View和Model。

但是应用逐渐变大之后,导致presenter的体积增大,难以维护。

要解决这个问题,或许可以从MVVM的思想中找到答案。

MVVM

首先,何为MVVM呢?MVVM可以分解成(Model-View-VIewModel)。

ViewModel可以理解为在presenter基础上的进阶版。如图所示☟☟:



ViewModel通过实现一套数据响应式机制自动响应Model中数据变化;

同时Viewmodel会实现一套更新策略自动将数据变化转换为视图更新;

通过事件监听响应View中用户交互修改Model中数据。

这样在ViewModel中就减少了大量DOM操作代码。

MVVM在保持View和Model松耦合的同时,还减少了维护它们关系的代码,使用户专注于业务逻辑,兼顾开发效率和可维护性。

总结:

这三者都是框架模式,它们设计的目标都是为了解决Model和View的耦合问题。

MVC模式出现较早主要应用在后端,如Spring MVC、ASP.NET MVC等,在前端领域的早期也有应用,如Backbone.js。

它的优点是分层清晰,缺点是数据流混乱,灵活性带来的维护性问题。

MVP模式在是MVC的进化形式,Presenter作为中间层负责MV通信,解决了两者耦合问题,但P层过于臃肿会导致维护问题。

MVVM模式在前端领域有广泛应用,它不仅解决MV耦合问题,还同时解决了维护两者映射关系的大量繁杂代码和DOM操作代码,在提高开发效率、可读性同时还保持了优越的性能表现。

(8)你了解哪些Vue性能优化方法?

相对其他的“陷阱面试题”,这个问题就显得友善了很多,只要我们基础功底扎实,回答得井井有条并不是难事。

首先,我们要找到VUE性能的现存问题,大部分都是代码层面的,然后具体的提出代码层优化意见就可以了。

目前我们所知的VUE代码层优化大致为一下11点,村长已经都帮大家整理好了,请大家随意消化一下:

●路由懒加载

●keep-alive缓存页面
●使用v-show复用DOM
●v-for 遍历避免同时使用 v-if
●长列表性能优化
●事件的销毁
●图片懒加载
●第三方插件按需引入
●无状态的组件标记为函数式组件
●子组件分割
●变量本地化

●SSR

下面是针对这11个优化点给出的具体优化方案:

●路由懒加载☟

const router = new VueRouter({
  routes: [
    { path: '/foo', component: () => import('./Foo.vue') }
  ]
})

●keep-alive缓存页面☟

<template>

<div id="app">

<keep-alive>

<router-view/>

</keep-alive>

</div>

</template>

●使用v-show复用DOM☟


●v-for 遍历避免同时使用 v-if☟


●长列表性能优化:

如果列表是纯粹的数据展示,不会有任何改变,就不需要做响应化☟

如果是大数据长列表,可采用虚拟滚动,只渲染少部分区域的内容☟

参考:

vue-virtual-scroller☟

github.com/Akryum/vue-v
vue-virtual-scroll-list☟

github.com/tangbc/vue-v

●事件的销毁:

Vue 组件销毁时,会自动解绑它的全部指令及事件监听器,但是仅限于组件本身的事件。

created() {
  this.timer = setInterval(this.refresh, 2000)
},
beforeDestroy() {
  clearInterval(this.timer)
}

●图片懒加载:

对于图片过多的页面,为了加速页面加载速度。

所以很多时候我们需要将页面内未出现在可视区域内的图片先不做加载, 等到滚动到可视区域后再去加载。

<img v-lazy="/static/img/1.png">

参考项目:

vue-lazyload☟

github.com/hilongjw/vue

●第三方插件按需引入:

像element-ui这样的第三方组件库可以按需引入,避免体积太大。

import Vue from 'vue';
import { Button, Select } from 'element-ui';

 Vue.use(Button)
 Vue.use(Select)

●无状态的组件标记为函数式组件☟

●子组件分割

●变量本地化

●服务端渲染 - SSR

(9)你对Vue3.0的新特性有没有了解?

young村长帮大家总结了Vue3.0改进方向,主要在以下几点:

●更快

○虚拟DOM重写

○优化slots的生成

○静态树提升

○静态属性提升

○基于Proxy的响应式系统

●更小:

○通过摇树优化核心库体积

●更容易维护:

○TypeScript + 模块化

●更加友好

○跨平台:编译器核心和运行时核心与平台无关,使得Vue更容易与任何平台(Web、Android、iOS)一起使用

●更容易使用

○改进的TypeScript支持,编辑器能提供强有力的类型检查和错误及警告

●更好的调试支持

●独立的响应化模块

●Composition API

虚拟 DOM 重写

期待更多的编译时提示来减少运行时开销,使用更有效的代码来创建虚拟节点。

组件快速路径+单个调用+子节点类型检测

▷跳过不必要的条件分支

▷JS引擎更容易优化

详情见下图☟


优化slots生成

vue3中可以单独重新渲染父级和子级:

▷确保实例正确的跟踪依赖关系

▷避免不必要的父子组件重新渲染

详情见下图☟

静态树提升(Static Tree Hoisting)

使用静态树提升,这意味着 Vue 3 的编译器将能够检测到什么是静态的,然后将其提升,从而降低了渲染成本。

▷跳过修补整棵树,从而降低渲染成本

▷即使多次出现也能正常工作

详情见下图☟

静态属性提升

使用静态属性提升,Vue 3打补丁时将跳过这些属性不会改变的节点。☟


基于 Proxy 的数据响应式

Vue 2的响应式系统使用:

Object.defineProperty 的getter 和 setter。

Vue 3 将使用 ES2015 Proxy 作为其观察机制,这将会带来如下变化:

●组件实例初始化的速度提高100%

●使用Proxy节省以前一半的内存开销,加快速度,但是存在低浏览器版本的不兼容

●为了继续支持 IE11,Vue 3 将发布一个支持旧观察者机制和新 Proxy 版本的构建


高可维护性

Vue 3 将带来更可维护的源代码。它不仅会使用 TypeScript,而且许多包被解耦,更加模块化。

created() {
  this.timer = setInterval(this.refresh, 2000)
},
beforeDestroy() {
  clearInterval(this.timer)
}

三天时间,能使用Vue3.0新语法开发项目,从源码层面分析Vue3.0,掌握新的响应式 vdom架构:

编辑于 06-19