9.29深信服前端一面
下午5点到6点的样子吧
但是u覅u额防护
1、写一个编程题目，类似树转数组，不过这次是树转map结构，大差不差的写了一会儿写完了
写完题目后问了几个问题，一些回答的不好的才记起来
2、组件间传值的方法，事件总线的本质，就是vue实例
props、$emit、事件总线、vuex、provide和inject、
———eventBus的实质
公共事件总线eventBus的实质就是创建一个vue实例，通过一个空的vue实例作为桥梁实现vue组件间的通信。它是实现非父子组件通信的一种解决方案。
第一步：项目中创建一个js文件（我通常给它取个名字为bus.js），引入vue，创建一个vue实例，导出这个实例，代码如下（一共就两行）：
import Vue from 'Vue' export default new Vue第二步：在两个需要通信的两个组件中分别引入这个bus.js
import Bus from '引入bus.js的路径'第三步：传递数据的组件里，通过vue实列的方法$emit发送事件名称和需要传递的数据（发送数据组件）
Bus.$emit('click',data)//这个click是一个自定义事件，data就是要传递的数据 第四步，被传递数据的组件内通过vue实例方法监听$on到事件和接收到数据（接收数据的组件）这里常挂载监听在vue生命周期created和mounted当中的一个） Bus.$on（'click',target=>{
console.log(target)//注意发送和监听的事件名称必须一致，target就是获取的数据
}） 3、css加载会不会阻塞dom树解析，css渲染会不会阻塞dom树的渲染啥的
css不会阻塞DOM树的解析
css加载会阻塞DOM树的解析
css加载会阻塞后面js语句的执行
可见一开始，dom树的构建和css是分开的，因此css不会阻塞dom树的构建；
DOM+CSSOM=渲染树，渲染树由DOM树，CSSOM树合并而成，但并不是必须等CSSOM树加载完成后才开始加载合并构建渲染树，三者的构建并无先后条件，亦并非相互独立，而是会有交叉，并行构建，因此会出现一边加载，一边解析，一边渲染的工作现象。
css不会阻塞DOM解析，但是会阻塞DOM渲染
js会阻塞DOM解析
CSS 加载不会阻塞 DOM 树的解析
由浏览器的渲染流程图可知，DOM 解析和 CSS 解析是两个并行的进程，所以 CSS 加载不会阻塞 DOM 树的解析
CSS 加载会阻塞 DOM 树的渲染
Render Tree是依赖于 DOM Tree 和 CSSOM Tree 的，所以无论 DOM Tree 是否已经完成，它都必须等待到 CSSOM Tree 构建完成，即 CSS 加载完成（或 CSS 加载失败）后，才能开始渲染。
因此，CSS加载是会阻塞 DOM 树的渲染
Render Tree是依赖于 DOM Tree 和 CSSOM Tree 的，所以无论 DOM Tree 是否已经完成，它都必须等待到 CSSOM Tree 构建完成，即 CSS 加载完成（或 CSS 加载失败）后，才能开始渲染。
因此，CSS加载是会阻塞 DOM 树的渲染
CSS 加载会阻塞其后的 JS 执行
由浏览器的渲染流程图可知，JS 的加载、解析与执行会阻塞 DOM 的构建，也就是说，在构建 DOM 时，HTML 解析器若遇到了 JS，那么它会暂停构建 DOM ，将控制权移交给JS引擎，等 JS 引擎运行完毕，浏览器再从中断的地方恢复 DOM 构建。
由浏览器的渲染流程图可知，JS 的加载、解析与执行会阻塞 DOM 的构建，也就是说，在构建 DOM 时，HTML 解析器若遇到了 JS，那么它会暂停构建 DOM ，将控制权移交给JS引擎，等 JS 引擎运行完毕，浏览器再从中断的地方恢复 DOM 构建。
渲染的流程大致分为：
- 处理HTML标记并构建DOM树
- 处理CSS标记并构建CSSOM树
- 将DOM和CSSOM合并成一个渲染树
- 根据渲染树来布局，以计算每个节点的几何信息
- 将各个节点绘制到屏幕上
4、async和defer
script标签用于加载脚本与执行脚本，是前端开发中非常重要的标签
直接使用script脚本的话，html会按照顺序来加载并执行脚本，在脚本加载及执行分过程中，会阻塞后续的DOM渲染。
现在script提供了async和defer两个属性来解决DOM渲染阻塞的问题
直接使用script脚本的话，html会按照顺序来加载并执行脚本，在脚本加载及执行分过程中，会阻塞后续的DOM渲染。
现在script提供了async和defer两个属性来解决DOM渲染阻塞的问题
有 defer，加载后续文档元素的过程将和 script.js 的加载并行进行（异步），但是 script.js 的执行要在所有元素解析完成之后，DOMContentLoaded 事件触发之前完成。
推迟的脚本原则上按照它们被列出的次序执行。
推迟的脚本原则上按照它们被列出的次序执行。
如果你的脚本代码依赖于页面中的DOM元素（文档是否解析完毕），或者被其他脚本文件依赖。 例： 评论框、代码语法高亮 、polyfill.js
有 async，加载和渲染后续文档元素的过程将和 script.js 的加载与执行并行进行（异步）。
异步脚本不能保证按照它们在页面中出现的次序执行。
异步脚本不能保证按照它们在页面中出现的次序执行。
如：百度统计、Google
5、遍历objects的方法
for....in、objects.keys（）返回的是对象自身属性名组成的数组它会自动过滤掉原型链上的属性，可以通过数组的 forEach() 方法遍历；
Object.getOwnPropertyNames(),Reflect.ownKeys.
- ：Object.getOwnPropertySymbols()
- 返回值：一个给定对象自身的所有 Symbol 属性的数组
6、判断数组的方法
7、axios是对ajax的请求的封装，说一下ajax请求的过程，有没有对axios二次封装的必要？
一开始回答的没有，我真的不知道这时候已经提示有必要了呀！比如对一些请求的消息的封装啥的，mask遮罩层什么的需要二次封装
8、说说同源协议
9、浏览器缓存，强制缓存和协商缓存的请求头啥的，优先级
10、http常见的状态码说说
11、对称加密和非对称加密，https的混合加密说一说
12、内存泄漏的情况
系统进程不再用到的内存，没有及时释放，就叫内存泄漏，当内存占用越来越高，轻则影响系统性能，重则导致进程崩溃，限制了浏览器所能使用的内存极限为1.4GB、
————引起内存泄漏的原因
——1、意外的全局变量、未声明的变量、（使用严格模式，use strict）
——2、闭包引起的内存泄漏，由于闭包可以读取函数内部的变量，然后让这些变量始终保存在内存中，如果在使用结束后没有将局部变量抢出
（解决方法：将事件处理函数定义在外部，解除闭包）
——3、没有清理的DOM元素引用，虽然在某个地方删除了元素，但是对象中还是存在对dom的引用
（解决办法：手动删除）
——4、被遗忘的定时器或者回调
定时器中有dom的引用，即使dom删除了，但是定时器还在，所以内存中还是有这个dom
——5、ES6中防止内存泄漏，推出两种新的数据结构，weakset和weakmap，他们对值的引用都是不计入垃圾回收机制的，也就是说如果其他对象都不再引用该对象，那么垃圾回收机制自动回收该对象所占用的内存。
每次先写题真的搞人心态~~~~
类似资料：