# 第31- 40 题

# 31、改造下面的代码，使之输出0 - 9，写出你能想到的所有解法。

for (var i = 0; i < 10; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000)
}

for (let i = 0; i < 10; i++) {
  setTimeout(() => {
    console.log(i);
  }, 1000)
}

for (var i = 0; i < 10; i++) {
  setTimeout((i) => {
    console.log(i);
  }, 1000, i)
}

for (var i = 0; i < 10; i++) {
  ((i) => {
    setTimeout(() => {
      console.log(i);
    }, 1000)
  })(i);
}

# 32、Virtual DOM 真的比操作原生 DOM 快吗？谈谈你的想法。

结论：没有任何框架比操作真是DOM快。

这是一个性能 Vs 可维护的取舍。框架给我们的是在不直接操作DOM的情况下，仍有不错的性能表现。

来自尤大的回答

# 1. 原生 DOM 操作 vs. 通过框架封装操作。

这是一个性能 vs. 可维护性的取舍。

框架的意义在于为你掩盖底层的 DOM 操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。没有任何框架可以比纯手动的优化 DOM 操作更快，因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作，它的实现必须是普适的。针对任何一个 benchmark(基准)，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能。

# 2. 对 React 的 Virtual DOM 的误解。

React 从来没有说过 “React 比原生操作 DOM 快”。 React 的基本思维模式是每次有变动就整个重新渲染整个应用。如果没有 Virtual DOM，简单来想就是直接重置 innerHTML。很多人都没有意识到，在一个大型列表所有数据都变了的情况下，重置 innerHTML 其实是一个还算合理的操作... 真正的问题是在 “全部重新渲染” 的思维模式下，即使只有一行数据变了，它也需要重置整个 innerHTML，这时候显然就有大量的浪费。

我们可以比较一下 innerHTML vs. Virtual DOM 的重绘性能消耗：

innerHTML: render html string O(template size) + 重新创建所有 DOM 元素 O(DOM size)
Virtual DOM: render Virtual DOM + diff O(template size) + 必要的 DOM 更新 O(DOM change)
Virtual DOM render + diff 显然比渲染 html 字符串要慢，但是！它依然是纯 js 层面的计算，比起后面的 DOM 操作来说，依然便宜了太多。可以看到，innerHTML 的总计算量不管是 js 计算还是 DOM 操作都是和整个界面的大小相关，但 Virtual DOM 的计算量里面，只有 js 计算和界面大小相关，DOM 操作是和数据的变动量相关的。前面说了，和 DOM 操作比起来，js 计算是极其便宜的。这才是为什么要有 Virtual DOM：它保证了
1. 不管你的数据变化多少，每次重绘的性能都可以接受；
2. 你依然可以用类似 innerHTML 的思路去写你的应用。

# 3. MVVM vs. Virtual DOM

相比起 React，其他 MVVM 系框架比如 Angular, Knockout 以及 Vue、Avalon 采用的都是数据绑定：通过 Directive/Binding 对象，观察数据变化并保留对实际 DOM 元素的引用，当有数据变化时进行对应的操作。 MVVM 的变化检查是数据层面的，而 React 的检查是 DOM 结构层面的。 MVVM 的性能也根据变动检测的实现原理有所不同：Angular 的脏检查使得任何变动都有固定的 O( watcher count) 的代价；Knockout/Vue/Avalon 都采用了依赖收集，在 js 和 DOM 层面都是 O(change)：

脏检查：scope digest O(watcher count) + 必要 DOM 更新 O(DOM change)

