JavaScript Ⅱ

最新推荐文章于 2024-07-04 17:29:59 发布

置顶 Henry23.

最新推荐文章于 2024-07-04 17:29:59 发布

阅读量244

点赞数

分类专栏： js 面试

本文链接：https://blog.csdn.net/Ayun0420/article/details/100020598

版权

面试同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

5 篇文章 0 订阅

订阅专栏

JavaScript Ⅱ

你使用过哪些数据格式，它们各有什么特点？
JSON 的了解
xml和json的区别，请用四个词语来形容
- JSON 和 JSONP 的区别？
前端拓展
Javascript中callee和caller的作用？
window.onload和$(document).ready
前端路由与后端路由
路由：
前端路由
后端路由
对比
前端渲染：
后端渲染：
进程线程协程
- 协程：
- - 定义
  - 运行流程

你使用过哪些数据格式，它们各有什么特点？

答: HTML格式 ,JSON格式,javascript格式,XML格式
1 HTML片段提供外部数据一般来说是最简单的。
2 如果数据需要重用，而且其他应用程序也可能一次受到影响，那么在性能和文件大小方面具有优势的JSON通常是不错的选择。
3 而当远程应用程序未知时，XML则能够为良好的互操作性提供最可靠的保证。

JSON 的了解

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式
它是基于JavaScript的一个子集。数据格式简单, 易于读写, 占用带宽小
JSON字符串转换为JSON对象:

var obj =eval('('+ str +')');
var obj = str.parseJSON();
var obj = JSON.parse(str);

JSON对象转换为JSON字符串：

var last=obj.toJSONString();
var last=JSON.stringify(obj);

xml和json的区别，请用四个词语来形容

· JSON相对于XML来讲，数据的体积小，传递的速度更快些
· JSON与JavaScript的交互更加方便，更容易解析处理，更好的数据交互
· JSON的速度要远远快于XML
· XML对数据描述性比较好；

JSON 和 JSONP 的区别？

JSON 返回的是一串 JSON 格式数据；而 JSONP 返回的是脚本代码（包含一个函数调用）。

前端拓展

模块化开发怎么做？

立即执行函数不暴露私有成员

var module1 = (function() {
  var _count = 0;
  var m1 = function() {
    //...
  };
  var m2 = function() {
    //...
  };
  return {
    m1 : m1,
    m2 : m2
  };
})()

webpack 如何实现打包的？

webpack是一个模块打包工具，webpack可以管理模块依赖，并编译输出各模块所需静态文件，它能够很好地管理，打包web开发中所用到的html，css，js以及各种静态文件（图片，字体），让开发过程更加高效。对于不同类型的资源，webpack有对应的模块加载器。webpack模块打包器分析模块间的依赖关系，最后生成优化且合并后的静态资源。

Commonjs AMD CMD ES模块协议区别

CommonJS 加载模块是同步的，所以只有加载完成才能执行后面的操作。像Node.js主要用于服务器的编程，加载的模块文件一般都已经存在本地硬盘，所以加载起来比较快，不用考虑异步加载的方式，所以CommonJS规范比较适用。但如果是浏览器环境，要从服务器加载模块，这是就必须采用异步模式。所以就有了 AMD CMD 解决方案。
CommonJS 是服务器端模块的规范，Node.js 采用了这个规范。CommonJS 规范加载模块是同步的，也就是说，只有加载完成，才能执行后面的操作。AMD 规范则是非同步加载模块，允许指定回调函数。
AMD 推荐的风格通过返回一个对象做为模块对象，CommonJS 的风格通过对 module.exports 或 exports 的属性赋值来达到暴露模块对象的目的。
AMD 是 RequireJS 在推广过程中对模块定义的规范化产出
CMD是SeaJS 在推广过程中对模块定义的规范化产出
AMD与CMD的区别有以下几点：

1.对于依赖的模块AMD是提前执行，CMD是延迟执行。不过RequireJS从2.0开始，也改成可以延迟执行（根据写法不同，处理方式不通过）。

2.AMD推崇依赖前置，CMD推崇依赖就近。

ES6 Modules
ES6正式提出了内置的模块化语法，我们在浏览器端无需额外引入requirejs来进行模块化。
ES6中的模块有以下特点：

模块自动运行在严格模式下
在模块的顶级作用域创建的变量，不会被自动添加到共享的全局作用域，它们只会在模块顶级作用域的内部存在；
模块顶级作用域的 this 值为 undefined
对于需要让模块外部代码访问的内容，模块必须导出它们

Javascript中callee和caller的作用？

caller是返回一个对函数的引用，该函数调用了当前函数；
callee是返回正在被执行的function函数，也就是所指定的function对象的正文

window.onload和$(document).ready

window.onload()方法是必须等到页面内包括图片的所有元素加载完毕后才能执行。
$(document).ready()是DOM结构绘制完毕后就执行，不必等到加载完毕

前端路由与后端路由