依赖收集：重新收集依赖 O(data change) + 必要 DOM 更新 O(DOM change)可以看到， Angular 最不效率的地方在于任何小变动都有的和 watcher 数量相关的性能代价。但是！当所有数据都变了的时候，Angular 其实并不吃亏。依赖收集在初始化和数据变化的时候都需要重新收集依赖，这个代价在小量更新的时候几乎可以忽略，但在数据量庞大的时候也会产生一定的消耗。 MVVM 渲染列表的时候，由于每一行都有自己的数据作用域，所以通常都是每一行有一个对应的 ViewModel 实例，或者是一个稍微轻量一些的利用原型继承的 "scope" 对象，但也有一定的代价。所以，MVVM 列表渲染的初始化几乎一定比 React 慢，因为创建 ViewModel / scope 实例比起 Virtual DOM 来说要昂贵很多。这里所有 MVVM 实现的一个共同问题就是在列表渲染的数据源变动时，尤其是当数据是全新的对象时，如何有效地复用已经创建的 ViewModel 实例和 DOM 元素。假如没有任何复用方面的优化，由于数据是 “全新” 的，MVVM 实际上需要销毁之前的所有实例，重新创建所有实例，最后再进行一次渲染！这就是为什么题目里链接的 angular/knockout 实现都相对比较慢。相比之下，React 的变动检查由于是 DOM 结构层面的，即使是全新的数据，只要最后渲染结果没变，那么就不需要做无用功。

Angular 和 Vue 都提供了列表重绘的优化机制，也就是 “提示” 框架如何有效地复用实例和 DOM 元素。比如数据库里的同一个对象，在两次前端 API 调用里面会成为不同的对象，但是它们依然有一样的 uid。这时候你就可以提示 track by uid 来让 Angular 知道，这两个对象其实是同一份数据。那么原来这份数据对应的实例和 DOM 元素都可以复用，只需要更新变动了的部分。或者，你也可以直接 track by $index 来进行 “原地复用”：直接根据在数组里的位置进行复用。在题目给出的例子里，如果 angular 实现加上 track by $index 的话，后续重绘是不会比 React 慢多少的。甚至在 dbmonster 测试中，Angular 和 Vue 用了 track by $index 以后都比 React 快: dbmon (注意 Angular 默认版本无优化，优化过的在下面）

顺道说一句，React 渲染列表的时候也需要提供 key 这个特殊 prop，本质上和 track-by 是一回事。

# 4. 性能比较也要看场合

在比较性能的时候，要分清楚初始渲染、小量数据更新、大量数据更新这些不同的场合。 Virtual DOM、脏检查 MVVM、数据收集 MVVM 在不同场合各有不同的表现和不同的优化需求。 Virtual DOM 为了提升小量数据更新时的性能，也需要针对性的优化，比如 shouldComponentUpdate 或是 immutable data。

初始渲染：Virtual DOM > 脏检查 >= 依赖收集
小量数据更新：依赖收集 >> Virtual DOM + 优化 > 脏检查（无法优化） > Virtual DOM 无优化
大量数据更新：脏检查 + 优化 >= 依赖收集 + 优化 > Virtual DOM（无法/无需优化）>> MVVM 无优化
不要天真地以为 Virtual DOM 就是快，diff 不是免费的，batching 么 MVVM 也能做，而且最终 patch 的时候还不是要用原生 API。在我看来 Virtual DOM 真正的价值从来都不是性能，而是它

为函数式的 UI 编程方式打开了大门；
可以渲染到 DOM 以外的 backend，比如 ReactNative。

# 5. 总结

以上这些比较，更多的是对于框架开发研究者提供一些参考。主流的框架 + 合理的优化，足以应对绝大部分应用的性能需求。如果是对性能有极致需求的特殊情况，其实应该牺牲一些可维护性采取手动优化：比如 Atom 编辑器在文件渲染的实现上放弃了 React 而采用了自己实现的 tile-based rendering；又比如在移动端需要 DOM-pooling 的虚拟滚动，不需要考虑顺序变化，可以绕过框架的内置实现自己搞一个。

附上尤大的回答链接链接：https://www.zhihu.com/question/31809713/answer/53544875 (opens new window)

# 33、下面的代码打印什么内容，为什么？

var b = 10;
(function b() {
  // 内部作用域，会先去查找是有已有变量b的声明，有就直接赋值20，确实有了呀。发现了具名函数 function b(){}，拿此b做赋值；
  // IIFE的函数无法进行赋值（内部机制，类似const定义的常量），所以无效。
  // （这里说的“内部机制”，想搞清楚，需要去查阅一些资料，弄明白IIFE在JS引擎的工作方式，堆栈存储IIFE的方式等）
  b = 20;
  console.log(b);
})();

结果：

ƒ b() {
    b = 20;
    console.log(b)
}

原因：在执行上下文中包含作用域链特性：声明提前：一个声明在函数体内都是可见的，函数声明优先于变量声明。在非匿名的自执行函数中，函数变量为只读不可修改。

# 34 、简单改造下面的代码，使之分别打印 10 和 20。

var b = 10;
(function b() {
  b = 20;
  console.log(b);
})();

var b = 10;
(function b() {
  b = 20;
  console.log(window.b);
})();

var b = 10;
(function c() {
  b = 20;
  console.log(b);
})();

# 35、浏览器读取缓存规则

可以从Service Work、Memory Cache、Disk Cache和Push Cache, 那请求的时候from Memory Cache和 from Dish Cache的依据是什么，哪些数据什么时候存放在Memory Cache和Disk Cache中？

强缓存： expires max-age

协商缓存： last-modify/if-modify-since

Etag/if-none-match

cache-control：

no-store 不用缓存 no-cache 协商缓存 public 允许客户端和代理器进行缓存 private 只允许客户端进行缓存，代理服务器不能缓存。默认值。

# 36、使用迭代的方法实现flatten函数。

let arr = [1, 2, [3, 4, 5, [6, 7], 8], 9, 10, [11, [12, 13]]];

// 迭代

function flatten(arr) {
  let arrs = [...arr];
  let result = [];

  while (arrs.length) {
    const cur = arrs.pop()
    if (Array.isArray(cur)) {
      arrs.unshift(...cur);
    } else {
      result.push(cur);
    }
  }
  return result;
}

// 递归
const flatten = array => array.reduce((acc, cur) => (Array.isArray(cur) ? [...acc, ...flatten(cur)] : [...acc, cur]), [])

# 37、为什么Vue的mutation和React的reduce不能做异步操作.

因为更改state的函数必须是纯函数，纯函数即统一输入就会统一输出，没有任何副作用；如果是异步怎会引入额外的副作用，导致更改后的state不可预测。

# 38、下面代码中 a 在什么情况下会打印 1？

var a = ?;
if (a == 1 && a == 2 && a == 3) {
  console.log(1);
}

// 较运算符时候,隐式转换会调用本类型toString或valueOf方法.

var a = {
  i: 1,
  toString() {
    return a.i++
  }
}
var a = { num: 0 };
a.valueOf = function () {
  return ++a.num
}

// 数据劫持
Object.defineProperty('window', 'a', {
  configurable: false, // 能否被删除
  enumerable: true, // 是否可被枚举
  writable: true , // 能否被改变 默认三个都是false
  get: () => {
    return this.value++;
  }
})

# 39、介绍下BFC及其应用

BFC：块级格式化上下文，是页面盒模型布局的一种css渲染模式，相当于一个独立的容器，和外边的元素互不影响。

创建BFC方式有：

html
overflow：不为visible(hidden/scroll/auto)
position：absolute/fixed
display：table/flex
flat 非none

作用：

清除浮动
防止同一BFC下相邻元素的外边距重叠问题。

# 40、在 Vue 中，子组件为何不可以修改父组件传递的 Prop

如果修改了，Vue 是如何监控到属性的修改并给出警告的。

为了保证数据的单向流动，便于对数据进行追踪，避免数据混乱。

然而 props传入的是对象的话是可以直接在子组件里更改的, 因为是同一个引用

组件对于data的监听是深度监听
而对于props的监听是浅度监听

← 第21-30题第 41 - 50 题 →