https://zhuanlan.zhihu.com/p/24814675
https://juejin.im/post/5b10b46df265da6e2a08a724
https://juejin.im/post/5abae9acf265da2378404fc8

路由：

路由就是URL到函数（前端函数||后端函数）的映射。
访问的URL会映射到相应的函数里（这个函数是广义的，可以是前端的函数也可以是后端的函数），然后由相应的函数来决定返回给这个URL什么东西。路由就是在做一个匹配的工作。
服务器端路由的映射函数:
静态资源服务器：文件读取
动态资源服务器：数据可读写操作，数据处理
前端路由的映射函数：
DOM操作
页面组件的显示隐藏

前端路由

https://juejin.im/post/5d2d19ccf265da1b7f29b05f
http://blog.xiaoboma.com/2017/01/24/%E5%89%8D%E7%AB%AF%E8%B7%AF%E7%94%B1/

定义：就是在保证只有一个 HTML 页面，且与用户交互时不刷新和跳转页面的同时，为 SPA 中的每个视图展示形式匹配一个特殊的 url。在刷新、前进、后退和SEO时均通过这个特殊的 url 来实现。

由来

用ajax请求，可以让页面无刷新，页面变了但Url没有变化，用户就不能复制到想要的地址，用前端路由做单页面网页就很好的解决了这个问题。但是前端路由使用浏览器的前进，后退键的时候会重新发送请求，没有合理地利用缓存。

优点：用户体验好，不需要每次都从服务器全部获取，快速展现给用户

缺点：

使用浏览器的前进，后退键的时候会重新发送请求，没有合理地利用缓存
单页面无法记住之前滚动的位置，无法在前进，后退的时候记住滚动的位置

原理：

页面跳转的URL规则匹配由前端来控制

实现方式

基于Hash的前端路由，优点是兼容性高。缺点是URL带有#号不好看

实现原理

URL中 # 及其后面的部分为 hash。
hash仅仅是客户端的一个状态，也就是说，当向服务器发请求的时候，hash部分并不会发过去。
通过监听 window 对象的 hashChange 事件，可以实现简单的路由。

基于History （pushState + popstate+pushState）的前端路由，优点是URL不带#号，好看。缺点是既需要浏览器支持也需要后端服务器支持

实现原理

通过HTML5 History API可以在不刷新页面的情况下，直接改变当前URL。详细用法可以参考：
history 的改变并不会触发任何事件，所以我们无法直接监听 history 的改变而做出相应的改变。
拦截所有可能触发 history 改变的情况，变相地监听 history 的改变。
通过监听 window 对象的 popstate 事件，捕获前进或后退事件
全局阻止A链接的默认事件，获取A链接的href属性，调用history.pushState（添加新的状态到历史状态栈）方法改变url，然后再调用响应的路由映射函数
在 JS 代码中触发 history.pushState 函数与 history.replaceState（用新的状态代替当前状态）函数改变url。然后再调用响应的路由映射函数

缺点详解：基于History API的路由需要对服务器做一些改造。

history模式下，通过以上三个方式在修改 url 后，虽然页面并不会刷新，
但如果我们在手动刷新，或通过 url 直接进入应用的时候，服务端是无法识别这个 url 的。因为我们是单页应用，只有一个 html 文件，服务端在处理其他路径的 url 的时候，就会出现404的情况。
所以，如果要应用 history 模式，需要在服务端增加一个覆盖所有情况的候选资源：如果 URL 匹配不到任何静态资源，则应该返回单页应用的 html 文件。

后端路由

定义：通过用户请求的url导航到具体的html页面；每跳转到不同的URL，都是重新访问服务端，然后服务端返回页面，页面也可以是服务端获取数据，然后和模板组合，返回HTML，也可以是直接返回模板HTML，然后由前端js再去请求数据，使用前端模板和数据进行组合，生成想要的HTML

对比

后端每次路由请求都是重新访问服务器
前端路由实际上只是JS根据URL来操作DOM元素，根据每个页面需要的去服务端请求数据，返回数据后和模板进行组合
从性能和用户体验的层面来比较的话，后端路由每次访问一个新页面的时候都要向服务器发送请求，然后服务器再响应请求，这个过程肯定会有延迟。而前端路由在访问一个新页面的时候仅仅是变换了一下路径而已，没有了网络延迟，对于用户体验来说会有相当大的提升。

前端渲染：

定义：指的是后端返回JSON数据，前端利用预先写的html模板，循环读取JSON数据，拼接字符串（es6的模板字符串特性大大减少了拼接字符串的的成本），并插入页面。
好处：网络传输数据量小。不占用服务端运算资源（解析模板），模板在前端（很有可能仅部分在前端），改结构变交互都前端自己来了，改完自己调就行。
坏处：前端耗时较多，对前端工作人员水平要求相对较高。前端代码较多，因为部分以前在后台处理的交互逻辑交给了前端处理。占用少部分客户端运算资源用于解析模板。