防抖

在事件被触发n秒后再执行回调，如果在这n秒内又被触发，则重新再等n秒在执行回调。

例子

//模拟一段ajax请求

function ajax(content) {

  console.log('ajax request ' + content)

}



let inputa = document.getElementById('unDebounce')



inputa.addEventListener('keyup', function (e) {

    ajax(e.target.value)

})

看一下运行结果：

可以看到，我们只要按下键盘，就会触发这次ajax请求。不仅从资源上来说是很浪费的行为，而且实际应用中，用户也是输出完整的字符后，才会请求。下面我们优化一下：

//模拟一段ajax请求



  function ajax(content) {

     console.log('ajax request' + content)

  }

  function debounce(fn, delay) {

    let timer;

    return function () {

      let context = this;

      const args = [...arguments];

      if (timer) {

        clearTimeout(timer);

      }

      timer = setTimeout(() => {

        fn.apply(context, args);

      }, delay);

    };

  }

  let dedebounceajax =  debounce(ajax,1000);

  var inputs = document.getElementById('inputs')

  inputs.addEventListener("keyup",(e)=>{

      dedebounceajax(e.target.value)

  })

看一下运行结果：

可以看到，我们加入了防抖以后，当你在频繁的输入时，并不会发送请求，只有当你在指定间隔内没有输入时，才会执行函数。如果停止输入但是在指定间隔内又输入，会重新触发计时。

节流

规定在一个单位时间内，只能触发一次函数。
假设你点击一个按钮规定了5秒生效，不管你在5秒内点击了按钮多少次，5秒只会生效一次。

例子

// 时间戳箭头函数版本 节流函数



function throttle(func, wait) {

    let timer = 0;

    return (...rest) => {

      let now = Date.now();

      let that = this;

      if (now > timer + delay) {

        fn.apply(that, rest);

        timer = now;

      }

    };

}



// 定时器版本 节流函数



function throttle(func, wait) {

    let timeout;

    return function() {

        let context = this;

        let args = arguments;

        if (!timeout) {

            timeout = setTimeout(() => {

                timeout = null;

                func.apply(context, args)

            }, wait)

        }



    }

}



let throttleAjax = throttle(ajax, 1000)

let inputc = document.getElementById('throttle')

inputc.addEventListener('keyup', function(e) {

    throttleAjax(e.target.value)

})



复制代码

看一下运行结果：

可以看到，我们在不断输入时，ajax会按照我们设定的时间，每1s执行一次。

总结

• 函数防抖和函数节流都是防止某一时间频繁触发，但是这两兄弟之间的原理却不一样。


• 函数防抖是某一段时间内只执行一次，而函数节流是间隔时间执行。

应用场景

防抖应用场景

• input框搜索，用户在不断输入值时，用防抖来节约请求资源。


• window触发resize的时候，不断的调整浏览器窗口大小会不断的触发这个事件，用防抖来让其只触发一次。

节流应用场景

• 鼠标不断点击触发，mousedown(单位时间内只触发一次)


• 监听滚动事件，比如是否滑到底部自动加载更多，用throttle来判断

写在前面

前端技术日新月异，我们需要不断学习来更新自己的前端知识并运用到自己的项目中。这次笔者整理一些未来普及或者现在同学们可能已经用到的CSS特性，包括SVG图标、滚动特性、CSS自定义属性、CSS现代伪类 、JS in CSS、Web Layout、混合模式和滤镜、CSS计数器等等。

滚动特性

在能用CSS实现的就不用麻烦JavaScript文章提及到滚动捕捉的特性，更多有关于容器滚动方面的CSS新特性其实还有有很多个，比如：

• 自定义滚动条的外观


• scroll-behavior指容容器滚动行为，让滚动效果更丝滑


• overscroll-behavior优化滚动边界，特别是可以帮助我们滚动的穿透

自定义滚动条的外观

默认的window外观和mac外观

windows

mac

在CSS中，我们可以使用-webkit-scrollbar来自定义滚动条的外观。该属性提供了七个伪元素：

• ::-webkit-scrollbar：整个滚动条


• ::-webkit-scrollbar-button：滚动条上的按钮（下下箭头）


• ::-webkit-scrollbar-thumb：滚动条上的滚动滑块


• ::-webkit-scrollbar-track：滚动条轨道


• ::-webkit-scrollbar-track-piece：滚动条没有滑块的轨道部分


• ::-webkit-scrollbar-corner：当同时有垂直和水平滚动条时交汇的部分


• ::-webkit-resizer：某些元素的交汇部分的部分样式（类似textarea的可拖动按钮）

html {

    --maxWidth:1284px;

    scrollbar-color: linear-gradient(to bottom,#ff8a00,#da1b60);

    scrollbar-width: 30px;

    background: #100e17;

    color: #fff;

    overflow-x: hidden

}



html::-webkit-scrollbar {

    width: 30px;

    height: 30px

}



html::-webkit-scrollbar-thumb {

    background: -webkit-gradient(linear,left top,left bottom,from(#ff8a00),to(#da1b60));

    background: linear-gradient(to bottom,#ff8a00,#da1b60);

    border-radius: 30px;

    -webkit-box-shadow: inset 2px 2px 2px rgba(255,255,255,.25),inset -2px -2px 2px rgba(0,0,0,.25);

    box-shadow: inset 2px 2px 2px rgba(255,255,255,.25),inset -2px -2px 2px rgba(0,0,0,.25)

}



html::-webkit-scrollbar-track {

    background: linear-gradient(to right,#201c29,#201c29 1px,#100e17 1px,#100e17)

}

通过这几个伪元素，可以实现你自己喜欢的滚动条外观效果，比如下面这个示例：

完整演示

css自定义属性

你大概已经听说过CSS自定义属性，也被称为 CSS 变量，估计熟悉SCSS、LESS就会很快上手，概念大同小异，都是让我们的CSS变得可维护，目前Edge最新版都已经支持这个特性了，这说明现在 CSS 自定义属性已经能用在实际项目中了，相信不久以后开发者们将大大依赖这个特性。但还请在使用之前请先检查一下本文附录中 Postcss 对于 CSS 自定义属性的支持情况，以便做好兼容。

什么是自定义属性呢？简单来说就是一种开发者可以自主命名和使用的 CSS 属性。浏览器在处理像 color 、position 这样的属性时，需要接收特定的属性值，而自定义属性，在开发者赋予它属性值之前，它是没有意义的。所以要怎么给 CSS 自定义属性赋值呢？这倒和习惯无异

.foo {

  color: red;

  --theme-color: gray;

}

自定义元素的定义由 -- 开头，这样浏览器能够区分自定义属性和原生属性，从而将它俩分开处理。假如只是定义了一个自定义元素和它的属性值，浏览器是不会做出反应的。如上面的代码， .foo 的字体颜色由 color 决定，但 --theme-color 对 .foo 没有作用。

你可以用 CSS 自定义元素存储任意有效的 CSS 属性值

.foo {

  --theme-color: blue;

  --spacer-width: 8px;

  --favorite-number: 3;

  --greeting: "Hey, what's up?";

  --reusable-shadow: 0 3px 1px -2px rgba(0, 0, 0, 0.85);

}

使用

假如自定义属性只能用于设值，那也太没用了点。至少，浏览器得能获取到它们的属性值。

使用 var() 方法就能实现：

.button {

  background-color: var(--theme-color);

}

下面这段代码中，我们将 .button 的 background-color 属性值赋值为 --theme-color 的值。这例子看起来自定义属性也没什么了不起的嘛，但这是一个硬编码的情况。你有没有意识到，--theme-color 的属性值是可以用在任意选择器和属性上的呢？这可就厉害了。

.button {

  background-color: var(--theme-color);

}

 

.title {

  color: var(--theme-color);

}

 

.image-grid > .image {

  border-color: var(--theme-color);

}

缺省值

如果开发者并没有定义过 --theme-color 这个变量呢？var() 可以接收第二个参数作为缺省值：

.button {

  background-color: var(--theme-color, gray);

}

注意：如果你想把另一个自定义属性作为缺省值，语法应该是 background-color: var(--theme-color, var(--fallback-color))

传参数时总是传入一个缺省值是一个好习惯，特别是在构建 web components 的时候。为了让你的页面在不支持自定义属性的浏览器上正常显示，别忘了加上兼容代码：

.button {

  background-color: gray;

  background-color: var(--theme-color, gray);

}

CSS现代伪类

这些最新的伪类特性，我们也需要知道。

使用 :is() 减少重复

你可以使用 :is() 伪类来删除选择器列表中的重复项。

/* BEFORE */

.embed .save-button:hover,

.attachment .save-button:hover {

  opacity: 1;

}



/* AFTER */

:is(.embed, .attachment) .save-button:hover {

  opacity: 1;

}

此功能主要在未处理的标准CSS代码中有用。如果使用Sass或类似的CSS预处理程序，则可能更喜欢嵌套。

注意：浏览器还支持非标准的 :-webkit-any() 和 :-moz-any() 伪类，它们与 :is() 相似，但限制更多。WebKit在2015年弃用了 :-webkit-any() ，Mozilla已将Firefox的用户代理样式表更新为使用 :is() 而不是 :-moz-any()。

使用 :where() 来保持低特殊性

:where() 伪类与 :is() 具有相同的语法和功能。它们之间的唯一区别是 :where() 不会增加整体选择器的特殊性（即某条CSS规则特殊性越高，它的样式越优先被采用）。

:where() 伪类及其任何参数都不对选择器的特殊性有所帮助，它的特殊性始终为零

此功能对于应易于覆盖的样式很有用。例如，基本样式表 sanitize.css 包含以下样式规则，如果缺少 <svg fill> 属性，该规则将设置默认的填充颜色：

svg:not([fill]) {

  fill: currentColor;

}

由于其较高的特殊性（B = 1，C = 1），网站无法使用单个类选择器（B = 1）覆盖此声明，并且被迫添加 !important 或人为地提高选择器的特殊性（例如 .share- icon.share-icon）。

.share-icon {

  fill: blue; /* 由于特殊性较低，因此不适用 */

}

CSS库和基础样式表可以通过用 :where() 包装它们的属性选择器来避免这个问题，以保持整个选择器的低特殊性(C=1)。

/* sanitize.css */

svg:where(:not([fill])) {

  fill: currentColor;

}



/* author stylesheet */

.share-icon {

  fill: blue; /* 由于特殊性较高，适用 */

}

其它新伪类特性有情趣同学可以按照导图查阅一下相关文档资料。

完整演示

JS in CSS

前面提到过，使用CSS自定义属性的时候，可以通过JavaScript来操作自定义属性的值。其实还可以更强大一点，如果你对CSS Houdini熟悉的话，可以借助其特性，直接在CSS的代码中来操作CSS自定义属性

:root {

  --property: document.write('hello world!');

}

window.onload = () => {

  const doc = window.getComputedStyle(document.documentElement);

  const cssProp = doc.getPropertyValue('--property');

  new Function((cssProp))();

}

完整演示

Web layout

对于Web布局而言，前端就一直在探讨这方面的最优方式。早期的table布局，接着的float和position相关的布局，多列布局，Flexbox布局和Grid布局等。Flexbox和Grid的出现，Web布局的灵活性越来越高。

如图不依赖媒体查询实现自动计算

CSS Grid中提供了很多强大的特性，比如：

• fr单位，可以很好的帮助我们来计算容器可用空间


• repeat()函数，允许我们给网格多个列指定相同的值。它也接受两个值：重复的次娄和重复的值


• minmax()函数，能够让我们用最简单的CSS控制网格轨道的大小，其包括一个最小值和一个最大值


• auto-fill和auto-fit，配合repeat()函数使用，可以用来替代重复次数，可以根据每列的宽度灵活的改变网格的列数


• max-content和min-content，可以根据单元格的内容来确定列的宽度


• grid-suto-flow，可以更好的让CSS Grid布局时能自动排列

结合这些功能点，布局会变得更轻松。比如我们要实现一个响应式的布局，很多时候都会依赖于媒体查询（@media）来处理，事实上，有了CSS Grid Layout之后，这一切变得更为简单，不需要依赖任何媒体查询就可以很好的实现响应式的布局。特别是当今这个时代，要面对的终端设备只会增加不会减少，那么希望布局更容易的适配这些终端的布局，那么CSS Grid Layout将会起到很大的作用。

完整示例

Grid和flex都是面向未来的最佳布局方案。我们不应该探讨谁优谁劣，而是应该取长补短结合使用。

混合模式和滤镜

能用CSS实现的就不用麻烦JavaScript — Part2一文提到混合模式。CSS混合模式和滤镜主要是用来处理图片的。熟悉PS之类软件的同学很容易理解里面的属性。

完整代码演示

CSS计数器

CSS计数器其实涉及到三个属性：counter-increment、counter-reset和counter()。一般情况都是配合CSS的伪元素::before和::after的content一起使用。可以用来计数

完整演示

SVG图标

对于SVG而言，它是一套独立而又成熟的体系，也有自己的相关规范（Scalable Vecgtor Graphics 2），即 SVG2。虽然该规范已经存在很久了，但很多有关于SVG相关的特性在不同的浏览器中得到的支持度也是有所不一致的。特别是SVG中的渐变和滤镜相关的特性。不过，随着技术的革新，在Web的应用当中SVG的使用越来越多，特别是SVG 图标相关的方面的运用。

• 
  

  最早通过<img>标签来引用图标（每个图标一个文件）

  
  


• 
  

  为了节省请求，提出了Sprites的概念，即将多个图标合并在一起，使用一个图片文件，借助background相关的属性来实现图标

  
  


• 
  

  图片毕竟是位图，面对多种设备终端，或者说更易于控制图标颜色和大小，开始在使用Icon Font来制作Web图标

  
  


• 
  

  当然，字体图标是解决了不少问题，但每次针对不同的图标的使用，需要自定义字体，也要加载相应的字体文件，相应的也带了一定的问题，比如说跨域问题，字体加载问题

  
  


• 
  

  随着SVG的支持力度越来越强，大家开始在思考SVG，使用SVG来制作图标。该技术能解决我们前面碰到的大部分问题，特别是在而对众多终端设备的时候，它的优势越发明显

  
  


• 
  

  SVG和img有点类似，我们也可以借助<symbol>标签和<use>标签，将所有的SVG图标拼接在一起，有点类似于Sprites的技术，只不过在此称为SVG Sprites

  
  

<!-- HTML -->

<svg width="0" height="0" display="none" xmlns="http://www.w3.org/2000/svg">

    <symbol id="half-circle" viewBox="0 0 106 57">...</symbol>

    <!-- .... -->

    <symbol id="icon-burger" viewBox="0 0 24 24">...</symbol>

</svg>

SVG Sprites和img Sprites有所不同，SVG Sprites就是一些代码（类似于HTML一样），估计没有接触过的同学会问，SVG Sprites对应的代码怎么来获取呢？其实很简单，可以借助一些设计软件来完成，比如Sketch。当然也可以使用一些构建工具，比如说svg-sprite。有了这个之后，在该使用的地方，使用<use>标签，指定<symbol>中相应的id值即可，比如：

<svg class="icon-nav-articles" width="26px" height="26px">

    <use xlink:href="#icon-nav-articles"></use>

</svg>

使用SVG的图标还有一优势，我们可以在CSS中直接通过代码来控制图标的颜色：

.site-header .main-nav .main-sections>li>a>svg {

    // ...

    fill: none;

    stroke-width: 2;

    stroke: #c2c2c2;

}

.site-header .main-nav:hover>ul>li:nth-child(1) svg {

    stroke: #ff8a00;

}

完整演示

写在最后

以上列举都是CSS一些优秀的特性。还有很多，有时间再收集更多分享给大家。这些新特性在不同的浏览器中差异性是有所不同的。但这并不是阻碍我们去学习和探索的原因所在。我们应该及时去了解并运用到，才可以做到对项目精益求精。

前言

每次开发新页面的时候，都免不了要去设计一个新的 URL，也就是我们的路由。其实路由在设计的时候不仅仅是一个由几个简单词汇和斜杠分隔符组成的链接，偶尔也可以去考虑有没有更“优雅”的设计方式和技巧。而在这背后，路由和组件之间的协作关系是怎样的呢？于是我以 React 中的 Router 使用方法为例，整理了一些知识点小记和大家分享～

React-Router

基本用法

通常我们使用 React-Router 来实现 React 单页应用的路由控制，它通过管理 URL，实现组件的切换，进而呈现页面的切换效果。

其最基本用法如下：

import { Router, Route } from 'react-router';

render((

  <Router>

    <Route path="/" component={App}/>

  </Router>

), document.getElementById('app'));

亦或是嵌套路由：

在 React-Router V4 版本之前可以直接嵌套，方法如下：

<Router>

  <Route path="/" render={() => <div>外层</div>}>

      <Route path="/in" render={() => <div>内层</div>} />

  </Route>

</Router>

上面代码中，理论上，用户访问 /in 时，会先加载 <div>外层</div>，然后在它的内部再加载 <div>内层</div>。

然而实际运行上述代码却发现它只渲染出了根目录中的内容。后续对比 React-Router 版本发现，是因为在 V4 版本中变更了其渲染逻辑，原因据说是为了践行 React 的组件化理念，不能让 Route 标签看起来只是一个标签（奇怪的知识又增加了）。

现在较新的版本中，可以使用 Render 方法实现嵌套。

<Route

  path="/"

  render={() => (

    <div>

      <Route

        path="/"

        render={() => <div>外层</div>}

      />

      <Route

        path="/in"

        render={() => <div>内层</div>}

      />

      <Route

        path="/others"

        render={() => <div>其他</div>}

      />

    </div>

  )}

/>

此时访问 /in 时，会将“外层”和“内层”一起展示出来，类似地，访问 /others 时，会将“外层”和“其他”一起展示出来。

路由传参小 Tips

在实际开发中，往往在页面切换时需要传递一些参数，有些参数适合放在 Redux 中作为全局数据，或者通过上下文传递，比如业务的一些共享数据，但有些参数则适合放在 URL 中传递，比如页面类型或详情页中单据的唯一标识 id。在处理 URL 时，除了问号带参数的方式，React-Router 能帮我们做什么呢？在这其中，Route 组件的 path 属性便可用于指定路由的匹配规则。

场景 1

描述：就想让普普通通的 URL 带个平平无奇的参数

那么，接下来我们可以这样干：

Case A：路由参数

path="/book/:id"

我们可以用冒号 + 参数名字的方式，将想要传递的参数添加到 URL 上，此时，当参数名字（本 Case 中是 id）对应的值改变时，将被认为是不同 URL。

Case B：查询参数

path="/book"

如果想要在页面跳转的时候问号带参数，那么 path 可以直接设计成既定的样子，参数由跳转方拼接。
在跳转时，有两种形式带上参数。其一是在 Link 组件的 to 参数中通过配置字符串并用问号带参数，其二是 to 参数可以接受一个对象，其中可以在 search 字段中配置想要传递的参数。

<Link to="/book?id=111" />

// 或者

<Link to={{

  pathname: '/book',

  search: '?id=111',

}}/>

此时，假设当前页面 URL中的 id 由111 修改为 222 时，该路由对应的组件（在上述例子中就是 React-Route 配置时 path="/book" 对应的页面/组件 ）会更新，即执行 componentDidUpdate 方法，但不会被卸载，也就是说，不会执行 componentDidMount 方法。

Case C：查询参数隐身式带法

path="/book"

path 依旧设计成既定的样子，而在跳转时，可以通过 Link 中的 state 将参数传递给对应路由的页面。

<Link to={{

  pathname: '/book',

  state: { id: 111 }

}}/>

但一定要注意的是，尽管这种方式下查询参数不会明文传递了，但此时页面刷新会导致参数丢失（存储在 state 中的通病），So，灰常不推荐~~（其实不想明文可以进行加密处理，但一般情况下敏感信息是不建议放在 URL 中传递的～）

场景 2

描述：编辑/详情页，想要共用一个页面，URL 由不同的参数区分，此时我们希望，参数必须为 edit、detail、add 中的 1 个，不然需要跳转到 404 Not Found 页面。

path='/book/:pageType(edit|detail|add)'

如果不加括号中的内容 (edit|detail|add)，当传入错误的参数（比如用户误操作、随便拼接 URL 的情况），则页面不会被 404 拦截，而是继续走下去开始渲染页面或调用接口，但此时很有可能导致接口传参错误或页面出错。

场景 3

描述：新增页和编辑页辣么像，我的新增页也想和编辑/详情共用一个页面。但是新增页不需要 id，编辑/详情页需要 id，使用同一个页面怎么办？

path='/book/:pageType(edit|detail|add)/:id?'

别急，可以用 ? 来解决，它意味着 id 不是一个必要参数，可传可不传。

场景 4

描述：我的 id 只能是数字，不想要字符串怎么办？

path='/book/:id(\\\d+)'

此时 id 不是数字时，会跳转 404，被认为 URL 对应的页面找不到啦。

底层依赖

有了这么多场景，那 Router 是怎样实现的呢？其实它底层是依赖了 path-to-regexp 方法。

var pathToRegexp = require('path-to-regexp')

// pathToRegexp(path, keys, options)

// 示例

var keys = []

var re = pathToRegexp('/foo/:bar', keys)

// re = /^\/foo\/([^\/]+?)\/?$/i

// keys = [{ name: 'bar', prefix: '/', delimiter: '/', optional: false, repeat: false, pattern: '[^\\/]+?' }]

delimiter：重复参数的定界符，默认是 '/'，可配置

一些其他常用的路由正则通配符：

• 
  

  ? 可选参数

  
  


• 
  

  * 匹配 0 次或多次

  
  


• 
  

  + 匹配 1 次或多次

  
  

如果忘记写参数名字，而只写了路由规则，比如下述代码中 /:foo 后面的参数：

var re = pathToRegexp('/:foo/(.*)', keys)

// 匹配除“\n”之外的任何字符

// keys = [{ name: 'foo', ... }, { name: 0, ...}]

re.exec('/test/route')

//=> ['/test/route', 'test', 'route']

它也会被正确解析，只不过在方法处理的内部，未命名的参数名会被替换成数组下标。

取路由参数

path 带的参数，可以通过 this.props.match 获取

例如：

// url 为 /book/:pageType(edit|detail|add)

const { match } = this.props;

const { pageType } = match.params;

由于有 #，# 之后的所有内容都会被认为是 hash 的一部分，window.location.search 是取不到问号带的参数的。

比如：aaa.bbb.com/book-center…

那么在 React-Router 中，问号带的参数，可以通过 this.props.location （官方墙推 👍）获取。个人理解是因为 React-Router 帮我们做了处理，通过路由和 hash 值（window.location.hash）做了解析的封装。

例如：

// url 为 /book?pageType=edit

const { location } = this.props;

const searchParams = location.search; // ?pageType=edit

实际打印 props 参数发现，this.props.history.location 也可以取到问号参数，但不建议使用，因为 React 的生命周期（componentWillReceiveProps、componentDidUpdate）可能使它变得不可靠。（原因可参考：blog.csdn.net/zrq1210/art…

在早期的 React-Router 2.0 版本是可以用 location.query.pageType 来获取参数的，但是 V4.0 去掉了（有人认为查询参数不是 URL 的一部分，有人认为现在有很多第三方库，交给开发者自己去解析会更好，有个对此讨论的 Issue，有兴趣的可以自行获取 😊 github.com/ReactTraini…

针对上一节中场景 1 的 Case C，查询参数隐身式带法时（从 state 里带过去的），在 this.props.location.state 里可以取到（不推荐不推荐不推荐，刷新会没～）

Switch

<div>

  <Route

    path="/router/:type"

    render={() => <div>影像</div>}

  />

  <Route

    path="/router/book"

    render={() => <div>图书</div>}

  />

</div>

如果 <Route /> 是平铺的（用 div 包裹是因为 Router 下只能有一个元素），输入 /router/book 则影像和图书都会被渲染出来，如果想要只精确渲染其中一个，则需要 Switch

<Switch>

  <Route

    path="/router/:type"

    render={() => <div>影像</div>}

  />

  <Route

    path="/router/book"

    render={() => <div>图书</div>}

  />

</Switch>

Switch 的意思便是精准的根据不同的 path 渲染不同 Route 下的组件。
但是，加了 Switch 之后路由匹配规则是从上到下执行，一旦发现匹配，就不再匹配其余的规则了。因此在使用的时候一定要“百般小心”。

上面代码中，用户访问 /router/book 时，不会触发第二个路由规则（不会 展示“图书”），因为它会匹配 /router/:type 这个规则。因此，带参数的路径一般要写在路由规则的底部。

路由的基本原理

路由做的事情：管控 URL 变化，改变浏览器中的地址。

Router 做的事情：URL 改变时，触发渲染，渲染对应的组件。

URL 有两种，一种不带 #，一种带 #，分别对应 Browse 模式和 Hash 模式。

一般单页应用中，改变 URL，但是不重新加载页面的方式有两类：

Case 1（会触发路由监听事件）：点击 前进、后退，或者调用的 history.back( )、history.forward( )

Case 2（不会触发路由监听事件）：组件中调用 history.push( ) 和 history.replace( )

于是参考 「源码解析 」这一次彻底弄懂 React-Router 路由原理 一文，针对上述两种 Case，以及这两种 Case 分别对应的两种模式，作出如下总结。

图片来源：「源码解析 」这一次彻底弄懂 React-Router 路由原理

Browser 模式

Case 1:

URL 改变，触发路由的监听事件 popstate，then，监听事件的回调函数 handlePopState 在回调中触发 history 的 setState 方法，产生新的 location 对象。state 改变，通知 Router 组件更新 location 并通过 context 上下文传递，匹配出符合的 Route 组件，最后由 <Route /> 组件取出对应内容，传递给渲染页面，渲染更新。

/* 简化版的 handlePopState （监听事件的回调） */

const handlePopState = (event)=>{

     /* 获取当前location对象 */

    const location = getDOMLocation(event.state)

    const action = 'POP'

     /* transitionManager 处理路由转换 */

    transitionManager.confirmTransitionTo(location, action, getUserConfirmation, (ok) => {

        if (ok) {

          setState({ action, location })

        } else {

          revertPop(location)

        }

    })

}

Case 2:
以 history.push 为例，首先依据你要跳转的 path 创建一个新的 location 对象，然后通过 window.history.pushState （H5 提供的 API ）方法改变浏览器当前路由（即当前的 url），最后通过 setState 方法通知 Router，触发组件更新。

const push = (path, state) => {

   const action = 'PUSH'

   /* 创建location对象 */

   const location = createLocation(path, state, createKey(), history.location)

   /* 确定是否能进行路由转换 */

   transitionManager.confirmTransitionTo(location, action, getUserConfirmation, (ok) => {

   ... // 此处省略部分代码

   const href = createHref(location)

   const { key, state } = location

   if (canUseHistory) {

     /* 改变 url */

     globalHistory.pushState({ key, state }, null, href)

     if (forceRefresh) {

       window.location.href = href

     } else {

       /* 改变 react-router location对象, 创建更新环境 */

       setState({ action, location })

     }

   } else {

     window.location.href = href

   }

 })

}

Hash 模式

Case 1:

增加监听，当 URL 的 Hash 发生变化时，触发 hashChange 注册的回调，回调中去进行相类似的操作，进而展示不同的内容。

window.addEventListener('hashchange',function(e){

  /* 监听改变 */

})

Case 2:
history.push 底层调用 window.location.hash 来改变路由。history.replace 底层是调用 window.location.replace 改变路由。然后 setState 通知改变。

从一些参考资料中显示，出于兼容性的考虑（H5 的方法 IE10 以下不兼容），路由系统内部将 Hash 模式作为创建 History 对象的默认方法。（此处若有疑议，欢迎指正～）

Dva/Router

在实际项目中发现，Link，Route 都是从 dva/router 中引进来的，那么，Dva 在这之中做了什么呢？

答案：貌似没有做特殊处理，Dva 在 React-Router 上做了上层封装，会默认输出 React-Router 接口。

我们对 Router 做过的一些处理

Case 1:

项目代码的 src 目录下，不管有多少文件夹，路由一般会放在同一个 router.js 文件中维护，但这样会导致页面太多时，文件内容会越来越长，不便于查找和修改。

因此我们可以做一些小改造，在 src 下的每个文件夹中，创建自己的路由配置文件，以便管理各自的路由。但这种情况下 React-Router 是不能识别的，于是我们写了一个 Plugin 放在 Webpack 中，目的是将各个文件夹下的路由汇总，并生成 router-config.js 文件。之后，将该文件中的内容解析成组件需要的相关内容。插件实现方式可了解本团队另一篇文章： 手把手带你入门 Webpack Plugin。

Case 2:

路由的 Hash 模式虽然兼容性好，但是也存在一些问题：

1. 对于 SEO、前端埋点不太友好，不容易区分路径


2. 原有页面有锚点时，使用 Hash 模式会出现冲突

因此公司内部做了一次 Hash 路由转 Browser 路由的改造。

如原有链接为：aaa.bbb.com/book-center…

改造方案为：

通过新增以下配置代码去掉 #

import createHistory from 'history/createBrowserHistroy';

const app = dva({

  history: createHistory({

    basename: '/book-center',

  }),

  onError,

});

同时，为了避免用户访问旧页面出现 404 的情况，前端需要在 Redirect 中配置重定向以及在 Nginx 中配置旧的 Hash 页面转发。

Case 3:

在实际项目中，其实我们也会去考虑用户未授权时路由跳转、页面 404 时路由跳转等不同情况，以下 Case 和代码仅供读者参考～

<Switch>

  {

    getRoutes(match.path, routerData).map(item =>

    	(

      	// 用户未授权处理，AuthorizedRoute 为项目中自己实现的处理组件

      	<AuthorizedRoute

        	{...item}

        	redirectPath="/exception/403"

      	/>

    	)

    )

  }

  // 默认跳转页面

  <Redirect from="/" exact to="/list" />

  // 页面 404 处理

  <Route render={props => <NotFound {...props} />} />

</Switch>

参考链接

「源码解析 」这一次彻底弄懂react-router路由原理

react-router v4 路由规则解析

二级动态路由的解决方案

六、附件形式下载

在服务端下载的场景中，附件形式下载是一种比较常见的场景。在该场景下，我们通过设置 Content-Disposition 响应头来指示响应的内容以何种形式展示，是以内联（inline）的形式，还是以附件（attachment）的形式下载并保存到本地。

Content-Disposition: inline

Content-Disposition: attachment

Content-Disposition: attachment; filename="mouth.png"

而在 HTTP 表单的场景下， Content-Disposition 也可以作为 multipart body 中的消息头：

Content-Disposition: form-data

Content-Disposition: form-data; name="fieldName"

Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"

第 1 个参数总是固定不变的 form-data；附加的参数不区分大小写，并且拥有参数值，参数名与参数值用等号（=）连接，参数值用双引号括起来。参数之间用分号（;）分隔。

了解完 Content-Disposition 的作用之后，我们来看一下如何实现以附件形式下载的功能。Koa 是一个简单易用的 Web 框架，它的特点是优雅、简洁、轻量、自由度高。所以我们选择它来搭建文件服务，并使用 @koa/router 中间件来处理路由：

// attachment/file-server.js

const fs = require("fs");

const path = require("path");

const Koa = require("koa");

const Router = require("@koa/router");



const app = new Koa();

const router = new Router();

const PORT = 3000;

const STATIC_PATH = path.join(__dirname, "./static/");



// http://localhost:3000/file?filename=mouth.png

router.get("/file", async (ctx, next) => {

  const { filename } = ctx.query;

  const filePath = STATIC_PATH + filename;

  const fStats = fs.statSync(filePath);

  ctx.set({

    "Content-Type": "application/octet-stream",

    "Content-Disposition": `attachment; filename=${filename}`,

    "Content-Length": fStats.size,

  });

  ctx.body = fs.createReadStream(filePath);

});



// 注册中间件

app.use(async (ctx, next) => {

  try {

    await next();

  } catch (error) {

    // ENOENT（无此文件或目录）：通常是由文件操作引起的，这表明在给定的路径上无法找到任何文件或目录

    ctx.status = error.code === "ENOENT" ? 404 : 500;

    ctx.body = error.code === "ENOENT" ? "文件不存在" : "服务器开小差";

  }

});

app.use(router.routes()).use(router.allowedMethods());



app.listen(PORT, () => {

  console.log(`应用已经启动：http://localhost:${PORT}/`);

});

以上的代码被保存在 attachment 目录下的 file-server.js 文件中，该目录下还有一个 static 子目录用于存放静态资源。目前 static 目录下包含以下 3 个 png 文件。

├── file-server.js

└── static

    ├── body.png

    ├── eyes.png

    └── mouth.png

当你运行 node file-server.js 命令成功启动文件服务器之后，就可以通过正确的 URL 地址来下载 static 目录下的文件。比如在浏览器中打开 http://localhost:3000/file?filename=mouth.png 这个地址，你就会开始下载 mouth.png 文件。而如果指定的文件不存在的话，就会返回文件不存在。

Koa 内核很简洁，扩展功能都是通过中间件来实现。比如常用的路由、CORS、静态资源处理等功能都是通过中间件实现。因此要想掌握 Koa 这个框架，核心是掌握它的中间件机制。若你想深入了解 Koa 的话，可以阅读 如何更好地理解中间件和洋葱模型 这篇文章。

在编写 HTML 网页时，对于一些简单图片，通常会选择将图片内容直接内嵌在网页中，从而减少不必要的网络请求，但是图片数据是二进制数据，该怎么嵌入呢？绝大多数现代浏览器都支持一种名为 Data URLs 的特性，允许使用 Base64 对图片或其他文件的二进制数据进行编码，将其作为文本字符串嵌入网页中。所以文件也可以通过 Base64 的格式进行传输，接下来我们将介绍如何下载 Base64 格式的图片。

附件形式下载示例：attachment

github.com/semlinker/f…

七、base64 格式下载

Base64 是一种基于 64 个可打印字符来表示二进制数据的表示方法。由于 2⁶ = 64 ，所以每 6 个比特为一个单元，对应某个可打印字符。3 个字节有 24 个比特，对应于 4 个 base64 单元，即 3 个字节可由 4 个可打印字符来表示。相应的转换过程如下图所示：

Base64 常用在处理文本数据的场合，表示、传输、存储一些二进制数据，包括 MIME 的电子邮件及 XML 的一些复杂数据。 在 MIME 格式的电子邮件中，base64 可以用来将二进制的字节序列数据编码成 ASCII 字符序列构成的文本。使用时，在传输编码方式中指定 base64。使用的字符包括大小写拉丁字母各 26 个、数字 10 个、加号 + 和斜杠 /，共 64 个字符，等号 = 用来作为后缀用途。

Base64 的相关内容就先介绍到这，如果你想进一步了解 Base64 的话，可以阅读 一文读懂base64编码 这篇文章。下面我们来看一下具体实现代码：

7.1 前端代码

html

在以下 HTML 代码中，我们通过 select 元素来让用户选择要下载的图片。当用户切换不同的图片时，img#imgPreview 元素中显示的图片会随之发生变化。

<h3>base64 下载示例</h3>

<img id="imgPreview" src="./static/body.png" />

<select id="picSelect">

   <option value="body">body.png</option>

   <option value="eyes">eyes.png</option>

   <option value="mouth">mouth.png</option>

</select>

<button onclick="download()">下载</button>

js

const picSelectEle = document.querySelector("#picSelect");

const imgPreviewEle = document.querySelector("#imgPreview");



picSelectEle.addEventListener("change", (event) => {

  imgPreviewEle.src = "./static/" + picSelectEle.value + ".png";

});



const request = axios.create({

  baseURL: "http://localhost:3000",

  timeout: 60000,

});



async function download() {

  const response = await request.get("/file", {

    params: {

      filename: picSelectEle.value + ".png",

    },

  });

  if (response && response.data && response.data.code === 1) {

    const fileData = response.data.data;

    const { name, type, content } = fileData;

    const imgBlob = base64ToBlob(content, type);

    saveAs(imgBlob, name);

  }

}

在用户选择好需要下载的图片并点击下载按钮时，就会调用以上代码中的 download 函数。在该函数内部，我们利用 axios 实例的 get 方法发起 HTTP 请求来获取指定的图片。因为返回的是 base64 格式的图片，所以在调用 FileSaver 提供的 saveAs 方法前，我们需要将 base64 字符串转换成 blob 对象，该转换是通过以下的 base64ToBlob 函数来完成，该函数的具体实现如下所示：

function base64ToBlob(base64, mimeType) {

  let bytes = window.atob(base64);

  let ab = new ArrayBuffer(bytes.length);

  let ia = new Uint8Array(ab);

  for (let i = 0; i < bytes.length; i++) {

    ia[i] = bytes.charCodeAt(i);

  }

  return new Blob([ab], { type: mimeType });

}

7.2 服务端代码

// base64/file-server.js

const fs = require("fs");

const path = require("path");

const mime = require("mime");

const Koa = require("koa");

const cors = require("@koa/cors");

const Router = require("@koa/router");



const app = new Koa();

const router = new Router();

const PORT = 3000;

const STATIC_PATH = path.join(__dirname, "./static/");



router.get("/file", async (ctx, next) => {

  const { filename } = ctx.query;

  const filePath = STATIC_PATH + filename;

  const fileBuffer = fs.readFileSync(filePath);

  ctx.body = {

    code: 1,

    data: {

      name: filename,

      type: mime.getType(filename),

      content: fileBuffer.toString("base64"),

    },

  };

});



// 注册中间件

app.use(async (ctx, next) => {

  try {

    await next();

  } catch (error) {

    ctx.body = {

      code: 0,

      msg: "服务器开小差",

    };

  }

});

app.use(cors());

app.use(router.routes()).use(router.allowedMethods());



app.listen(PORT, () => {

  console.log(`应用已经启动：http://localhost:${PORT}/`);

});

在以上代码中，对图片进行 Base64 编码的操作是定义在 /file 路由对应的路由处理器中。当该服务器接收到客户端发起的文件下载请求，比如 GET /file?filename=body.png HTTP/1.1 时，就会从 ctx.query 对象上获取 filename 参数。该参数表示文件的名称，在获取到文件的名称之后，我们就可以拼接出文件的绝对路径，然后通过 Node.js 平台提供的 fs.readFileSync 方法读取文件的内容，该方法会返回一个 Buffer 对象。在成功读取文件的内容之后，我们会继续调用 Buffer 对象的 toString 方法对文件内容进行 Base64 编码，最终所下载的图片将以 Base64 格式返回到客户端。

base64 格式下载示例：base64

github.com/semlinker/f…

八、chunked 下载

分块传输编码主要应用于如下场景，即要传输大量的数据，但是在请求在没有被处理完之前响应的长度是无法获得的。例如，当需要用从数据库中查询获得的数据生成一个大的 HTML 表格的时候，或者需要传输大量的图片的时候。

要使用分块传输编码，则需要在响应头配置 Transfer-Encoding 字段，并设置它的值为 chunked 或 gzip, chunked：

Transfer-Encoding: chunked

Transfer-Encoding: gzip, chunked

响应头 Transfer-Encoding 字段的值为 chunked，表示数据以一系列分块的形式进行发送。需要注意的是 Transfer-Encoding 和 Content-Length 这两个字段是互斥的，也就是说响应报文中这两个字段不能同时出现。下面我们来看一下分块传输的编码规则：

• 每个分块包含分块长度和数据块两个部分；
• 分块长度使用 16 进制数字表示，以 \r\n 结尾；
• 数据块紧跟在分块长度后面，也使用 \r\n 结尾，但数据不包含 \r\n；
• 终止块是一个常规的分块，表示块的结束。不同之处在于其长度为 0，即 0\r\n\r\n。

了解完分块传输的编码规则，我们来看如何利用分块传输编码实现文件下载。

8.1 前端代码

html5

<h3>chunked 下载示例</h3>

<button onclick="download()">下载</button>

js

const chunkedUrl = "http://localhost:3000/file?filename=file.txt";



function download() {

  return fetch(chunkedUrl)

    .then(processChunkedResponse)

    .then(onChunkedResponseComplete)

    .catch(onChunkedResponseError);

}



function processChunkedResponse(response) {

  let text = "";

  let reader = response.body.getReader();

  let decoder = new TextDecoder();



  return readChunk();



  function readChunk() {

    return reader.read().then(appendChunks);

  }



  function appendChunks(result) {

    let chunk = decoder.decode(result.value || new Uint8Array(), {

      stream: !result.done,

    });

    console.log("已接收到的数据：", chunk);

    console.log("本次已成功接收", chunk.length, "bytes");

    text += chunk;

    console.log("目前为止共接收", text.length, "bytes\n");

    if (result.done) {

      return text;

    } else {

      return readChunk();

    }

  }

}



function onChunkedResponseComplete(result) {

  let blob = new Blob([result], {

    type: "text/plain;charset=utf-8",

  });

  saveAs(blob, "hello.txt");

}



function onChunkedResponseError(err) {

  console.error(err);

}

当用户点击 下载 按钮时，就会调用以上代码中的 download 函数。在该函数内部，我们会使用 Fetch API 来执行下载操作。因为服务端的数据是以一系列分块的形式进行发送，所以在浏览器端我们是通过流的形式进行接收。即通过 response.body 获取可读的 ReadableStream，然后用 ReadableStream.getReader() 创建一个读取器，最后调用 reader.read 方法来读取已返回的分块数据。

因为 file.txt 文件的内容是普通文本，且 result.value 的值是 Uint8Array 类型的数据，所以在处理返回的分块数据时，我们使用了 TextDecoder 文本解码器。一个解码器只支持一种特定文本编码，例如 utf-8、iso-8859-2、koi8、cp1261，gbk 等等。

如果收到的分块非 终止块，result.done 的值是 false，则会继续调用 readChunk 方法来读取分块数据。而当接收到 终止块 之后，表示分块数据已传输完成。此时，result.done 属性就会返回 true。从而会自动调用 onChunkedResponseComplete 函数，在该函数内部，我们以解码后的文本作为参数来创建 Blob 对象。之后，继续使用 FileSaver 库提供的 saveAs 方法实现文件下载。

这里我们用 Wireshark 网络包分析工具，抓了个数据包。具体如下图所示：

从图中我们可以清楚地看到在 HTTP chunked response 下面包含了 Data chunk（数据块） 和 End of chunked encoding（终止块）。接下来，我们来看一下服务端的代码。

8.2 服务端代码

const fs = require("fs");

const path = require("path");

const Koa = require("koa");

const cors = require("@koa/cors");

const Router = require("@koa/router");



const app = new Koa();

const router = new Router();

const PORT = 3000;



router.get("/file", async (ctx, next) => {

  const { filename } = ctx.query;

  const filePath = path.join(__dirname, filename);

  ctx.set({

    "Content-Type": "text/plain;charset=utf-8",

  });

  ctx.body = fs.createReadStream(filePath);

});



// 注册中间件

app.use(async (ctx, next) => {

  try {

    await next();

  } catch (error) {

    // ENOENT（无此文件或目录）：通常是由文件操作引起的，这表明在给定的路径上无法找到任何文件或目录

    ctx.status = error.code === "ENOENT" ? 404 : 500;

    ctx.body = error.code === "ENOENT" ? "文件不存在" : "服务器开小差";

  }

});

app.use(cors());

app.use(router.routes()).use(router.allowedMethods());



app.listen(PORT, () => {

  console.log(`应用已经启动：http://localhost:${PORT}/`);

});

在 /file 路由处理器中，我们先通过 ctx.query 获得 filename 文件名，接着拼接出该文件的绝对路径，然后通过 Node.js 平台提供的 fs.createReadStream 方法创建可读流。最后把已创建的可读流赋值给 ctx.body 属性，从而向客户端返回图片数据。

现在我们已经知道可以利用分块传输编码（Transfer-Encoding）实现数据的分块传输，那么有没有办法获取指定范围内的文件数据呢？对于这个问题，我们可以利用 HTTP 协议的范围请求。接下来，我们将介绍如何利用 HTTP 范围请求来下载指定范围的数据。

chunked 下载示例：chunked

github.com/semlinker/f…

九、范围下载

HTTP 协议范围请求允许服务器只发送 HTTP 消息的一部分到客户端。范围请求在传送大的媒体文件，或者与文件下载的断点续传功能搭配使用时非常有用。如果在响应中存在 Accept-Ranges 首部（并且它的值不为 “none”），那么表示该服务器支持范围请求。

在一个 Range 首部中，可以一次性请求多个部分，服务器会以 multipart 文件的形式将其返回。如果服务器返回的是范围响应，需要使用 206 Partial Content 状态码。假如所请求的范围不合法，那么服务器会返回 416 Range Not Satisfiable 状态码，表示客户端错误。服务器允许忽略 Range 首部，从而返回整个文件，状态码用 200 。

Range 语法：

Range: <unit>=<range-start>-

Range: <unit>=<range-start>-<range-end>

Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>

Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>

• unit：范围请求所采用的单位，通常是字节（bytes）。
• <range-start>：一个整数，表示在特定单位下，范围的起始值。
• <range-end>：一个整数，表示在特定单位下，范围的结束值。这个值是可选的，如果不存在，表示此范围一直延伸到文档结束。

了解完 Range 语法之后，我们来看一下实际的使用示例：

# 单一范围

$ curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"

# 多重范围

$ curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"

9.1 前端代码

html

<h3>范围下载示例</h3>

<button onclick="download()">下载</button>

js

async function download() {

  try {

    let rangeContent = await getBinaryContent(

      "http://localhost:3000/file.txt",

       0, 100, "text"

    );

    const blob = new Blob([rangeContent], {

      type: "text/plain;charset=utf-8",

    });

    saveAs(blob, "hello.txt");

  } catch (error) {

    console.error(error);

  }

}



function getBinaryContent(url, start, end, responseType = "arraybuffer") {

  return new Promise((resolve, reject) => {

    try {

      let xhr = new XMLHttpRequest();

      xhr.open("GET", url, true);

      xhr.setRequestHeader("range", `bytes=${start}-${end}`);

      xhr.responseType = responseType;

      xhr.onload = function () {

        resolve(xhr.response);

      };

        xhr.send();

    } catch (err) {

        reject(new Error(err));

    }

  });

}

当用户点击 下载 按钮时，就会调用 download 函数。在该函数内部会通过调用 getBinaryContent 函数来发起范围请求。对应的 HTTP 请求报文如下所示：

GET /file.txt HTTP/1.1

Host: localhost:3000

Connection: keep-alive

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36

Accept: */*

Accept-Encoding: identity

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,id;q=0.7

Range: bytes=0-100

而当服务器接收到该范围请求之后，会返回对应的 HTTP 响应报文：

HTTP/1.1 206 Partial Content

Vary: Origin

Access-Control-Allow-Origin: null

Accept-Ranges: bytes

Last-Modified: Fri, 09 Jul 2021 00:17:00 GMT

Cache-Control: max-age=0

Content-Type: text/plain; charset=utf-8

Date: Sat, 10 Jul 2021 02:19:39 GMT

Connection: keep-alive

Content-Range: bytes 0-100/2590

Content-Length: 101

从以上的 HTTP 响应报文中，我们见到了前面介绍的 206 状态码和 Accept-Ranges 首部。此外，通过 Content-Range 首部，我们就知道了文件的总大小。在成功获取到范围请求的响应体之后，我们就可以使用返回的内容作为参数，调用 Blob 构造函数创建对应的 Blob 对象，进而使用 FileSaver 库提供的 saveAs 方法来下载文件了。

9.2 服务端代码

const Koa = require("koa");

const cors = require("@koa/cors");

const serve = require("koa-static");

const range = require("koa-range");



const PORT = 3000;

const app = new Koa();



// 注册中间件

app.use(cors());

app.use(range);

app.use(serve("."));



app.listen(PORT, () => {

  console.log(`应用已经启动：http://localhost:${PORT}/`);

});

服务端的代码相对比较简单，范围请求是通过 koa-range 中间件来实现的。由于篇幅有限，阿宝哥就不展开介绍了。感兴趣的小伙伴，可以自行阅读该中间件的源码。其实范围请求还可以应用在大文件下载的场景，如果文件服务器支持范围请求的话，客户端在下载大文件的时候，就可以考虑使用大文件分块下载的方案。

范围下载示例：range

github.com/semlinker/f…

十、大文件分块下载

相信有些小伙伴已经了解大文件上传的解决方案，在上传大文件时，为了提高上传的效率，我们一般会使用 Blob.slice 方法对大文件按照指定的大小进行切割，然后在开启多线程进行分块上传，等所有分块都成功上传后，再通知服务端进行分块合并。

那么对大文件下载来说，我们能否采用类似的思想呢？其实在服务端支持 Range 请求首部的条件下，我们也是可以实现大文件分块下载的功能，具体处理方案如下图所示：

因为在 JavaScript 中如何实现大文件并发下载？ 这篇文章中，阿宝哥已经详细介绍了大文件并发下载的方案，所以这里就不展开介绍了。我们只回顾一下大文件并发下载的完整流程：

其实在大文件分块下载的场景中，我们使用了 async-pool 这个库来实现并发控制。该库提供了 ES7 和 ES6 两种不同版本的实现，代码很简洁优雅。如果你想了解 async-pool 是如何实现并发控制的，可以阅读 JavaScript 中如何实现并发控制？ 这篇文章。

大文件分块下载示例：big-file

github.com/semlinker/f…

十一、总结

本文阿宝哥详细介绍了文件下载的 9 种场景，希望阅读完本文后，你对 9 种场景背后使用的技术有一定的了解。其实在传输文件的过程中，为了提高传输效率，我们可以使用 gzip、deflate 或 br 等压缩算法对文件进行压缩。由于篇幅有限，阿宝哥就不展开介绍了，如果你感兴趣的话，可以阅读 HTTP 传输大文件的几种方案 这篇文章。

既然掘友有要求，连标题也帮阿宝哥想好了，那我们就来整一篇文章，总结一下文件下载的场景。

一般在我们工作中，主要会涉及到 9 种文件下载的场景，每一种场景背后都使用不同的技术，其中也有很多细节需要我们额外注意。今天阿宝哥就来带大家总结一下这 9 种场景，让大家能够轻松地应对各种下载场景。阅读本文后，你将会了解以下的内容：

在浏览器端处理文件的时候，我们经常会用到 Blob 。比如图片本地预览、图片压缩、大文件分块上传及文件下载。在浏览器端文件下载的场景中，比如我们今天要讲到的 a 标签下载、showSaveFilePicker API 下载、Zip 下载 等场景中，都会使用到 Blob ，所以我们有必要在学习具体应用前，先掌握它的相关知识，这样可以帮助我们更好地了解示例代码。

一、基础知识

1.1 了解 Blob

Blob（Binary Large Object）表示二进制类型的大对象。在数据库管理系统中，将二进制数据存储为一个单一个体的集合。Blob 通常是影像、声音或多媒体文件。在 JavaScript 中 Blob 类型的对象表示一个不可变、原始数据的类文件对象。 它的数据可以按文本或二进制的格式进行读取，也可以转换成 ReadableStream 用于数据操作。

Blob 对象由一个可选的字符串 type（通常是 MIME 类型）和 blobParts 组成：

在 JavaScript 中你可以通过 Blob 的构造函数来创建 Blob 对象，Blob 构造函数的语法如下：

const aBlob = new Blob(blobParts, options);

相关的参数说明如下：

• blobParts：它是一个由 ArrayBuffer，ArrayBufferView，Blob，DOMString 等对象构成的数组。DOMStrings 会被编码为 UTF-8。


• options：一个可选的对象，包含以下两个属性：
  
  
  
  • type —— 默认值为 ""，它代表了将会被放入到 blob 中的数组内容的 MIME 类型。
  
  
  • endings —— 默认值为 "transparent"，用于指定包含行结束符 \n 的字符串如何被写入。 它是以下两个值中的一个： "native"，代表行结束符会被更改为适合宿主操作系统文件系统的换行符，或者 "transparent"，代表会保持 blob 中保存的结束符不变。
  
  
  
  

1.2 了解 Blob URL

Blob URL/Object URL 是一种伪协议，允许 Blob 和 File 对象用作图像、下载二进制数据链接等的 URL 源。在浏览器中，我们使用 URL.createObjectURL 方法来创建 Blob URL，该方法接收一个 Blob 对象，并为其创建一个唯一的 URL，其形式为 blob:<origin>/<uuid>，对应的示例如下：

blob:http://localhost:3000/53acc2b6-f47b-450f-a390-bf0665e04e59

浏览器内部为每个通过 URL.createObjectURL 生成的 URL 存储了一个 URL → Blob 映射。因此，此类 URL 较短，但可以访问 Blob。生成的 URL 仅在当前文档打开的状态下才有效。它允许引用 <img>、<a> 中的 Blob，但如果你访问的 Blob URL 不再存在，则会从浏览器中收到 404 错误。

上述的 Blob URL 看似很不错，但实际上它也有副作用。 虽然存储了 URL → Blob 的映射，但 Blob 本身仍驻留在内存中，浏览器无法释放它。映射在文档卸载时自动清除，因此 Blob 对象随后被释放。但是，如果应用程序寿命很长，那么 Blob 在短时间内将无法被浏览器释放。因此，如果你创建一个 Blob URL，即使不再需要该 Blob，它也会存在内存中。

针对这个问题，你可以调用 URL.revokeObjectURL(url) 方法，从内部映射中删除引用，从而允许删除 Blob（如果没有其他引用），并释放内存。

现在你已经了解了 Blob 和 Blob URL，如果你还意犹未尽，想深入理解 Blob 的话，可以阅读 你不知道的 Blob 这篇文章。下面我们开始介绍客户端文件下载的场景。

随着 Web 技术的不断发展，浏览器的功能也越来越强大。这些年出现了很多在线 Web 设计工具，比如在线 PS、在线海报设计器或在线自定义表单设计器等。这些 Web 设计器允许用户在完成设计之后，把生成的文件保存到本地，其中有一部分设计器就是利用浏览器提供的 Web API 来实现客户端文件下载。下面阿宝哥先来介绍客户端下载中，最常见的 a 标签下载 方案。

二、a 标签下载

html

<h3>a 标签下载示例</h3>

<div>

  <img src="../images/body.png" />

  <img src="../images/eyes.png" />

  <img src="../images/mouth.png" />

</div>

<img id="mergedPic" src="http://via.placeholder.com/256" />

<button onclick="merge()">图片合成</button>

<button onclick="download()">图片下载</button>

在以上代码中，我们通过 img 标签引用了以下 3 张素材：

当用户点击 图片合成 按钮时，会将合成的图片显示在 img#mergedPic 容器中。在图片成功合成之后，用户可以通过点击 图片下载 按钮把已合成的图片下载到本地。对应的操作流程如下图所示：

由上图可知，整体的操作流程相对简单。接下来，我们来看一下 图片合成 和 图片下载 的实现逻辑。

js

图片合成的功能，阿宝哥是直接使用 Github 上 merge-images 这个第三方库来实现。利用该库提供的 mergeImages(images, [options]) 方法，我们可以轻松地实现图片合成的功能。调用该方法后，会返回一个 Promise 对象，当异步操作完成后，合成的图片会以 Data URLs 的格式返回。

const mergePicEle = document.querySelector("#mergedPic");

const images = ["/body.png", "/eyes.png", "/mouth.png"].map(

  (path) => "../images" + path

);

let imgDataUrl = null;



async function merge() {

  imgDataUrl = await mergeImages(images);

  mergePicEle.src = imgDataUrl;

}

而图片下载的功能是借助 dataUrlToBlob 和 saveFile 这两个函数来实现。它们分别用于实现 Data URLs => Blob 的转换和文件的保存，具体的代码如下所示：

function dataUrlToBlob(base64, mimeType) {

  let bytes = window.atob(base64.split(",")[1]);

  let ab = new ArrayBuffer(bytes.length);

  let ia = new Uint8Array(ab);

  for (let i = 0; i < bytes.length; i++) {

    ia[i] = bytes.charCodeAt(i);

  }

  return new Blob([ab], { type: mimeType });

}



// 保存文件

function saveFile(blob, filename) {

  const a = document.createElement("a");

  a.download = filename;

  a.href = URL.createObjectURL(blob);

  a.click();

  URL.revokeObjectURL(a.href)

}

因为本文的主题是介绍文件下载，所以我们来重点分析 saveFile 函数。在该函数内部，我们使用了 HTMLAnchorElement.download 属性，该属性值表示下载文件的名称。如果该名称不是操作系统的有效文件名，浏览器将会对其进行调整。此外，该属性的作用是表明链接的资源将被下载，而不是显示在浏览器中。

需要注意的是，download 属性存在兼容性问题，比如 IE 11 及以下的版本不支持该属性，具体如下图所示：

（图片来源：caniuse.com/download）

当设置好 a 元素的 download 属性之后，我们会调用 URL.createObjectURL 方法来创建 Object URL，并把返回的 URL 赋值给 a 元素的 href 属性。接着通过调用 a 元素的 click 方法来触发文件的下载操作，最后还会调用一次 URL.revokeObjectURL 方法，从内部映射中删除引用，从而允许删除 Blob（如果没有其他引用），并释放内存。

关于 a 标签下载 的内容就介绍到这，下面我们来介绍如何使用新的 Web API —— showSaveFilePicker 实现文件下载。

a 标签下载示例：a-tag

github.com/semlinker/f…

三、showSaveFilePicker API 下载

showSaveFilePicker API 是 Window 接口中定义的方法，调用该方法后会显示允许用户选择保存路径的文件选择器。该方法的签名如下所示：

let FileSystemFileHandle = Window.showSaveFilePicker(options);

showSaveFilePicker 方法支持一个对象类型的可选参数，可包含以下属性：

• excludeAcceptAllOption：布尔类型，默认值为 false。默认情况下，选择器应包含一个不应用任何文件类型过滤器的选项（由下面的 types 选项启用）。将此选项设置为 true 意味着 types 选项不可用。


• types：数组类型，表示允许保存的文件类型列表。数组中的每一项是包含以下属性的配置对象：
  
  
  
  • description（可选）：用于描述允许保存文件类型类别。
  
  
  • accept：是一个对象，该对象的 key 是 MIME 类型，值是文件扩展名列表。
  
  
  
  

调用 showSaveFilePicker 方法之后，会返回一个 FileSystemFileHandle 对象。有了该对象，你就可以调用该对象上的方法来操作文件。比如调用该对象上的 createWritable 方法之后，就会返回 FileSystemWritableFileStream 对象，就可以把数据写入到文件中。具体的使用方式如下所示：

async function saveFile(blob, filename) {

  try {

    const handle = await window.showSaveFilePicker({

      suggestedName: filename,

      types: [

        {

          description: "PNG file",

          accept: {

            "image/png": [".png"],

          },

        },

        {

          description: "Jpeg file",

          accept: {

            "image/jpeg": [".jpeg"],

          },

         },

      ],

     });

    const writable = await handle.createWritable();

    await writable.write(blob);

    await writable.close();

    return handle;

  } catch (err) {

     console.error(err.name, err.message);

  }

}



function download() {

  if (!imgDataUrl) {

    alert("请先合成图片");

    return;

  }

  const imgBlob = dataUrlToBlob(imgDataUrl, "image/png");

  saveFile(imgBlob, "face.png");

}

当你使用以上更新后的 saveFile 函数，来保存已合成的图片时，会显示以下保存文件选择器：

由上图可知，相比 a 标签下载 的方式，showSaveFilePicker API 允许你选择文件的下载目录、选择文件的保存格式和更改存储的文件名称。看到这里是不是觉得 showSaveFilePicker API 功能挺强大的，不过可惜的是该 API 目前的兼容性还不是很好，具体如下图所示：

（图片来源：caniuse.com/?search=sho…

其实 showSaveFilePicker 是 File System Access API 中定义的方法，除了 showSaveFilePicker 之外，还有 showOpenFilePicker 和 showDirectoryPicker 等方法。如果你想在实际项目中使用这些 API 的话，可以考虑使用 GoogleChromeLabs 开源的 browser-fs-access 这个库，该库可以让你在支持平台上更方便地使用 File System Access API，对于不支持的平台会自动降级使用 <input type="file"> 和 <a download> 的方式。

可能大家对 browser-fs-access 这个库会比较陌生，但是如果换成是 FileSaver.js 这个库的话，应该就比较熟悉了。接下来，我们来介绍如何利用 FileSaver.js 这个库实现客户端文件下载。

showSaveFilePicker API 下载示例：save-file-picker

github.com/semlinker/f…

四、FileSaver 下载

FileSaver.js 是在客户端保存文件的解决方案，非常适合在客户端上生成文件的 Web 应用程序。它是 HTML5 版本的 saveAs() FileSaver 实现，支持大多数主流的浏览器，其兼容性如下图所示：

（图片来源：github.com/eligrey/Fil…

在引入 FileSaver.js 这个库之后，我们就可以使用它提供的 saveAs 方法来保存文件。该方法对应的签名如下所示：

FileSaver saveAs(

 Blob/File/Url, 

 optional DOMString filename, 

 optional Object { autoBom }

)

saveAs 方法支持 3 个参数，第 1 个参数表示它支持 Blob/File/Url 三种类型，第 2 个参数表示文件名（可选），而第 3 个参数表示配置对象（可选）。如果你需要 FlieSaver.js 自动提供 Unicode 文本编码提示（参考：字节顺序标记），则需要设置 { autoBom: true}。

了解完 saveAs 方法之后，我们来举 3 个具体的使用示例：

1. 保存文本

let blob = new Blob(["大家好，我是阿宝哥!"], { type: "text/plain;charset=utf-8" });

saveAs(blob, "hello.txt");

2. 保存线上资源

saveAs("https://httpbin.org/image", "image.jpg");

如果下载的 URL 地址与当前站点是同域的，则将使用 a[download] 方式下载。否则，会先使用 同步的 HEAD 请求 来判断是否支持 CORS 机制，若支持的话，将进行数据下载并使用 Blob URL 实现文件下载。如果不支持 CORS 机制的话，将会尝试使用 a[download] 方式下载。

标准的 W3C File API Blob 接口并非在所有浏览器中都可用，对于这个问题，你可以考虑使用 Blob.js 来解决兼容性问题。

（图片来源：caniuse.com/?search=blo…

3. 保存 canvas 画布内容

let canvas = document.getElementById("my-canvas");

canvas.toBlob(function(blob) {

  saveAs(blob, "abao.png");

});

需要注意的是 canvas.toBlob() 方法并非在所有浏览器中都可用，对于这个问题，你可以考虑使用 canvas-toBlob.js 来解决兼容性问题。

（图片来源：caniuse.com/?search=toB…

介绍完 saveAs 方法的使用示例之后，我们来更新前面示例中的 download 方法：

function download() {

  if (!imgDataUrl) {

    alert("请先合成图片");

    return;

  }

  const imgBlob = dataUrlToBlob(imgDataUrl, "image/png");

  saveAs(imgBlob, "face.png");

}

很明显，使用 saveAs 方法之后，下载已合成的图片就很简单了。如果你对 FileSaver.js 的工作原理感兴趣的话，可以阅读 聊一聊 15.5K 的 FileSaver，是如何工作的？ 这篇文章。前面介绍的场景都是直接下载单个文件，其实我们也可以在客户端同时下载多个文件，然后把已下载的文件压缩成 Zip 包并下载到本地。

FileSaver 下载示例：file-saver

github.com/semlinker/f…

五、Zip 下载

在 文件上传，搞懂这8种场景就够了 这篇文章中，阿宝哥介绍了如何利用 JSZip 这个库提供的 API，把待上传目录下的所有文件压缩成 ZIP 文件，然后再把生成的 ZIP 文件上传到服务器。同样，利用 JSZip 这个库，我们可以实现在客户端同时下载多个文件，然后把已下载的文件压缩成 Zip 包，并下载到本地的功能。对应的操作流程如下图所示：

在以上 Gif 图中，阿宝哥演示了把 3 张素材图，打包成 Zip 文件并下载到本地的过程。接下来，我们来介绍如何使用 JSZip 这个库实现以上的功能。

html

<h3>Zip 下载示例</h3>

<div>

  <img src="../images/body.png" />

  <img src="../images/eyes.png" />

  <img src="../images/mouth.png" />

</div>

<button onclick="download()">打包下载</button>

js

const images = ["body.png", "eyes.png", "mouth.png"];

const imageUrls = images.map((name) => "../images/" + name);



async function download() {

  let zip = new JSZip();

  Promise.all(imageUrls.map(getFileContent)).then((contents) => {

    contents.forEach((content, i) => {

      zip.file(images[i], content);

    });

    zip.generateAsync({ type: "blob" }).then(function (blob) {

      saveAs(blob, "material.zip");

    });

  });

}



// 从指定的url上下载文件内容

function getFileContent(fileUrl) {

  return new JSZip.external.Promise(function (resolve, reject) {

    // 调用jszip-utils库提供的getBinaryContent方法获取文件内容

    JSZipUtils.getBinaryContent(fileUrl, function (err, data) {

      if (err) {

        reject(err);

      } else {

        resolve(data);

      }

    });

  });

}

在以上代码中，当用户点击 打包下载 按钮时，就会调用 download 函数。在该函数内部，会先调用 JSZip 构造函数创建 JSZip 对象，然后使用 Promise.all 函数来确保所有的文件都下载完成后，再调用 file(name, data [,options]) 方法，把已下载的文件添加到前面创建的 JSZip 对象中。最后通过 zip.generateAsync 函数来生成 Zip 文件并使用 FileSaver.js 提供的 saveAs 方法保存 Zip 文件。

Zip 下载示例：Zip

github.com/semlinker/f…

最近因为鸿星尔克给河南捐了5000万物资，真的是看哭了很多的网友，普通一家公司捐款5000万可能不会有这样的共情，但是看了鸿星尔克的背景之后，发现真的是令人心酸。鸿星尔克2020年的营收是28亿，但是利润却是亏损2个亿，甚至连微博的官方账号都舍不得开会员，在这种情况下，还豪气地捐赠5000万，真的是破防了。

网友还称鸿星尔克，特别像是老一辈人省吃俭用一分一毛攒起来的存款，小心翼翼存在铁盒里。一听说祖国需要，立马拿出铁盒子，哗~全导给你。让上最贵的鞋，拿出了双 249 的。

然后我去鸿星尔克的官网看了看他家的鞋子。

好家伙，等了55秒，终于把网站打开了。。。（看来真的是年久失修了，太令人心酸了。作为一个前端看到这一幕真的疯了...）

恰逢周末，我就去了离我最近的鸿星尔克看了看。买了一双 136 的鞋子（是真的便宜，最关键的还是舒服）。

买回家后心里想着，像毒APP上面那些阿迪、耐克的都有线上 360° 查看，就想着能不能给鸿星尔克也做一个呢，算作为一个技术人员为它出的一份绵薄之力。

行动

有了这个想法后，我就立马开始行动了。然后我大致总结了以下几个步骤：

1.建模

2.使用 Thee.js 创建场景

3.导入模型

4.加入 Three.js 控制器

由于之前学习了一些 Three.js 的相关知识，因此对于有了模型后的展示还是比较有底的，因此其中最麻烦的就是建模了，因为我们需要把一个3维的东西，放到电脑中。对于2维的物体，想要放到电脑上，我们都知道，非常简单，就是使用相机拍摄一下就好了，但是想要在电脑中查看3维的物体却不一样，它多了一个维度，增加的量确实成倍的增长，于是开始查阅各种资料来看如何能够建立一个物体的模型。

查了一堆资料，想要建立一个鞋子模型，总结起来共有两种模式。

1.摄影绘图法（photogrammetry）：通过拍摄照片，通过纯算法转化成3d模型，在图形学中也称为单目重建 。

2.雷达扫描（Lidar scan）：是通过激光雷达扫描，何同学的最新一期视频中也提到了这种方式扫描出点云。

放上一个我总结的大纲，大部分都是国外的网站/工具。

一开始搜索结果中，绝大多数人都在提 123D Catch，并且也看了很多视频，说它建立模型快速且逼真，但是再进一步的探索中，发现它貌似在2017年的时候业务就进行了合并进行了整合。整合后的 ReMake 需要付费，处于成本考虑我就没有继续了。（毕竟只是demo尝试）

后面发现一款叫做 Polycam 的软件，成品效果非常好。

但是当我选择使用的时候，发现它需要激光雷达扫描仪（LiDAR），必须要 iphone 12 pro 以上的机型才能使用。

最终我选择了 Reality Capture 来创建模型，他是可以通过多张图片来合成一个模型的方式，看了一些b站的视频，感觉它的呈像效果也不错，不过它只支持 windows，且运行内存需要8g，这个时候我搬出了我7年前的windows电脑... 发现没想到它还能服役，也是惊喜。

建模

下面就开始正式的内容，主角就是我这次买的鞋子（开头放的那双）

然后我们开始拍摄，首先我环绕着鞋子随意拍摄了一组照片，但是发现这个模型真的差强人意...

后面我也采用了白幕的形式，加了一层背景，后面发现还是不行，应用更多是识别到了后面的背景数字。

最后... 还是在楠溪的帮助下，将背景图P成了白色。

皇天不负有心人，最终的效果还不错，基本上的点云模型已经出来了。（这感觉还不错，有种电影里的黑科技的感觉）

下面是模型的样子，已经是我花了一天的时间训练出的最好的模型了（但是还是有一些轻微的粗糙）

为了尽可能的让模型看起来完美，中间一共花了一天的时间来测试模型，因为拍摄的角度以及非常影响模型的生成，我一共拍了大约1G的图片，大约500张图片（由于前期不懂如何调整模型，因此尝试了大量的方法。）

有了模型后，我们就可以将它展示在互联网上啦，这里采用了 Three.js（由于这里考虑到很多人不是这块领域相关的人员，因此会讲的比较基础，大佬们请见谅。）

构建应用

主要由三部分组成（构建场景、模型加载、添加控制器）

1.构建3d场景

首先我们先加载 Three.js

<script type="module">

import * as THREE from 'https://cdn.jsdelivr.net/npm/three@0.129.0/build/three.module.js';

</script>

然后创建一个WebGL渲染器

const container = document.createElement( 'div' );

document.body.appendChild( container );



let renderer = new THREE.WebGLRenderer( { antialias: true } );

container.appendChild( renderer.domElement );

再将添加一个场景和照相机

let scene = new THREE.Scene();

相机语法PerspectiveCamera(fov, aspect, near, far)

// 设置一个透视摄像机

camera = new THREE.PerspectiveCamera( 45, window.innerWidth / window.innerHeight, 0.25, 1000 );

// 设置相机的位置

camera.position.set( 0, 1.5, -30.0 );

将场景和相机添加到 WebGL渲染器中。

renderer.render( scene, camera );

2.模型加载

由于我们的导出的模型是 OBJ 格式的，体积非常大，我先后给它压成了 gltf、glb 的格式，Three.js 已经帮我们写好了GLTF 的loader，我们直接使用即可。

// 加载模型

const gltfloader = new GLTFLoader();

const draco = new DRACOLoader();

draco.setDecoderPath('https://www.gstatic.com/draco/v1/decoders/');

gltfloader.setDRACOLoader(draco);

gltfloader.setPath('assets/obj4/');

gltfloader.load('er4-1.glb', function (gltf) {

  gltf.scene.scale.set(0.2, 0.2, 0.2); //设置缩放

  gltf.scene.rotation.set(-Math.PI / 2, 0, 0) // 设置角度

  const Orbit = new THREE.Object3D();

  Orbit.add(gltf.scene);

  Orbit.rotation.set(0, Math.PI / 2, 0);



  scene.add(Orbit);

  render();

});

但是通过以上代码打开我们的页面会是一片漆黑，这个是因为我们的还没有添加光照。于是我们继续来添加一束光，来照亮我们的鞋子。

// 设置灯光

const directionalLight = new THREE.AmbientLight(0xffffff, 4);

scene.add(directionalLight);

directionalLight.position.set(2, 5, 5);

现在能够清晰地看到我们的鞋子了，仿佛黑暗中看到了光明，但是这时候无法通过鼠标或者手势控制的，需要用到我们 Three.js 的控制器来帮助我们控制我们的模型角度。

3.添加控制器

const controls = new OrbitControls( camera, renderer.domElement );

controls.addEventListener('change', render );

controls.minDistance = 2; // 限制缩放

controls.maxDistance = 10;

controls.target.set( 0, 0, 0 );  // 旋转中心点

controls.update()

这个时候我们就能从各个角度看我们的鞋子啦。

大功告成！

在线体验地址: resume.mdedit.online/erke/

开源地址（包含了工具、运行步骤以及实际demo）：github.com/hua1995116/…

后续规划

由于时间有限（花了一整天周末的时间），还是没有得到一个非常完美的模型，后续也会继续探索这块的实现，再后续将探索是否能实现一条自动化的方式，从拍摄到模型的展示，以及其实我们有了模型后，离AR试鞋也不远了，如果你有兴趣或者有更好的想法建议，欢迎和我交流。

最后非常感谢楠溪，放下了原本计划的一些事情来帮助一起拍摄加后期处理，以及陪我处理了一整天的模型。（条件有限的拍摄真的太艰难了。）

还有祝鸿星尔克能够成为长久的企业，保持创新，做出更多更好的运动服装，让此刻的全民青睐的状态保持下去。

附录

得出的几个拍摄技巧，也是官方提供的。

1.不要限制图像数量，RealityCapture可以处理任意张图片。

2.使用高分辨率的图片。

3.场景表面中的每个点应该在至少两个高质量的图像中清晰可见。

4.拍照时以圆形方式围绕物体移动。

5.移动的角度不要超过30度以上。

6.从拍摄整个对象的照片，移动它然后关注细节，保证大小都差不多。

7.完整的环绕。（不要绕半圈就结束了）

前言

亲爱的coder们，我又来了，一个喜欢图形的程序员👩‍💻，前几篇文章一直都在教大家怎么画地图、画折线图、画烟花🎆，难道图形就是这样嘛，当然不是，一个很简单的问题， 如果我在canvas中画了10万个点，鼠标在画布上移动，靠近哪一个点，哪一个点高亮。有同学就说遇事不决 用for循环遍历哇，我也知道可以用循环解决哇，循环解决几百个点可以，如果是几万甚至几百万个点你还循环，你想让用户等死？这时就引入今天的主角他来了就是Rbush

RBUSH

我们先看下定义，这个rbush到底能帮我们解决了什么问题？

RBush是一个high-performanceJavaScript库，用于点和矩形的二维空间索引。它基于优化的R-tree数据结构，支持大容量插入。空间索引是一种用于点和矩形的特殊数据结构，允许您非常高效地执行“此边界框中的所有项目”之类的查询（例如，比在所有项目上循环快数百倍）。它最常用于地图和数据可视化。

看定义他是基于优化的R-tree数据结构，那么R-tree又是什么呢？

R-trees是用于空间访问方法的树数据结构，即用于索引多维信息，例如地理坐标、矩形或多边形。R-tree 在现实世界中的一个常见用途可能是存储空间对象，例如餐厅位置或构成典型地图的多边形：街道、建筑物、湖泊轮廓、海岸线等，然后快速找到查询的答案例如“查找我当前位置 2 公里范围内的所有博物馆”、“检索我所在位置 2 公里范围内的所有路段”（以在导航系统中显示它们）或“查找最近的加油站”（尽管不将道路进入帐户）。

R-tree的关键思想是将附近的对象分组，并在树的下一个更高级别中用它们的最小边界矩形表示它们；R-tree 中的“R”代表矩形。由于所有对象都位于此边界矩形内，因此不与边界矩形相交的查询也不能与任何包含的对象相交。在叶级，每个矩形描述一个对象；在更高级别，聚合包括越来越多的对象。这也可以看作是对数据集的越来越粗略的近似。说着有点抽象，还是看一张图：

我来详细解释下这张图：

0. 首先我们假设所有数据都是二维空间下的点，我们从图中这个R8区域说起，也就是那个shape of data object。别把那一块不规则图形看成一个数据，我们把它看作是多个数据围成的一个区域。为了实现R树结构，我们用一个最小边界矩形恰好框住这个不规则区域，这样，我们就构造出了一个区域：R8。R8的特点很明显，就是正正好好框住所有在此区域中的数据。其他实线包围住的区域，如R9，R10，R12等都是同样的道理。这样一来，我们一共得到了12个最最基本的最小矩形。这些矩形都将被存储在子结点中。


1. 下一步操作就是进行高一层次的处理。我们发现R8，R9，R10三个矩形距离最为靠近，因此就可以用一个更大的矩形R3恰好框住这3个矩形。


2. 同样道理，R15，R16被R6恰好框住，R11，R12被R4恰好框住，等等。所有最基本的最小边界矩形被框入更大的矩形中之后，再次迭代，用更大的框去框住这些矩形。

算法

插入

为了插入一个对象，树从根节点递归遍历。在每一步，检查当前目录节点中的所有矩形，并使用启发式方法选择候选者，例如选择需要最少放大的矩形。搜索然后下降到这个页面，直到到达叶节点。如果叶节点已满，则必须在插入之前对其进行拆分。同样，由于穷举搜索成本太高，因此采用启发式方法将节点一分为二。将新创建的节点添加到上一层，这一层可以再次溢出，并且这些溢出可以向上传播到根节点；当这个节点也溢出时，会创建一个新的根节点并且树的高度增加。

搜索

在范围搜索中，输入是一个搜索矩形（查询框）。搜索从树的根节点开始。每个内部节点包含一组矩形和指向相应子节点的指针，每个叶节点包含空间对象的矩形（指向某个空间对象的指针可以在那里）。对于节点中的每个矩形，必须确定它是否与搜索矩形重叠。如果是，则还必须搜索相应的子节点。以递归方式进行搜索，直到遍历所有重叠节点。当到达叶节点时，将针对搜索矩形测试包含的边界框（矩形），如果它们位于搜索矩形内，则将它们的对象（如果有）放入结果集中。

读着就复杂，但是社区里肯定有大佬替我们封装好了，就不用自己再去手写了，写了写估计不一定对哈哈哈。

RBUSH 用法

用法

// as a ES module

import RBush from 'rbush';



// as a CommonJS module

const RBush = require('rbush');

创建一个树🌲

const tree = new RBush(16);

后面的16 是一个可选项，RBush 的一个可选参数定义了树节点中的最大条目数。 9（默认使用）是大多数应用程序的合理选择。 更高的值意味着更快的插入和更慢的搜索，反之亦然。

插入数据📚

const item = {

    minX: 20,

    minY: 40,

    maxX: 30,

    maxY: 50,

    foo: 'bar'

};

tree.insert(item);

删除数据📚

tree.remove(item);

默认情况下，RBush按引用移除对象。但是，您可以传递一个自定义的equals函数，以便按删除值进行比较，当您只有需要删除的对象的副本时（例如，从服务器加载），这很有用：

tree.remove(itemCopy, (a, b) => {

    return a.id === b.id;

});

删除所有数据

tree.clear();

搜索🔍

const result = tree.search({

    minX: 40,

    minY: 20,

    maxX: 80,

    maxY: 70

});

api 介绍完毕下面👇开始进入实战环节一个简单的小案例——canvas中画布搜索🔍的。

用图片填充画布

填充画布的的过程中，这里和大家介绍一个canvas点的api ——createPattern

CanvasRenderingContext2D .createPattern()是 Canvas 2D API 使用指定的图像 (CanvasImageSource)创建模式的方法。 它通过repetition参数在指定的方向上重复元图像。此方法返回一个CanvasPattern对象。

第一个参数是填充画布的数据源可以是下面这：

• HTMLImageElement


• HTMLVideoElement


• HTMLCanvasElement


• CanvasRenderingContext2D,


• ImageBitmap,


• ImageData,


• Blob.

第二个参数指定如何重复图像。允许的值有：

• "repeat" (both directions),


• "repeat-x" (horizontal only),


• "repeat-y" (vertical only),


• "no-repeat" (neither).

如果为空字符串 ('') 或 null (但不是 undefined)，repetition将被当作"repeat"。

代码如下：

 class search { 

     constructor() { 

         this.canvas = document.getElementById('map') 

         this.ctx = this.canvas.getContext('2d') 

         this.tree = new RBush() 

         this.fillCanvas() 

     } 



     fillCanvas() { 

         const img = new Image() 

         img.src ='https://ztifly.oss-cn-hangzhou.aliyuncs.com/%E6%B2%B9%E7%94%BB.jpeg' 

         img.onload = () => { 

             const pattern = this.ctx.createPattern(img, '') 

             this.ctx.fillStyle = pattern

             this.ctx.fillRect(0, 0, 960, 600) 

         } 

    } 

 } 

这边有个小提醒的就是图片加载成功的回调里面去给画布创建模式，然后就是this 指向问题， 最后就是填充画布。

如图：

数据的生成

数据生成主要在画布的宽度 和长度的范围内随机生成10万个矩形。插入到rbush数据的格式就是有minX、maxX、minY、maxY。这个实现的思路也是非常的简单哇， minX用画布的长度Math.random minY 就是画布的高度Math.random. 然后最大再此基础上随机*20 就OK了，一个矩形就形成了。这个实现的原理就是左上和右下两个点可以形成一个矩形。代码如下：

randomRect() {

  const rect = {}

  rect.minX = parseInt(Math.random() * 960)

  rect.maxX = rect.minX + parseInt(Math.random() * 20)

  rect.minY = parseInt(Math.random() * 600)

  rect.maxY = rect.minY + parseInt(Math.random() * 20)

  rect.name = 'rect' + this.id

  this.id += 1

  return rect

}

然后循环加入10万条数据：

loadItems(n = 100000) {

  let items = []

  for (let i = 0; i < n; i++) {

    items.push(this.randomRect())

  }

  this.tree.load(items)

}

画布填充

这里我创建一个和当前画布一抹一样的canvas，但是里面画了n个矩形，将这个画布 当做图片填充到原先的画布中。

memCanva() {

  this.memCanv = document.createElement('canvas')

  this.memCanv.height = 600

  this.memCanv.width = 960

  this.memCtx = this.memCanv.getContext('2d')

  this.memCtx.strokeStyle = 'rgba(255,255,255,0.7)'

}



loadItems(n = 10000) {

  let items = []

  for (let i = 0; i < n; i++) {

    const item = this.randomRect()

    items.push(item)

    this.memCtx.rect(

      item.minX,

      item.minY,

      item.maxX - item.minX,

      item.maxY - item.minY

    )

  }

  this.memCtx.stroke()

  this.tree.load(items)

}

然后在加载数据的时候，在当前画布画了10000个矩形。这时候新建的画布有东西了，然后我们用一个drawImage api ,

这个api做了这样的一个事，就是将画布用特定资源填充，然后你可以改变位置，后面有参数可以修改，这里我就不多介绍了， 传送门

this.ctx.drawImage(this.memCanv, 0, 0)

我们看下效果：

添加交互

添加交互， 就是对画布添加mouseMove 事件， 然后呢我们以鼠标的位置，形成一个搜索的数据，然后我在统计花费的时间，然后你就会发现，这个Rbush 是真的快。代码如下：

 this.canvas.addEventListener('mousemove', this.handler.bind(this))

 // mouseMove 事件

 handler(e) {

    this.clearRect()

    const x = e.offsetX

    const y = e.offsetY

    this.bbox.minX = x - 20

    this.bbox.maxX = x + 20

    this.bbox.minY = y - 20

    this.bbox.maxY = y + 20

    const start = performance.now()

    const res = this.tree.search(this.bbox)

    this.ctx.fillStyle = this.pattern

    this.ctx.strokeStyle = 'rgba(255,255,255,0.7)'

    res.forEach((item) => {

      this.drawRect(item)

    })

    this.ctx.fill()

    this.res.innerHTML =

      'Search Time (ms): ' + (performance.now() - start).toFixed(3)

  }

这里给大家讲解一下，现在我们画布是黑白的， 然后以鼠标搜索到数据后，然后我们画出对应的矩形，这时候呢，可以将矩形的填充模式改成 pattern 模式，这样便于我们看的更加明显。fillStyle可以填充3种类型：

ctx.fillStyle = color;

ctx.fillStyle = gradient;

ctx.fillStyle = pattern;

分别代表的是：

OK讲解完毕， 直接gif 看在1万个矩形的搜索中Rbush的表现怎么样。

这是1万个矩形我换成10万个矩形我们在看看效果：

我们发现增加到10万个矩形，速度还是非常快的，也就是1点几毫秒，增加到100万个矩形，canvas 已经有点画不出来了，整个页面已经卡顿了，这边涉及到canvas的性能问题，当图形的数量过多，或者数量过大的时候，fps会大幅度下降的。可以采用批量绘制的方法，还有一种优化手段是分层渲染

我引用一下官方的Rbush的性能图，供大家参考。

总结

最后总结下：rbush 是一种空间索引搜索🔍算法，当你涉及到空间几何搜索的时候，尤其在地图场景下，因为Rbush 实现的原理是比较搜索物体的boundingBox 和已知的boundingBox 求交集， 如果不相交，那么在树的遍历过程中就已经过滤掉了。

前言

随着产品的迭代，项目里的弹框越来越多，业务模块共用的弹框也比较多。在刚开始的阶段，有可能不是共用的业务弹框，我们只放到了当前的业务模块里。随着迭代升级，有些模块会成为通用弹框。简而言之，一个弹框会在多个页面中使用。举例说下我们的场景。

项目当中有这样一个预览的弹框，已经存放在我们的业务组件当中。内容如下

import React from 'react';

import {Modal} from 'antd';



const Preview = (props) => {

    const {visible, ...otherProps} = props;

    return(

        <Modal 

          visible={visible}

          {...otherProps}

          ... // 其它Props

        >

            <div>预览组件的内容</div>

        </Modal>

    )

}

这样的一个组件我们在多个业务模块当中使用，下面我们通过不同的方式来处理这种情况。

各模块引入组件

组件是共用的，我们可以在各业务模块去使用。

在模块A中使用

import React, {useState} from 'react';

import Preview from './components/preview';

import {Button} from 'antd';



const A = () => {

    const [previewState, setPreviewState] = useState({

        visible: false,

        ... // 其它props，包括弹框的props和预览需要的参数等

    });

    

    // 显示弹框

    const showPreview = () => {

        setPreviewState({

            ...previewState,

            visible: true,

        })

    }

    

    // 关闭弹框

    const hidePreview = () => {

         setPreviewState({

            ...previewState,

            visible: false,

        })

    }



    return (<div>

        <Button onClick={showPreview}>预览</Button>

        <Preview {...previewState} onCancel={hidePreview} />

    </div>)

}



export default A;

在模块B中使用

import React, {useState} from 'react';

import Preview from './components/preview';

import {Button} from 'antd';



const B = () => {

    const [previewState, setPreviewState] = useState({

        visible: false,

        ... // 其它props，包括弹框的props和预览需要的参数等

    });

    

    // 显示弹框

    const showPreview = () => {

        setPreviewState({

            ...previewState,

            visible: true,

        })

    }

    

    // 关闭弹框

    const hidePreview = () => {

         setPreviewState({

            ...previewState,

            visible: false,

        })

    }



    return (<div>

        B模块的业务逻辑

        <Button onClick={showPreview}>预览</Button>

        <Preview {...previewState} onCancel={hidePreview} />

    </div>)

}



export default B;

我们发现打开弹框和关闭弹框等这些代码基本都是一样的。如果我们的系统中有三四十个地方需要引入预览组件，那维护起来简直会要了老命，每次有调整，需要改动的地方太多了。

放到Redux中，全局管理。

通过上面我们可以看到显示很关闭的业务逻辑是重复的，我们把它放到redux中统一去管理。先改造下Preview组件

import React from 'react';

import {Modal} from 'antd';



@connect(({ preview }) => ({

  ...preview,

}))

const Preview = (props) => {

    const {visible} = props;

    

    const handleCancel = () => {

        porps.dispatch({

            type: 'preview/close'

        })

    }

    

    return(

        <Modal 

          visible={visible}

          onCancel={handleCancel}

          ... // 其它Props

        >

            <div>预览组件的内容</div>

        </Modal>

    )

}

在redux中添加state管理我们的状态和处理一些参数

const initState = {

  visible: false,

};



export default {

  namespace: 'preview',

  state: initState,

  reducers: {

    open(state, { payload }) {

      return {

        ...state,

        visible: true,

      };

    },

    close(state) {

      return {

        ...state,

        visible: false,

      };

    },

  },



};

全局引入

我们想要在模块中通过dispatch去打开我们弹框，需要在加载这些模块之前就导入我们组件。我们在Layout中导入组件

import Preview from './components/preview';

const B = () => {



    return (<div>

        <Header>顶部导航</Header>

        <React.Fragment>

            // 存放我们全局弹框的地方

            <Preview />

        </React.Fragment>

    </div>)

}



export default B;

在模块A中使用

import React, {useState} from 'react';

import Preview from './components/preview';

import {Button} from 'antd';



@connect()

const A = (porps) => {

    // 显示弹框

    const showPreview = () => {

       porps.dispatch({

           type: 'preview/show'

           payload: { ... 预览需要的参数}

       })

    }

    return (<div>

        <Button onClick={showPreview}>预览</Button>

    </div>)

}



export default A;

在模块B中使用

import React, {useState} from 'react';

import Preview from './components/preview';

import {Button} from 'antd';



@connect()

const B = () => {

    // 显示弹框

    const showPreview = () => {

       this.porps.dispatch({

           type: 'preview/show'

           payload: { ... 预览需要的参数}

       })

    }

    return (<div>

        <Button onClick={showPreview}>预览</Button>

    </div>)

}



export default B;

放到redux中去管理状态，先把弹框组件注入到我们全局当中，我们在业务调用的时候只需通过dispatch就可以操作我们的弹框。

基于插件注入到业务当中

把状态放到redux当中，我们每次都要实现redux那一套流程和在layout组件中注入我们的弹框。我们能不能不关心这些事情，直接在业务当中使用呢。

创建一个弹框的工具类

class ModalViewUtils {



  // 构造函数接收一个组件

  constructor(Component) {

    this.div = document.createElement('div');

    this.modalRef = React.createRef();

    this.Component = Component;

  }



  onCancel = () => {

    this.close();

  }



  show = ({

    title,

    ...otherProps

  }: any) => {

    const CurrComponent = this.Component;

    document.body.appendChild(this.div);

    ReactDOM.render(<GlobalRender>

        <Modal

          onCancel={this.onCancel}

          visible

          footer={null}

          fullScreen

          title={title || '预览'}

          destroyOnClose

          getContainer={false}

        >

          <CurrComponent {...otherProps} />

        </ZetModal>

      </GlobalRender>, this.div)



  }

  

  close = () => {

    const unmountResult = ReactDOM.unmountComponentAtNode(this.div);

    if (unmountResult && this.div.parentNode) {

      this.div.parentNode.removeChild(this.div);

    }

  }



}



export default ModalViewUtils;

更改Preview组件

import React, { FC, useState } from 'react';

import * as ReactDOM from 'react-dom';

import ModalViewUtils from '../../utils/modalView';



export interface IModalViewProps extends IViewProps {

  title?: string;

  onCancel?: () => void;

}



// view 组件的具体逻辑

const ModalView: FC<IModalViewProps> = props => {

  const { title, onCancel, ...otherProps } = props;

  return <View isModal {...otherProps} />

}



// 实例化工具类，传入对用的组件

export default new ModalViewUtils(ModalView);

在模块A中使用

import React, {useState} from 'react';

import Preview from './components/preview';

import {Button} from 'antd';



const A = (porps) => {

    // 显示弹框

    const showPreview = (params) => {

       Preview.show()

    }

    return (<div>

        <Button onClick={showPreview}>预览</Button>

    </div>)

}



export default A;

在模块B中使用

import React, {useState} from 'react';

import Preview from './components/preview';

import {Button} from 'antd';



const B = () => {

    // 显示弹框

    const showPreview = () => {

         Preview.show(params)

    }

    return (<div>

        <Button onClick={showPreview}>预览</Button>

    </div>)

}



export default B;

基于这种方式，我们只用关心弹框内容的实现，调用的时候直接引入组件，调用show方法, 不会依赖redux，也不用再调用的地方实例组件，并控制显示隐藏等。

基于Umi插件，不需引入模块组件

我们可以借助umi的插件，把全局弹框统一注入到插件当中, 直接使用。

import React, {useState} from 'react';

import {ModalView} from 'umi';

import {Button} from 'antd';



const A = () => {

    // 显示弹框

    const showPreview = () => {

         ModalView.Preview.show(params)

    }

    return (<div>

        <Button onClick={showPreview}>预览</Button>

    </div>)

}



export default A

结束语

对全局弹框做的统一处理，大家有问题，评论一起交流。

👆 这句话，想然大家道理都懂 ~

但最近在暑期实习的日子里，我特意留心观察了一下身边的实习生同学使用工具的习惯。我发现自己在大学认为高效率的工作模式，他们无论在意识层面还是在使用层面上对工具的掌握都有些蹩脚。特别是有部分同学 Mac 也没有怎么接触过，算是效率领域的门外汉了。所以本着做个负责的好师兄的态度，我将自己对工具使用的经验，分享给大家。也算是抛砖引玉，和大家一起聊聊有哪些 NB 又和好玩的工具。

需要注意的是：我这里主要以 Mac Apple 生态作为基调，但我相信工具和效率提升的思想是不变的，Win 下也有具体的工具可以替代，所以 Win 的同学也可以认真找一找，评论回复一下 Win 下的替代方案吧 🙏🏻

当然，👇 的工具，我没有办法在这种汇总类的文章里面讲透彻，所以都「点到为止」，给了相关扩展阅读的文章，所以感兴趣的话大家再外链出去研究一番，或者自行 Google 社区的优质资源 ~

所以准备好了么？Here we go ~

🛠 前端工作中的那些工具

在开始聊前端的主流工具之前，先强调一下作为的 Coder，熟练，及其熟练，飞一般熟练快捷键的重要性！

成为快捷键爱好者

使用工具软件的时候，我都是下意识地要求自己记住至少 Top 20 操作的「快捷键」。虽然不至于要求一定要成为 vim 编辑者这种级别的「纯金键盘侠」，但至少对 VSCode 主流快捷键要形成「肌肉记忆」。这就问大家一个问题，如果能够回答上，说明大家对 VSCode 快捷键掌握还是不错的 ~ 来：

问：VSCode 中 RenameSymbol 的快捷键是什么？（P.S. 若 Rename Symbol 都不知道是什么作用的话，去打板子吧 😄）

如果回答不上，那请加油了，相信我，快捷键每次操作都可以节省你至少 1s 的时间，想一想，有多划算吧 ~
当然在这里给大家推荐一个查询 Mac 下面应用对「快捷键」注册的工具 —— CheatSheet，长按 Command 键可以激活当前使用 App 的快捷键菜单。like this 👇

捷键没有速成之法，还是在不断重复练习，所以 KEEP ON DOING THAT。

成为 VSCode Professional

工具，也有时髦之说，自从 Typescript 开始泛滥之后，VSCode 确乎成为了主流的前端开发工具。但我发很多同学对 VSCode 的使用上还是处于一种入门水准，没有真正发挥好这个工具的强大之处 ~ 所以也在和大家一起聊一聊。我不打算写一篇 Bible 级别的 VSCode 指南，只是通过几个小 Case 告诉大家 VSCode 有很多有趣的点可以使用以极大程度上提升效率，尤其是 VSCode Extensions（插件）。

1. 你知道 VSCode 是可以云同步配置的功能，且可以一键同步其它设备么？


2. 你知道 VSCode 有一个可以自动给 Typescript 的 import 排序并自动清除无效依赖的插件么？


3. 你知道 VSCode 可以使用快捷键自动折叠代码层数么？


4. 你知道如何快速返回到上一个编辑或者浏览过的文件吗？

如果都知道，那还不错 👍，如果听都没听说过，那我给大家几个建议：

• 把 VSCode 的快捷键列表看一遍，摘出来自己觉得可以将来提升自己编码效率的，反复执行，直到形成肌肉记忆。


• 把 VSCode 安装量和受欢迎度 Top200 的插件，浏览一遍，看看简介，安装自己感兴趣的插件。 👈 来一场探索宝藏的游戏吧，少读一些推荐文章，多动手自己捣鼓，找到好工具！

• 最后把 VSCode 上一个绝美的皮肤和字体，按照我的审美，这就是我要的「滑板鞋」 ~ btw，主题是 OneDarkPro 字体是：FiraCode。

扩展阅读：

• VSCode 插件推荐：B 乎上有很多这类文章，大家自取。


• 编写 VSCode 插件指南：知其然，知其所以然，我之前写过一个 VSCode Plugin，对 VSCode 的架构略知一二，感觉很 NX。

用好 Terminal

作为一个工程师，不要求你成为 Shell 大师，但 Terminal 里面的常用命令以及日常美化优化还是必须要做的。这里给大家推荐 iTerm + OhMyZsh 的模式，打造一个稳定好用的 Terminal。

• 下载 iTerm 安装（你用 VSCode 的也行，但我还是推荐独立终端 App，因为 VSCode 这货有时候会假死，然后把 iTerm 一下整没了，所以还是术业有专攻才行 🙈），有了这货，分屏幕上 👇 就是常规操作了。

• 下载 OhMyZsh 安装，更新最新的 Git 目录，把主流插件都 down 下来，装好后秒变彩色，再安装对应的主题，不要太开心。

• 按照个人兴趣「调教」OhMyZsh，强烈建议在 ~/.zshrc 启动这些插件：谁用谁知道 ~ 😄 随便说一个功能都好用到不行，这里就不啰嗦了，有其它好用插件的同学，欢迎盖楼分享一下。

plugins=(git osx wd autojump zsh-autosuggestions copyfile history last-working-dir)

比如：Git 这个插件就可以将复杂的 git 命令 git checkout -b 'xxx' 简化为：gcb 'xxx' 。

比如：OSX 插件可以帮我们快速打开 Finder 等等操作。

...

扩展阅读：

• 
  

  Shell 编程入门：手撸脚本，提升效率 ✍🏻

  
  


• 
  

  OhMyZsh 插件集：看那些花里胡哨的 shell 插件们，来，拉出来都晒一晒 🌞

  
  


• 
  

  Vim 快捷键 CheatSheet：在手撸服务器时代，Vim 是神器，现在看来依旧值得传火 🧎‍♂️ 大神收下我的膝盖

  
  

用好 Chrome DebugTool

作为一个前端我就不赘述这个的重要性了。强烈建议大家把官方文档撸一遍，你会有很多新知的。

developer.chrome.com/docs/devtoo…

👆 这个可以写一本书，但是我还是建议大家用好这个工具，这是我们前端最重要的调试器了，我经常在面试同学的时候会问关于他们如何使用调试器解决问题的。其实看大家调试代码的过程就知道这个同学的编程水准，真的，大家可以有意识的看看自己是怎么去调试和排查问题的，效率高么？有没有提升空间。

• 比如：如何排查一个项目的渲染卡顿点？


• 比如：如何排查内存泄露？


• 比如：如何全局搜索查找重复的代码？

用好 ChromeExtensions

浏览器插件，我就不多说了。我在此罗列一下我日常使用的 Chrome 插件，也欢迎各路神仙补充自己的浏览器插件和那些骚操作。重点说一下 For 开发者的：

• 
  

  JSONFormatter：对于日常直接请求的 JSON 数据格式化

  
  


• 
  

  XSwitch：我前 TL 手撸的浏览器网络请求代理工具，帮他打个广告 😛

  
  


• 
  

  ReactDeveloerTools 👈 这个就不多解释了，强烈建议大家打开 HighlightRerender 功能，看看自己的代码写得多烂，多多批判一下自己 🙈

  
  

对于 Chrome Extension 这种「神文」比较多，像油猴、AdBlock、视频下载啥的之类的工具我就不在这里提了，懂的人都懂，不懂的人自己 Google。我这里再推荐几篇文章，大家按需阅读吧：

• Chrome 前端插件推荐：B 乎上这个 问题和 回答 比较中肯


• Chrome 通用插件推荐：B 乎继续 推荐，看看高赞回答下的「集体智慧」吧 😁

🔍 搜索！搜索！！搜索！！！

呼，终于聊完了开发用的工具，那接下来我们来聊一下搜索。按照我的理解，我一直把数字化时代个人信息管理的效率分成三个基础段位：

• 入门级：很少整理自己的磁盘和桌面，典型特征就是桌面什么奇葩的命名文件都堆在一起


• 新手级：开始有意识整理了，文件分级分层，重视文件命名，建立标签等机制


• 熟练级：开始有意识建立数据库索引，在 OS 层面做文件索引，有数据意识


• 大师级：开始关注数据，将个人数据，集体数据融入日常，甚至开始使用非结构化的数据来辅助自己做事情

扪心自问，你在哪一个 Level 呢？

Spotlight

第一第二级，我就不了了，这里我重点和大家分享一下达到第三级的索引和搜索工具。要知道在 Mac 下 Spotlight 一直都是一个全局搜索工具，用好 Spotlight，就可以无缝解锁系统级别的搜索，主要的 Apps、文件、日历 ... 都可以搜索。

Alfred

但系统自带的，往往都不是最强的是吧？所以在 Spotlight 系统级的 metadata （Mac 会自建文件索引库并开放 API 给上层应用调用）的基础上，诞生了一个很强的工具 Alfred。我一直是 Alfred 的资深粉丝 + 用户，每天使用 Alfred 的功能（搜索）高达 70 次。👇 图为证：

Alfred 是一个「真正意义上的效率工具」，其主要的功能：

• 文档检索


• 快捷 URL 拼接


• 剪切板历史快速访问 & 搜索


• BookMark 搜索


• 自定义工作流（下一个章节重点聊一聊这个）


• ...（功能无敌）

强烈建议不知道 Alfred 是啥的同学，读一下 👇 这篇文章，这篇文章是我在入职阿里第一年内网写的一篇介绍 Alfred 的文章，如果有收获，还请给我点个赞了 👍

此处为语雀内容卡片，点击链接查看：http://www.yuque.com/surfacew/fe…

🚌 自动化的魅力

「自动化」一定是一种程序工作者应该深深植入自己「脑海里」的思考模式。但凡遇到重复的流程，我们是不是都应该尝试着问自己，这么费时间的流程，频次有多少，是否值得我们使用工具去自动化？

如今，靠做自动化上市的公司也有了，所以这里重点想和大家一起聊一聊个人如何把身边的自动化做到极致。这里重点讲三个工具：Alfred Workflow、Apple 捷径、IFFTT。

AlfredWorkflow

主打 Mac 上的自动化流程。通过 👇 这种可视化编程的思路，创建一种动作流。比如我想实现通过 Cmd + Alt + B 搜索 Chrome 书签 🔖。社区的小伙伴们就已经帮我们实现了一套工作流。我们可以直接在 Alfred 的社区 Packtal 等论坛去下载已经实现的 Workflow 去实现这些日常生活中的小自动化流程。

再比如上面的：

• 
  

  ChromeHistory：搜索 Chrome 历史记录（在 Alfred 搜索中）

  
  


• 
  

  GithubRepos：浏览搜索自己的 GithubRepo

  
  


• 
  

  Colors：快速转换前端颜色（前端同学一定知道为什么这个常用）🙈

  
  

• ... 等等等等

我们也可以定义自己的工作流来自动化一些流程，我用自身的一个 Case 来说，我会定义很多快捷键来绑定我自己的日常操作。比如：

• 
  

  Cmd + Alt + D：打开钉钉

  
  


• 
  

  Alfred 输入 weather：查询天气

  
  


• 
  

  Alfred 输入 calendar：打开百度日历（不为别的，看放假日历 😄）

  
  


• 
  

  codereview：进入集团 CR 的工作台

  
  


• 
  

  ...

  
  

浑然一体，非常好玩，可以大量定制自己的工作流程。我之前写过一篇文章有关联到 Workflow 的部分，感兴趣的可以 一读。

AppleShortcuts

主打手机上的自动化流程。（iPhone）

它提供了近乎 0 代码的流程编排，让我们可以访问 App 以及一些操作系统的 API，从而实现类似 👆 Alfred 的功能编排，是不是也很强。比如我们想要实现一个从剪切板里面读取内容并打开网页的功能，只需要下面增加两个简单的编程动作（真 0 代码）就可以实现自定义流程的实现。

Apple 捷径提供的 API 示意：

可以看到的是，Apple 这些大厂一直在思考真正意义上的让编码平易近人，让普通的小白用户也可以低成本地定义自己的工作流程。Shortcuts 的玩法有很多，在这里就不细细展开了，给大家足够多探索的可能性。

IFFTT

🔗：ifttt.com/home

三方中立的自动化流程提供商。这个工具跨平台多端支持，我用的相对偏少，但可以解决我部分跨平台的流程问题，这块大家自行探索吧 ~

聪明的人，一定会用「自动化」的思维解决问题，所以用好自动化的工具的重要性我相信大家应该明白了。

💻 突破次元壁の工具

最后，再和大家聊一聊非软件的「工具」吧。我还是觉得大家作为 Coder，还是要在自己的装备上多花点盘缠，就像 Kevin 老师用了戴森吹风机就比普通发型师厉害一样。

• 自己的 主力机，一定是要性能杠杠的，经济允许的情况下，前端我还是力挺 Mac（高配） 和 Apple 生态 ~


• 给自己 一块 4K 屏（最好放公司），看着心情都会变好，如果财力雄厚，搞一块 Apple 的 PRO DISPLAY XDR，就给跪了。

• 使用 iPad & ApplePencil 尝试着数字笔记的艺术，涂涂画画，发现灵感，整理思维。

• 
  

  自动升降桌 & 人体工程学椅：对身体，脊椎好一点 🙂 就坐屁股变大，变胖，是不争的事实 😿

  
  


• 
  

  HHKB 键盘 ⌨️，最近用了一段时间，适应布局之后，觉得打字都变快了 ... 可能是金钱的力量让代码翘起来都更顺心了呢 🎶（开个玩笑）

  
  


• 
  

  ...

  
  

🎓 结语

当然，👆 的工具只是大千世界中，集体智慧凝练的工具的冰山一角。

这些工具提升效率创造的增益往往初步看很小，但是大家一定要知道，这种增益会随着时间积累而放大，做一个简单的计算，一天你因为工具里面的 100 次效率优化，每一次即便是优化 5s，一年下来，节省的时间（Alfred 可以直接计算时间）：

是不是令人震惊地高达 50 个小时，活生生的 2 天 啊！！！受限于篇幅，如果大家觉得对这篇文章对自己有帮助的话，欢迎点赞收藏转载（怎么变成了 B 站三连了）哈哈，如果后续有时间的话，我再和大家一起分享一下我是如何做信息管理和知识管理的，希望能够给大家带来一些真正帮助。

前言

最近产品经理在掘金社区的出镜率很高，看来大家都很喜闻乐见工程师与产品经理的相爱相杀。

这次他让我调研一下在网页里实现裸眼3D

这是故意为难我把？

搞什么调研影响我摸鱼

现在的我想拿枪打他

拿弓箭射他

点火烧他

诶，如果我在3D场景中刻意加上一些框框，会不会看上去更立体呢？

方案一：造个框框，再打破它

现在我们用一个非常简单的立方体来试试看

立体感是稍微提升一点，但就这？那怕是交不了差的...

不过，大家发挥一下想象力，框框可以不全是直的，这个B站防遮挡弹幕是不是也让你产生了些裸眼3D的效果呢？

方案二：人脸识别

不行，谁都不能耽误我摸鱼。

此时我又想起另一个方案，是不是可以通过摄像头实时检测人脸在摄像头画面中的位置来模拟裸眼3D呢。我找到了tracking.js，这是一款在浏览器中可以实时进行人脸检测的库。

github.com/eduardolund…

var tracker = new tracking.ObjectTracker('face');

  tracker.setInitialScale(4);

  tracker.setStepSize(2);

  tracker.setEdgesDensity(0.1);



  tracking.track('#video', tracker, { camera: true });



  tracker.on('track', function(event) {

    context.clearRect(0, 0, canvas.width, canvas.height);



    event.data.forEach(function(rect) {

      context.strokeStyle = '#a64ceb';

      context.strokeRect(rect.x, rect.y, rect.width, rect.height);

      context.font = '11px Helvetica';

      context.fillStyle = "#fff";

      context.fillText('x: ' + rect.x + 'px', rect.x + rect.width + 5, rect.y + 11);

      context.fillText('y: ' + rect.y + 'px', rect.x + rect.width + 5, rect.y + 22);

    });

  });

我们可以看到，画面中呈现了人脸在摄像头视角画布中的坐标，有了这个坐标数据，我们就可以做很多事情了。

接着把它接到threejs中，我们仍然拿这个立方体来试试看

实际体验还有点意思，但录屏的感受不太明显，请自行下载demo源码试试看吧

方案三：陀螺仪

W3C标准APIDeviceOrientation，用于检测移动设备的旋转方向和加速度。通过这个API，我们可以获取到三个基础属性：

• alpha（设备平放时，水平旋转的角度）

• beta（设备平放时，绕横向X轴旋转的角度）

• gamma（设备平放时，绕纵向Y轴旋转的角度）

这个API的使用非常简单，通过给window添加一个监听

function capture_orientation (event) { 

    var alpha = event.alpha; 

    var beta = event.beta; 

    var gamma = event.gamma; 

    console.log('Orientation - Alpha: '+alpha+', Beta: '+beta+', Gamma: '+gamma); 

}



window.addEventListener('deviceorientation', capture_orientation, false);

现在我们把这个加入到咱们的立方体演示中，在加入的过程中，这里需要注意的是，在IOS设备上，这个API需要主动申请用户权限。

window.DeviceOrientationEvent.requestPermission()

    .then(state => {

        switch (state) {

            case "granted":

                //在这里建立监听

                window.addEventListener('deviceorientation', capture_orientation, false);

                break;

            case "denied":

                alert("你拒绝了使用陀螺仪");

                break;

            case "prompt":

                alert("其他行为");

                break;

        }

});

返回的是一个promise，所以你也可以这么写

var permissionState = await window.DeviceOrientationEvent.requestPermission();

if(permissionState=="granted")window.addEventListener('deviceorientation', capture_orientation, false);

还有几点需要注意的事，requestPermission必须由用户主动发起，也就是必须在用户的行为事件里触发，比如“click”，还有就是这个API的调用，必须在HTTPS协议访问的网页里使用。

结语

至此，我能想到在网页里实现裸眼3D的几种方法都在此文中，你还能想到别的方法吗？请在评论区一起讨论吧。

有言在先

本瓜知道前不久写的《JS 如何函数式编程》系列各位可能并不感冒，因为一切理论的东西如果脱离实战的话，那就将毫无意义。

于是乎，本瓜着手于实际工作开发，尝试应用函数式编程的一些思想。

最终惊人的发现：这个实现过程并不难，但是效果却不小！

实现思路：借助 compose 函数对连续的异步过程进行组装，不同的组合方式实现不同的业务流程。

这样不仅提高了代码的可读性，还提高了代码的扩展性。我想：这也许就是高内聚、低耦合吧~

撰此篇记之，并与各位分享。

场景说明

在和产品第一次沟通了需求后，我理解需要实现一个应用 新建流程，具体是这样的：

第 1 步：调用 sso 接口，拿到返回结果 res_token；

第 2 步：调用 create 接口，拿到返回结果 res_id；

第 3 步：处理字符串，拼接 Url；

第 4 步：建立 websocket 链接；

第 5 步：拿到 websocket 后端推送关键字，渲染页面；

• 注：接口、参数有做一定简化

上面除了第 3 步、第 5 步，剩下的都是要调接口的，并且前后步骤都有传参的需要，可以理解为一个连续且有序的异步调用过程。

为了快速响应产品需求，于是本瓜迅速写出了以下代码：

/**

 * 新建流程

 * @param {*} appId

 * @param {*} tag

 */



export const handleGetIframeSrc = function(appId, tag) {

  let h5Id

// 第 1 步: 调用 sso 接口，获取token

  getsingleSignOnToken({ formSource: tag }).then(data => { 

    return new Promise((resolve, reject) => {

      resolve(data.result)

    })

  }).then(token => { 

    const para = { appId: appId }

    return new Promise((resolve, reject) => {

// 第 2 步: 调用 create 接口，新建应用

      appH5create(para).then(res => {

// 第 3 步: 处理字符串，拼接 Url

        this.handleInsIframeUrl(res, token, appId)

        this.setH5Id(res.result.h5Id)

        h5Id = res.result.h5Id

        resolve(h5Id)

      }).catch(err => {

        this.$message({

          message: err.message || '出现错误',

          type: 'error'

        })

      })

    })

  }).then(h5Id => { 

// 第 4 步：建立 websocket 链接；

    return new Promise((resolve, reject) => {

      webSocketInit(resolve, reject, h5Id)

    })

  }).then(doclose => {

// 第 5 步：拿到 websocket 后端推送关键字，渲染页面；

    if (doclose) { this.setShowEditLink({ appId: appId, h5Id: h5Id, state: true }) }

  }).catch(err => {

    this.$message({

      message: err.message || '出现错误',

      type: 'error'

    })

  })

}



const handleInsIframeUrl = function(res, token, appId) { 

// url 拼接

  const secretId = this.$store.state.userinfo.enterpriseList[0].secretId

  let editUrl = res.result.editUrl

  const infoId = editUrl.substr(editUrl.indexOf('?') + 1, editUrl.length - editUrl.indexOf('?'))

  editUrl = res.result.editUrl.replace(infoId, `from=a2p&${infoId}`)

  const headList = JSON.parse(JSON.stringify(this.headList))

  headList.forEach(i => {

    if (i.appId === appId) { i.srcUrl = `${editUrl}&token=${token}&secretId=${secretId}` }

  })

  this.setHeadList(headList)

}

这段代码是非常自然地根据产品所提需求，然后自己理解所编写。

其实还可以，是吧？🐶

需求更新

但你不得不承认，程序员和产品之间有一条无法逾越的沟通鸿沟。

它大部分是由所站角度不同而产生，只能说：李姐李姐！

所以，基于前一个场景，需求发生了点 更新 ~

除了上节所提的 【新建流程】 ，还要加一个 【编辑流程】 ╮(╯▽╰)╭

编辑流程简单来说就是：砍掉新建流程的第 2 步调接口，再稍微调整传参即可。

于是本瓜直接 copy 一下再作简单删改，不到 1 分钟，编辑流程的代码就诞生了~

/**

 * 编辑流程

 */

 

const handleToIframeEdit = function() { // 编辑 iframe

  const { editUrl, appId, h5Id } = this.ruleForm

// 第 1 步: 调用 sso 接口，获取token

  getsingleSignOnToken({ formSource: 'ins' }).then(data => {

    return new Promise((resolve, reject) => {

      resolve(data.result)

    })

  }).then(token => { 

// 第 2 步：处理字符串，拼接 Url

    return new Promise((resolve, reject) => {

      const secretId = this.$store.state.userinfo.enterpriseList[0].secretId

      const infoId = editUrl.substr(editUrl.indexOf('?') + 1, editUrl.length - editUrl.indexOf('?'))

      const URL = editUrl.replace(infoId, `from=a2p&${infoId}`)

      const headList = JSON.parse(JSON.stringify(this.headList))

      headList.forEach(i => {

        if (i.appId === appId) { i.srcUrl = `${URL}&token=${token}&secretId=${secretId}` }

      })

      this.setHeadList(headList)

      this.setShowEditLink({ appId: appId, h5Id: h5Id, state: false })

      this.setShowNavIframe({ appId: appId, state: true })

      this.setNavLabel(this.headList.find(i => i.appId === appId).name)

      resolve(h5Id)

    })

  }).then(h5Id => {

// 第 3 步：建立 websocket 链接；

    return new Promise((resolve, reject) => {

      webSocketInit(resolve, reject, h5Id)

    })

  }).then(doclose => {

// 第 4 步：拿到 websocket 后端推送关键字，渲染页面；

    if (doclose) { this.setShowEditLink({ appId: appId, h5Id: h5Id, state: true }) }

  }).catch(err => {

    this.$message({

      message: err.message || '出现错误',

      type: 'error'

    })

  })

}

需求再更新

老实讲，不怪产品，咱做需求的过程也是逐步理解需求的过程。理解有变化，再正常不过！(#^.^#) 李姐李姐......

上面已有两个流程：新建流程、编辑流程。

这次，要再加一个 重新创建流程 ~

重新创建流程可简单理解为：在新建流程之前调一个 delDraft 删除草稿接口；

至此，我们产生了三个流程：

1. 新建流程；


2. 编辑流程；


3. 重新创建流程；

本瓜这里作个简单的脑图示意逻辑：

我的直觉告诉我：不能再 copy 一份新建流程作修改了，因为这样就太拉了。。。没错，它没有耦合，但是它也没有内聚，这不是我想要的。于是，我开始封装了......

实现上述脑图的代码：

/**

 * 判断是否存在草稿记录？

 */

judgeIfDraftExist(item) {

  const para = { appId: item.appId }

  return appH5ifDraftExist(para).then(res => {

    const { editUrl, h5Id, version } = res.result

    if (h5Id === -1) { // 不存在草稿

      this.handleGetIframeSrc(item)

    } else { // 存在草稿

      this.handleExitDraft(item, h5Id, version, editUrl)

    }

  }).catch(err => {

    console.log(err)

  })

},

/**

 * 选择继续编辑？

 */

handleExitDraft(item, h5Id, version, editUrl) {

  this.$confirm('有未完成的信息收集链接，是否继续编辑?', '提示', {

    confirmButtonText: '继续编辑',

    cancelButtonText: '重新创建',

    type: 'warning'

  }).then(() => {

    const editUrlH5Id = h5Id

    this.handleGetIframeSrc(item, editUrl, editUrlH5Id)

  }).catch(() => {

    this.handleGetIframeSrc(item)

    appH5delete({ h5Id: h5Id, version: version })

  })

},

/**

 * 新建流程、编辑流程、重新创建流程；

 */

handleGetIframeSrc(item, editUrl, editUrlH5Id) {

  let ws_h5Id

  getsingleSignOnToken({ formSource: item.tag }).then(data => { 

// 调用 sso 接口，拿到返回结果 res_token；

    return new Promise((resolve, reject) => {

      resolve(data.result)

    })

  }).then(token => {

    const para = { appId: item.appId }

    return new Promise((resolve, reject) => {

      if (!editUrl) { // 新建流程、重新创建流程

// 调用 create 接口，拿到返回结果 res_id；

        appH5create(para).then(res => {

// 处理字符串，拼接 Url；

          this.handleInsIframeUrl(res.result.editUrl, token, item.appId)

          this.setH5Id(res.result.h5Id)

          ws_h5Id = res.result.h5Id

          this.setShowNavIframe({ appId: item.appId, state: true })

          this.setNavLabel(item.name)

          resolve(true)

        }).catch(err => {

          this.$message({

            message: err.message || '出现错误',

            type: 'error'

          })

        })

      } else { // 编辑流程

        this.handleInsIframeUrl(editUrl, token, item.appId)

        this.setH5Id(editUrlH5Id)

        ws_h5Id = editUrlH5Id

        this.setShowNavIframe({ appId: item.appId, state: true })

        this.setNavLabel(item.name)

        resolve(true)

      }

    })

  }).then(() => { 

// 建立 websocket 链接；

    return new Promise((resolve, reject) => {

      webSocketInit(resolve, reject, ws_h5Id)

    })

  }).then(doclose => {

// 拿到 websocket 后端推送关键字，渲染页面；

    if (doclose) { this.setShowEditLink({ appId: item.appId, h5Id: ws_h5Id, state: true }) }

  }).catch(err => {

    this.$message({

      message: err.message || '出现错误',

      type: 'error'

    })

  })

},



handleInsIframeUrl(editUrl, token, appId) {

// url 拼接

  const secretId = this.$store.state.userinfo.enterpriseList[0].secretId

  const infoId = editUrl.substr(editUrl.indexOf('?') + 1, editUrl.length - editUrl.indexOf('?'))

  const url = editUrl.replace(infoId, `from=a2p&${infoId}`)

  const headList = JSON.parse(JSON.stringify(this.headList))

  headList.forEach(i => {

    if (i.appId === appId) { i.srcUrl = `${url}&token=${token}&secretId=${secretId}` }

  })

  this.setHeadList(headList)

}

如此，我们便将 新建流程、编辑流程、重新创建流程 全部整合到了上述代码；

需求再再更新

上面的封装看起来似乎还不错，但是这时我害怕了！想到：如果这个时候，还要加流程或者改流程呢？？？ 我是打算继续用 if...else 叠加在那个主函数里面吗？还是打算直接 copy 一份再作删改？

我都能遇见它会充斥着各种判断，变量赋值、引用飞来飞去，最终成为一坨💩，没错，代码屎山的💩

我摸了摸左胸的左心房，它告诉我：“饶了接盘侠吧~”

于是乎，本瓜尝试引进了之前吹那么 nb 的函数式编程！它的能力就是让代码更可读，这是我所需要的！来吧！！展示！！

compose 函数

我们在 《XDM，JS如何函数式编程？看这就够了！（三）》 这篇讲过函数组合 compose！没错，我们这次就要用到这个家伙！

还记得那句话吗?

组合 ———— 声明式数据流 ———— 是支撑函数式编程最重要的工具之一！

最基础的 compose 函数是这样的：

function compose(...fns) {

    return function composed(result){

        // 拷贝一份保存函数的数组

        var list = fns.slice();

        while (list.length > 0) {

            // 将最后一个函数从列表尾部拿出

            // 并执行它

            result = list.pop()( result );

        }

        return result;

    };

}



// ES6 箭头函数形式写法

var compose =

    (...fns) =>

        result => {

            var list = fns.slice();

            while (list.length > 0) {

                // 将最后一个函数从列表尾部拿出

                // 并执行它

                result = list.pop()( result );

            }

            return result;

        };

它能将一个函数调用的输出路由跳转到另一个函数的调用上，然后一直进行下去。

我们不需关注黑盒子里面做了什么，只需关注：这个东西（函数）是什么！它需要我输入什么！它的输出又是什么！

composePromise

但上面提到的 compose 函数是组合同步操作，而在本篇的实战中，我们需要组合是异步函数！

于是它被改造成这样：

/**

 * @param  {...any} args

 * @returns

 */



export const composePromise = function(...args) {

  const init = args.pop()

  return function(...arg) {

    return args.reverse().reduce(function(sequence, func) {

      return sequence.then(function(result) {

        // eslint-disable-next-line no-useless-call

        return func.call(null, result)

      })

    }, Promise.resolve(init.apply(null, arg)))

  }

}

原理：Promise 可以指定一个 sequence，来规定一个执行 then 的过程，then 函数会等到执行完成后，再执行下一个 then 的处理。启动sequence 可以使用 Promise.resolve() 这个函数。构建 sequence 可以使用 reduce 。

我们再写一个小测试在控制台跑一下！

let compose = function(...args) {

  const init = args.pop()

  return function(...arg) {

    return args.reverse().reduce(function(sequence, func) {

      return sequence.then(function(result) {

        return func.call(null, result)

      })

    }, Promise.resolve(init.apply(null, arg)))

  }

}



let a = async() => {

  return new Promise((resolve, reject) => {

    setTimeout(() => {

      console.log('xhr1')

      resolve('xhr1')

    }, 5000)

  })

}



let b = async() => {

  return new Promise((resolve, reject) => {

    setTimeout(() => {

      console.log('xhr2')

      resolve('xhr2')

    }, 3000)

  })

}

let steps = [a, b] // 从右向左执行

let composeFn = compose(...steps)



composeFn().then(res => { console.log(666) })



// xhr2

// xhr1

// 666

它会先执行 b ，3 秒后输出 "xhr2"，再执行 a，5 秒后输出 "xhr1"，最后输出 666

你也可以在控制台带参 debugger 试试，很有意思：

composeFn(1, 2).then(res => { console.log(66) })

逐渐美丽起来

测试通过！借助上面 composePromise 函数，我们更加有信心用函数式编程 composePromise 重构 我们的代码了。

• 实际上，这个过程一点不费力~

实现如下：

/**

 * 判断是否存在草稿记录？

 */

handleJudgeIfDraftExist(item) {

    return appH5ifDraftExist({ appId: item.appId }).then(res => {

      const { editUrl, h5Id, version } = res.result

      h5Id === -1 ? this.compose_newAppIframe(item) : this.hasDraftConfirm(item, h5Id, editUrl, version)

    }).catch(err => {

      console.log(err)

    })

},

/**

 * 选择继续编辑？

 */

hasDraftConfirm(item, h5Id, editUrl, version) {

    this.$confirm('有未完成的信息收集链接，是否继续编辑?', '提示', {

      confirmButtonText: '继续编辑',

      cancelButtonText: '重新创建',

      type: 'warning'

    }).then(() => {

      this.compose_editAppIframe(item, h5Id, editUrl)

    }).catch(() => {

      this.compose_reNewAppIframe(item, h5Id, version)

    })

},

敲黑板啦！画重点啦!

/**

* 新建应用流程

* 入参: item

* 输出：item

*/

compose_newAppIframe(...args) {

    const steps = [this.step_getDoclose, this.step_createWs, this.step_splitUrl, this.step_appH5create, this.step_getsingleSignOnToken]

    const handleCompose = composePromise(...steps)

    handleCompose(...args)

},

/**

* 编辑应用流程

* 入参: item, draftH5Id, editUrl

* 输出：item

*/

compose_editAppIframe(...args) {

    const steps = [this.step_getDoclose, this.step_createWs, this.step_splitUrl, this.step_getsingleSignOnToken]

    const handleCompose = composePromise(...steps)

    handleCompose(...args)

},

/**

* 重新创建流程

* 入参: item，draftH5Id，version

* 输出：item

*/

compose_reNewAppIframe(...args) {

    const steps = [this.step_getDoclose, this.step_createWs, this.step_splitUrl, this.step_appH5create, this.step_getsingleSignOnToken, this.step_delDraftH5Id]

    const handleCompose = composePromise(...steps)

    handleCompose(...args)

},

我们通过 composePromise 执行不同的 steps，来依次执行（从右至左）里面的功能函数；你可以任意组合、增删或修改 steps 的子项，也可以任意组合出新的流程来应付产品。并且，它们都被封装在 compose_xxx 里面，相互独立，不会干扰外界其它流程。同时，传参也是非常清晰的，输入是什么！输出又是什么！一目了然！

对照脑图再看此段代码，不正是对我们需求实现的最好诠释吗？

对于一个阅读陌生代码的人来说，你得先告诉他逻辑是怎样的，然后再告诉他每个步骤的内部具体实现。这样才是合理的！

功能函数（具体步骤内部实现）：

/**

* 调用 sso 接口，拿到返回结果 res_token；

*/

step_getsingleSignOnToken(...args) {

    const [item] = args.flat(Infinity)

    return new Promise((resolve, reject) => {

      getsingleSignOnToken({ formSource: item.tag }).then(data => {

        resolve([...args, data.result]) // data.result 即 token

      })

    })

},

/**

*  调用 create 接口，拿到返回结果 res_id；

*/

step_appH5create(...args) {

    const [item, token] = args.flat(Infinity)

    return new Promise((resolve, reject) => {

      appH5create({ appId: item.appId }).then(data => {

        resolve([item, data.result.h5Id, data.result.editUrl, token])

      }).catch(err => {

        this.$message({

          message: err.message || '出现错误',

          type: 'error'

        })

      })

    })

},

/**

* 调 delDraft 删除接口；

*/

step_delDraftH5Id(...args) {

    const [item, h5Id, version] = args.flat(Infinity)

    return new Promise((resolve, reject) => {

      appH5delete({ h5Id: h5Id, version: version }).then(data => {

        resolve(...args)

      })

    })

},

/**

*  处理字符串，拼接 Url；

*/

step_splitUrl(...args) {

    const [item, h5Id, editUrl, token] = args.flat(Infinity)

    const infoId = editUrl.substr(editUrl.indexOf('?') + 1, editUrl.length - editUrl.indexOf('?'))

    const url = editUrl.replace(infoId, `from=a2p&${infoId}`)

    const headList = JSON.parse(JSON.stringify(this.headList))

    headList.forEach(i => {

      if (i.appId === item.appId) { i.srcUrl = `${url}&token=${token}` }

    })

    this.setHeadList(headList)

    this.setH5Id(h5Id)

    this.setShowNavIframe({ appId: item.appId, state: true })

    this.setNavLabel(item.name)

    return [...args]

},

/**

*  建立 websocket 链接；

*/

step_createWs(...args) {

    return new Promise((resolve, reject) => {

      webSocketInit(resolve, reject, ...args) 

})

  },

/**

*  拿到 websocket 后端推送关键字，渲染页面；

*/

step_getDoclose(...args) {

    const [item, h5Id, editUrl, token, doclose] = args.flat(Infinity)

    if (doclose) { this.setShowEditLink({ appId: item.appId, h5Id: h5Id, state: true }) }

    return new Promise((resolve, reject) => {

      resolve(true)

    })

},

功能函数的输入、输出也是清晰可见的。

至此，我们可以认为：借助 compose 函数，借助函数式编程，咱把业务需求流程进行了封装，明确了输入输出，让我们的代码更加可读了！可扩展性也更高了！这不就是高内聚、低耦合？！

阶段总结

你问我什么是 JS 函数式编程实战？我只能说本篇完全就是出自工作中的实战！！！

这样导致本篇代码量可能有点多，但是这就是实打实的需求变化，代码迭代、改造的过程。（建议通篇把握、理解）

当然，这不是终点，代码重构这个过程应该是每时每刻都在进行着。

对于函数式编程，简单应用 compose 函数，这也只是一个起点！

已经讲过，偏函数、函数柯里化、函数组合、数组操作、时间状态、函数式编程库等等概念......我们将再接再厉得使用它们，把代码屎山进行分类、打包、清理！让它不断美丽起来！💩 => 👩‍🦰

以上，便是本次分享~ 都看到这里，不如点个赞吧👍👍👍

1. JS事件冒泡和事件代理（委托）

1. 事件冒泡

会从当前触发的事件目标一级一级往上传递，依次触发，直到document为止。

<body>    <div id="parentId"> 查看消息信息 <div id="childId1"> 删除消息信息 </div>    </div></body><script>    let parent = document.getElementById('parentId');    let childId1 = document.getElementById('childId1');    parent.addEventListener('click', function () {        alert('查看消息信息');    }, false);    childId1.addEventListener('click', function () {        alert('删除消息信息');    }, false);     // 如出发消息列表里的删除按钮， 先执行了删除操作， 在向上冒泡执行‘ 查看消息信息’。        // 打印：删除消息信息 查看消息信息</script>

原生js取消事件冒泡

   try{

      e.stopPropagation();//非IE浏览器

    }

    catch(e){

        window.event.cancelBubble = true;//IE浏览器

    }    

vue.js取消事件冒泡

<div @click.stop="doSomething($event)">vue取消事件冒泡</div>

2. 事件代理（委托）

a. 为什么要用事件委托：

比如ul下有100个li，用for循环遍历所有的li，然后给它们添加事件，需要不断的与dom节点进行交互，访问dom的次数越多，引起浏览器重绘与重排的次数也就越多，就会延长整个页面的交互就绪时间，这就是为什么性能优化的主要思想之一就是减少DOM操作的原因；

如果要用事件委托，就会将所有的操作放到js程序里面，与dom的操作就只需要交互一次，这样就能大大的减少与dom的交互次数，提高性能；

b. 事件委托的原理

事件委托：利用事件冒泡的特性，将本应该注册在子元素上的处理事件注册在父元素上，这样点击子元素时发现其本身没有相应事件就到父元素上寻找作出相应。这样做的优势有：

1、减少DOM操作，提高性能。

2、随时可以添加子元素，添加的子元素会自动有相应的处理事件。

<div id="box">

        <input type="button" id="add" value="添加" />

        <input type="button" id="remove" value="删除" />

        <input type="button" id="move" value="移动" />

        <input type="button" id="select" value="选择" />

 </div>  

方式一：需要4次dom操作

    window.onload = function () {        

var Add = document.getElementById("add");        

var Remove = document.getElementById("remove");        

var Move = document.getElementById("move");        

var Select = document.getElementById("select");        

Add.onclick = function () {            alert('添加');        };        Remove.onclick = function () {            alert('删除');        };        Move.onclick = function () {            alert('移动');        };        Select.onclick = function () {            alert('选择');        }    }

方式二：委托它们父级代为执行事件

window.onload = function(){

            var oBox = document.getElementById("box");

            oBox.onclick = function (ev) {

                var ev = ev || window.event;

                var target = ev.target || ev.srcElement;

                if(target.nodeName.toLocaleLowerCase() == 'input'){

                    switch(target.id){

                        case 'add' :

                            alert('添加');

                            break;

                        case 'remove' :

                            alert('删除');

                            break;

                        case 'move' :

                            alert('移动');

                            break;

                        case 'select' :

                            alert('选择');

                            break;

                    }

                }

            }

            

}

用事件委托就可以只用一次dom操作就能完成所有的效果，比上面的性能肯定是要好一些的 

3. 事件捕获

会从document开始触发，一级一级往下传递，依次触发，直到真正事件目标为止。

    <div> <button>            <p>点击捕获</p>        </button></div>    <script>        var oP = document.querySelector('p');        var oB = document.querySelector('button');        var oD = document.querySelector('div');        var oBody = document.querySelector('body');        oP.addEventListener('click', function () {            console.log('p标签被点击')        }, true);        oB.addEventListener('click', function () {            console.log("button被点击")        }, true);        oD.addEventListener('click', function () {            console.log('div被点击')        }, true);        oBody.addEventListener('click', function () {            console.log('body被点击')        }, true);    </script>    点击<p>点击捕获</p>，打印的顺序是：body=>div=>button=>p</body>

流程：先捕获，然后处理，然后再冒泡出去。

2. 原型链

1. 原型对象诞生原因和本质

为了解决无法共享公共属性的问题，所以要设计一个对象专门用来存储对象共享的属性，那么我们叫它「原型对象」

原理：构造函数加一个属性叫做prototype，用来指向原型对象，我们把所有实例对象共享的属性和方法都放在这个构造函数的prototype属性指向的原型对象中，不需要共享的属性和方法放在构造函数中。实现构造函数生成的所有实例对象都能够共享属性。

构造函数：私有属性

原型对象：共有属性

2.  彼此之间的关系

构造函数中一属性prototype：指向原型对象，而原型对象一constructor属性，又指回了构造函数。



每个构造函数生成的实例对象都有一个proto属性，这个属性指向原型对象。

那原型对象的_proto_属性指向谁？-> null

3. 原型链是什么？

顾名思义，肯定是一条链，既然每个对象都有一个_proto_属性指向原型对象，那么原型对象也有_proto_指向原型对象的原型对象，直到指向上图中的null，这才到达原型链的顶端。

4. 原型链和继承使用场景

原型链主要用于继承，实现代码复用。因为js算不上是面向对象的语言，继承是基于原型实现而不是基于类实现的，

a. 判断函数的原型是否在对象的原型链上

对象 instanceof 函数（不推荐使用）

b. 创建一个新对象，该新对象的隐式原型指向指定的对象

Object.create(对象)

var obj = Object.create(Object.prototype);

obj.__proto__ === Object.prototype

c. new的实现

d. es6的class A extends B 

因为es6-没有类和继承的概念。js实现继承本质是把js中的对象构造函数在自己的脑中抽象成一个类，然后使用构造函数的protptype属性封装出一个类（另一个构造函数），使之完美继承前一构造函数的所有属性和方法。因为构造函数能new出一个具体的对象实例，这就在js中实现了现代化的面向对象和继承。

3. 闭包和垃圾回收机制

闭包的概念

　　function f1(){　　　　var n=999;　　　　function f2(){　　　　　　alert(n);　　　　}　　　　return f2;　　}　　var result=f1();　　result(); // 999

在上面的代码中，函数f2就被包括在函数f1内部，这时f1内部的所有局部变量，对f2都是可见的。但是反过来就不行，f2内部的局部变量，对f1就是不可见的。这就是Javascript语言特有的"链式作用域"结构（chain scope），子对象会一级一级地向上寻找所有父对象的变量。所以，父对象的所有变量，对子对象都是可见的，反之则不成立。

既然f2可以读取f1中的局部变量，那么只要把f2作为返回值，我们不就可以在f1外部读取它的内部变量了吗！

作用：一是前面提到的可以读取函数内部的变量，二是让这些变量的值始终保持在内存中，主要用来封装私有变量, 提供一些暴露的接口

垃圾回收

**垃圾回收机制：JavaScript 引擎中有一个后台进程称为垃圾回收器，它监视所有对象，并删除那些不可访问的对象

**

**注意点：**对于内存的管理，Javascript与C语言等底层语言JavaScript是在创建变量（对象，字符串等）时自动进行了分配内存，并且在不使用它们时“自动”释放。 释放的过程称为垃圾回收。这个“自动”是混乱的根源，并让JavaScript（和其他高级语言）开发者错误的感觉他们可以不关心内存管理，

实现的原理：由于 f2 中引用了 相对于自己的全局变量 n ，所以 f2 会一直存在内存中，又因为 n 是 f1 中的局部变量，也就是说 f2 依赖 f1，所以说 f1 也会一直存在内存中，并不像普通函数那样，调用后变量便被垃圾回收了。

所以说，在setTimeout中的函数引用了外层 for循环的变量 i，导致 i 一直存在内存中，不被回收，所以等到JS队列执行 函数时，i 已经是 10了，所以最终打印 10个10。

五、使用闭包的注意点

1）由于闭包会使得函数中的变量都被保存在内存中，内存消耗很大，所以不能滥用闭包，否则会造成网页的性能问题，在IE中可能导致内存泄露。解决方法是，在退出函数之前，将不使用的局部变量全部删除。

for (var i=1; i<=5; i++) {

    setTimeout( function timer() {

        console.log( i );

     }, i*1000 );

}

打印：5个6，原因js事件执行机制

办法一：

for (var i=1; i<=5; i++) {

    (function(j) {

        setTimeout( function timer() {

            console.log( j );

        }, j*1000 );

    })(i);

}

打印：依次输出1到5

原因：因为实际参数跟定时器内部的i有强依赖。通过闭包，将i的变量驻留在内存中，当输出j时，

引用的是外部函数的变量值i，i的值是根据循环来的，执行setTimeout时已经确定了里面的的输出了。办法二：

for (let i=1; i<=5; i++) {

    setTimeout( function timer() {

        console.log( i );

     }, i*1000 );

}

打印：依次输出1到5因为for循环头部的let不仅将i绑定到for循环中，事实上它将其重新绑定到循环体的每一次迭代中，

确保上一次迭代结束的值重新被赋值。

setTimeout里面的function()属于一个新的域，

通过var定义的变量是无法传入到这个函数执行域中的，

通过使用let来声明块变量能作用于这个块，所以function就能使用i这个变量了；

这个匿名函数的参数作用域和for参数的作用域不一样，是利用了这一点来完成的。

这个匿名函数的作用域有点类似类的属性，是可以被内层方法使用的。

4. js事件执行机制

事件循环的过程如下：

1. JS引擎（唯一主线程）按顺序解析代码，遇到函数声明，直接跳过，遇到函数调用，入栈；


2. 如果是同步函数调用，直接执行得到结果，同步函数弹出栈，继续下一个函数调用；


3. 如果是异步函数调用，分发给Web API（多个辅助线程），异步函数弹出栈，继续下一个函数调用；


4. Web API中，异步函数在相应辅助线程中处理完成后，即异步函数达到触发条件了（比如setTimeout设置的10s后），如果异步函数是宏任务，则入宏任务消息队列，如果是微任务，则入微任务消息队列；


5. Event Loop不停地检查主线程的调用栈与回调队列，当调用栈空时，就把微任务消息队列中的第一个任务推入栈中执行，执行完成后，再取第二个微任务，直到微任务消息队列为空；然后
   
   去宏任务消息队列中取第一个宏任务推入栈中执行，当该宏任务执行完成后，在下一个宏任务执行前，再依次取出微任务消息队列中的所有微任务入栈执行。


6. 上述过程不断循环，每当微任务队列清空，可作为本轮事件循环的结束。

一、CDN

1. CDN的概念

CDN（Content Delivery Network，内容分发网络）是指一种通过互联网互相连接的电脑网络系统，利用最靠近每位用户的服务器，更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户，来提供高性能、可扩展性及低成本的网络内容传递给用户。

典型的CDN系统由下面三个部分组成：

• 分发服务系统： 最基本的工作单元就是Cache设备，cache（边缘cache）负责直接响应最终用户的访问请求，把缓存在本地的内容快速地提供给用户。同时cache还负责与源站点进行内容同步，把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache设备的数量、规模、总服务能力是衡量一个CDN系统服务能力的最基本的指标。


• 负载均衡系统： 主要功能是负责对所有发起服务请求的用户进行访问调度，确定提供给用户的最终实际访问地址。两级调度体系分为全局负载均衡（GSLB）和本地负载均衡（SLB）。全局负载均衡主要根据用户就近性原则，通过对每个服务节点进行“最优”判断，确定向用户提供服务的cache的物理位置。本地负载均衡主要负责节点内部的设备负载均衡


• **运营管理系统：**运营管理系统分为运营管理和网络管理子系统，负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作，包含客户管理、产品管理、计费管理、统计分析等功能。

2. CDN的作用

CDN一般会用来托管Web资源（包括文本、图片和脚本等），可供下载的资源（媒体文件、软件、文档等），应用程序（门户网站等）。使用CDN来加速这些资源的访问。

（1）在性能方面，引入CDN的作用在于：

• 用户收到的内容来自最近的数据中心，延迟更低，内容加载更快


• 部分资源请求分配给了CDN，减少了服务器的负载

（2）在安全方面，CDN有助于防御DDoS、MITM等网络攻击：

• 针对DDoS：通过监控分析异常流量，限制其请求频率


• 针对MITM：从源服务器到 CDN 节点到 ISP（Internet Service Provider），全链路 HTTPS 通信

除此之外，CDN作为一种基础的云服务，同样具有资源托管、按需扩展（能够应对流量高峰）等方面的优势。

3. CDN的原理

CDN和DNS有着密不可分的联系，先来看一下DNS的解析域名过程，在浏览器输入 http://www.test.com 的解析过程如下：

（1） 检查浏览器缓存

（2）检查操作系统缓存，常见的如hosts文件

（3）检查路由器缓存

（4）如果前几步都没没找到，会向ISP(网络服务提供商)的LDNS服务器查询

（5）如果LDNS服务器没找到，会向根域名服务器(Root Server)请求解析，分为以下几步：

• 根服务器返回顶级域名(TLD)服务器如.com，.cn，.org等的地址，该例子中会返回.com的地址


• 接着向顶级域名服务器发送请求，然后会返回次级域名(SLD)服务器的地址，本例子会返回.test的地址


• 接着向次级域名服务器发送请求，然后会返回通过域名查询到的目标IP，本例子会返回http://www.test.com的地址


• Local DNS Server会缓存结果，并返回给用户，缓存在系统中

CDN的工作原理：

（1）用户未使用CDN缓存资源的过程：

1. 浏览器通过DNS对域名进行解析（就是上面的DNS解析过程），依次得到此域名对应的IP地址


2. 浏览器根据得到的IP地址，向域名的服务主机发送数据请求


3. 服务器向浏览器返回响应数据

（2）用户使用CDN缓存资源的过程：

1. 对于点击的数据的URL，经过本地DNS系统的解析，发现该URL对应的是一个CDN专用的DNS服务器，DNS系统就会将域名解析权交给CNAME指向的CDN专用的DNS服务器。


2. CND专用DNS服务器将CND的全局负载均衡设备IP地址返回给用户


3. 用户向CDN的全局负载均衡设备发起数据请求


4. CDN的全局负载均衡设备根据用户的IP地址，以及用户请求的内容URL，选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求


5. 区域负载均衡设备选择一台合适的缓存服务器来提供服务，将该缓存服务器的IP地址返回给全局负载均衡设备


6. 全局负载均衡设备把服务器的IP地址返回给用户


7. 用户向该缓存服务器发起请求，缓存服务器响应用户的请求，将用户所需内容发送至用户终端。

如果缓存服务器没有用户想要的内容，那么缓存服务器就会向它的上一级缓存服务器请求内容，以此类推，直到获取到需要的资源。最后如果还是没有，就会回到自己的服务器去获取资源。

CNAME（意为：别名）：在域名解析中，实际上解析出来的指定域名对应的IP地址，或者该域名的一个CNAME，然后再根据这个CNAME来查找对应的IP地址。

4. CDN的使用场景

• **使用第三方的CDN服务：**如果想要开源一些项目，可以使用第三方的CDN服务


• **使用CDN进行静态资源的缓存：**将自己网站的静态资源放在CDN上，比如js、css、图片等。可以将整个项目放在CDN上，完成一键部署。


• **直播传送：**直播本质上是使用流媒体进行传送，CDN也是支持流媒体传送的，所以直播完全可以使用CDN来提高访问速度。CDN在处理流媒体的时候与处理普通静态文件有所不同，普通文件如果在边缘节点没有找到的话，就会去上一层接着寻找，但是流媒体本身数据量就非常大，如果使用回源的方式，必然会带来性能问题，所以流媒体一般采用的都是主动推送的方式来进行。

二、懒加载

1. 懒加载的概念

懒加载也叫做延迟加载、按需加载，指的是在长网页中延迟加载图片数据，是一种较好的网页性能优化的方式。在比较长的网页或应用中，如果图片很多，所有的图片都被加载出来，而用户只能看到可视窗口的那一部分图片数据，这样就浪费了性能。

如果使用图片的懒加载就可以解决以上问题。在滚动屏幕之前，可视化区域之外的图片不会进行加载，在滚动屏幕时才加载。这样使得网页的加载速度更快，减少了服务器的负载。懒加载适用于图片较多，页面列表较长（长列表）的场景中。

2. 懒加载的特点

• 减少无用资源的加载：使用懒加载明显减少了服务器的压力和流量，同时也减小了浏览器的负担。


• 提升用户体验: 如果同时加载较多图片，可能需要等待的时间较长，这样影响了用户体验，而使用懒加载就能大大的提高用户体验。


• 防止加载过多图片而影响其他资源文件的加载 ：会影响网站应用的正常使用。

3. 懒加载的实现原理

图片的加载是由src引起的，当对src赋值时，浏览器就会请求图片资源。根据这个原理，我们使用HTML5 的data-xxx属性来储存图片的路径，在需要加载图片的时候，将data-xxx中图片的路径赋值给src，这样就实现了图片的按需加载，即懒加载。

注意：data-xxx 中的xxx可以自定义，这里我们使用data-src来定义。

懒加载的实现重点在于确定用户需要加载哪张图片，在浏览器中，可视区域内的资源就是用户需要的资源。所以当图片出现在可视区域时，获取图片的真实地址并赋值给图片即可。

使用原生JavaScript实现懒加载：

知识点：

（1）window.innerHeight 是浏览器可视区的高度

（2）document.body.scrollTop || document.documentElement.scrollTop 是浏览器滚动的过的距离

（3）imgs.offsetTop 是元素顶部距离文档顶部的高度（包括滚动条的距离）

（4）图片加载条件：img.offsetTop < window.innerHeight + document.body.scrollTop;

图示：

代码实现：

<div>

     <img src="loading.gif"  data-src="pic.png">

     <img src="loading.gif"  data-src="pic.png">

     <img src="loading.gif"  data-src="pic.png">

     <img src="loading.gif"  data-src="pic.png">

     <img src="loading.gif"  data-src="pic.png">

     <img src="loading.gif"  data-src="pic.png">

</div>

<script>

var imgs = document.querySelectorAll('img');

function lozyLoad(){

        var scrollTop = document.body.scrollTop || document.documentElement.scrollTop;

        var winHeight= window.innerHeight;

        for(var i=0;i < imgs.length;i++){

            if(imgs[i].offsetTop < scrollTop + winHeight ){

                imgs[i].src = imgs[i].getAttribute('data-src');

            }

        }

    }

  window.onscroll = lozyLoad;

</script>

4. 懒加载与预加载的区别

这两种方式都是提高网页性能的方式，两者主要区别是一个是提前加载，一个是迟缓甚至不加载。懒加载对服务器前端有一定的缓解压力作用，预加载则会增加服务器前端压力。

• 懒加载也叫延迟加载，指的是在长网页中延迟加载图片的时机，当用户需要访问时，再去加载，这样可以提高网站的首屏加载速度，提升用户的体验，并且可以减少服务器的压力。它适用于图片很多，页面很长的电商网站的场景。懒加载的实现原理是，将页面上的图片的 src 属性设置为空字符串，将图片的真实路径保存在一个自定义属性中，当页面滚动的时候，进行判断，如果图片进入页面可视区域内，则从自定义属性中取出真实路径赋值给图片的 src 属性，以此来实现图片的延迟加载。


• 预加载指的是将所需的资源提前请求加载到本地，这样后面在需要用到时就直接从缓存取资源。 通过预加载能够减少用户的等待时间，提高用户的体验。我了解的预加载的最常用的方式是使用 js 中的 image 对象，通过为 image 对象来设置 scr 属性，来实现图片的预加载。

三、回流与重绘

1. 回流与重绘的概念及触发条件

（1）回流

当渲染树中部分或者全部元素的尺寸、结构或者属性发生变化时，浏览器会重新渲染部分或者全部文档的过程就称为回流。

下面这些操作会导致回流：

• 页面的首次渲染


• 浏览器的窗口大小发生变化


• 元素的内容发生变化


• 元素的尺寸或者位置发生变化


• 元素的字体大小发生变化


• 激活CSS伪类


• 查询某些属性或者调用某些方法


• 添加或者删除可见的DOM元素

在触发回流（重排）的时候，由于浏览器渲染页面是基于流式布局的，所以当触发回流时，会导致周围的DOM元素重新排列，它的影响范围有两种：

• 全局范围：从根节点开始，对整个渲染树进行重新布局


• 局部范围：对渲染树的某部分或者一个渲染对象进行重新布局

（2）重绘

当页面中某些元素的样式发生变化，但是不会影响其在文档流中的位置时，浏览器就会对元素进行重新绘制，这个过程就是重绘。

下面这些操作会导致回流：

• color、background 相关属性：background-color、background-image 等


• outline 相关属性：outline-color、outline-width 、text-decoration


• border-radius、visibility、box-shadow

注意： 当触发回流时，一定会触发重绘，但是重绘不一定会引发回流。

2. 如何避免回流与重绘？

减少回流与重绘的措施：

• 操作DOM时，尽量在低层级的DOM节点进行操作


• 不要使用table布局， 一个小的改动可能会使整个table进行重新布局


• 使用CSS的表达式


• 不要频繁操作元素的样式，对于静态页面，可以修改类名，而不是样式。


• 使用absolute或者fixed，使元素脱离文档流，这样他们发生变化就不会影响其他元素


• 避免频繁操作DOM，可以创建一个文档片段documentFragment，在它上面应用所有DOM操作，最后再把它添加到文档中


• 将元素先设置display: none，操作结束后再把它显示出来。因为在display属性为none的元素上进行的DOM操作不会引发回流和重绘。


• 将DOM的多个读操作（或者写操作）放在一起，而不是读写操作穿插着写。这得益于浏览器的渲染队列机制。

浏览器针对页面的回流与重绘，进行了自身的优化——渲染队列

浏览器会将所有的回流、重绘的操作放在一个队列中，当队列中的操作到了一定的数量或者到了一定的时间间隔，浏览器就会对队列进行批处理。这样就会让多次的回流、重绘变成一次回流重绘。

上面，将多个读操作（或者写操作）放在一起，就会等所有的读操作进入队列之后执行，这样，原本应该是触发多次回流，变成了只触发一次回流。

3. 如何优化动画？

对于如何优化动画，我们知道，一般情况下，动画需要频繁的操作DOM，就就会导致页面的性能问题，我们可以将动画的position属性设置为absolute或者fixed，将动画脱离文档流，这样他的回流就不会影响到页面了。

4. documentFragment 是什么？用它跟直接操作 DOM 的区别是什么？

MDN中对documentFragment的解释：

DocumentFragment，文档片段接口，一个没有父对象的最小文档对象。它被作为一个轻量版的 Document使用，就像标准的document一样，存储由节点（nodes）组成的文档结构。与document相比，最大的区别是DocumentFragment不是真实 DOM 树的一部分，它的变化不会触发 DOM 树的重新渲染，且不会导致性能等问题。

当我们把一个 DocumentFragment 节点插入文档树时，插入的不是 DocumentFragment 自身，而是它的所有子孙节点。在频繁的DOM操作时，我们就可以将DOM元素插入DocumentFragment，之后一次性的将所有的子孙节点插入文档中。和直接操作DOM相比，将DocumentFragment 节点插入DOM树时，不会触发页面的重绘，这样就大大提高了页面的性能。

四、节流与防抖

1. 对节流与防抖的理解

• 函数防抖是指在事件被触发 n 秒后再执行回调，如果在这 n 秒内事件又被触发，则重新计时。这可以使用在一些点击请求的事件上，避免因为用户的多次点击向后端发送多次请求。


• 函数节流是指规定一个单位时间，在这个单位时间内，只能有一次触发事件的回调函数执行，如果在同一个单位时间内某事件被触发多次，只有一次能生效。节流可以使用在 scroll 函数的事件监听上，通过事件节流来降低事件调用的频率。

防抖函数的应用场景：

• 按钮提交场景：防⽌多次提交按钮，只执⾏最后提交的⼀次


• 服务端验证场景：表单验证需要服务端配合，只执⾏⼀段连续的输⼊事件的最后⼀次，还有搜索联想词功能类似⽣存环境请⽤lodash.debounce

节流函数的****适⽤场景：

• 拖拽场景：固定时间内只执⾏⼀次，防⽌超⾼频次触发位置变动


• 缩放场景：监控浏览器resize


• 动画场景：避免短时间内多次触发动画引起性能问题

2. 实现节流函数和防抖函数

函数防抖的实现：

function debounce(fn, wait) {

  var timer = null;



  return function() {

    var context = this,

      args = [...arguments];



    // 如果此时存在定时器的话，则取消之前的定时器重新记时

    if (timer) {

      clearTimeout(timer);

      timer = null;

    }



    // 设置定时器，使事件间隔指定事件后执行

    timer = setTimeout(() => {

      fn.apply(context, args);

    }, wait);

  };

}

函数节流的实现：

// 时间戳版

function throttle(fn, delay) {

  var preTime = Date.now();



  return function() {

    var context = this,

      args = [...arguments],

      nowTime = Date.now();



    // 如果两次时间间隔超过了指定时间，则执行函数。

    if (nowTime - preTime >= delay) {

      preTime = Date.now();

      return fn.apply(context, args);

    }

  };

}



// 定时器版

function throttle (fun, wait){

  let timeout = null

  return function(){

    let context = this

    let args = [...arguments]

    if(!timeout){

      timeout = setTimeout(() => {

        fun.apply(context, args)

        timeout = null 

      }, wait)

    }

  }

}

五、图片优化

1. 如何对项目中的图片进行优化？

1. 不用图片。很多时候会使用到很多修饰类图片，其实这类修饰图片完全可以用 CSS 去代替。


2. 对于移动端来说，屏幕宽度就那么点，完全没有必要去加载原图浪费带宽。一般图片都用 CDN 加载，可以计算出适配屏幕的宽度，然后去请求相应裁剪好的图片。


3. 小图使用 base64 格式


4. 将多个图标文件整合到一张图片中（雪碧图）


5. 选择正确的图片格式：

• 
  
  
  
  • 对于能够显示 WebP 格式的浏览器尽量使用 WebP 格式。因为 WebP 格式具有更好的图像数据压缩算法，能带来更小的图片体积，而且拥有肉眼识别无差异的图像质量，缺点就是兼容性并不好
  
  
  • 小图使用 PNG，其实对于大部分图标这类图片，完全可以使用 SVG 代替
  
  
  • 照片使用 JPEG
  
  
  
  

2. 常见的图片格式及使用场景

（1）BMP，是无损的、既支持索引色也支持直接色的点阵图。这种图片格式几乎没有对数据进行压缩，所以BMP格式的图片通常是较大的文件。

（2）GIF是无损的、采用索引色的点阵图。采用LZW压缩算法进行编码。文件小，是GIF格式的优点，同时，GIF格式还具有支持动画以及透明的优点。但是GIF格式仅支持8bit的索引色，所以GIF格式适用于对色彩要求不高同时需要文件体积较小的场景。

（3）JPEG是有损的、采用直接色的点阵图。JPEG的图片的优点是采用了直接色，得益于更丰富的色彩，JPEG非常适合用来存储照片，与GIF相比，JPEG不适合用来存储企业Logo、线框类的图。因为有损压缩会导致图片模糊，而直接色的选用，又会导致图片文件较GIF更大。

（4）PNG-8是无损的、使用索引色的点阵图。PNG是一种比较新的图片格式，PNG-8是非常好的GIF格式替代者，在可能的情况下，应该尽可能的使用PNG-8而不是GIF，因为在相同的图片效果下，PNG-8具有更小的文件体积。除此之外，PNG-8还支持透明度的调节，而GIF并不支持。除非需要动画的支持，否则没有理由使用GIF而不是PNG-8。

（5）PNG-24是无损的、使用直接色的点阵图。PNG-24的优点在于它压缩了图片的数据，使得同样效果的图片，PNG-24格式的文件大小要比BMP小得多。当然，PNG24的图片还是要比JPEG、GIF、PNG-8大得多。

（6）SVG是无损的矢量图。SVG是矢量图意味着SVG图片由直线和曲线以及绘制它们的方法组成。当放大SVG图片时，看到的还是线和曲线，而不会出现像素点。这意味着SVG图片在放大时，不会失真，所以它非常适合用来绘制Logo、Icon等。

（7）WebP是谷歌开发的一种新图片格式，WebP是同时支持有损和无损压缩的、使用直接色的点阵图。从名字就可以看出来它是为Web而生的，什么叫为Web而生呢？就是说相同质量的图片，WebP具有更小的文件体积。现在网站上充满了大量的图片，如果能够降低每一个图片的文件大小，那么将大大减少浏览器和服务器之间的数据传输量，进而降低访问延迟，提升访问体验。目前只有Chrome浏览器和Opera浏览器支持WebP格式，兼容性不太好。

• 在无损压缩的情况下，相同质量的WebP图片，文件大小要比PNG小26%；


• 在有损压缩的情况下，具有相同图片精度的WebP图片，文件大小要比JPEG小25%~34%；


• WebP图片格式支持图片透明度，一个无损压缩的WebP图片，如果要支持透明度只需要22%的格外文件大小。

六、Webpack优化

1. 如何提⾼webpack的打包速度**?**

（1）优化 Loader

对于 Loader 来说，影响打包效率首当其冲必属 Babel 了。因为 Babel 会将代码转为字符串生成 AST，然后对 AST 继续进行转变最后再生成新的代码，项目越大，转换代码越多，效率就越低。当然了，这是可以优化的。

首先我们优化 Loader 的文件搜索范围

module.exports = {

  module: {

    rules: [

      {

        // js 文件才使用 babel

        test: /\.js$/,

        loader: 'babel-loader',

        // 只在 src 文件夹下查找

        include: [resolve('src')],

        // 不会去查找的路径

        exclude: /node_modules/

      }

    ]

  }

}

对于 Babel 来说，希望只作用在 JS 代码上的，然后 node_modules 中使用的代码都是编译过的，所以完全没有必要再去处理一遍。

当然这样做还不够，还可以将 Babel 编译过的文件缓存起来，下次只需要编译更改过的代码文件即可，这样可以大幅度加快打包时间

loader: 'babel-loader?cacheDirectory=true'

（2）HappyPack

受限于 Node 是单线程运行的，所以 Webpack 在打包的过程中也是单线程的，特别是在执行 Loader 的时候，长时间编译的任务很多，这样就会导致等待的情况。

HappyPack 可以将 Loader 的同步执行转换为并行的，这样就能充分利用系统资源来加快打包效率了

module: {

  loaders: [

    {

      test: /\.js$/,

      include: [resolve('src')],

      exclude: /node_modules/,

      // id 后面的内容对应下面

      loader: 'happypack/loader?id=happybabel'

    }

  ]

},

plugins: [

  new HappyPack({

    id: 'happybabel',

    loaders: ['babel-loader?cacheDirectory'],

    // 开启 4 个线程

    threads: 4

  })

]

（3）DllPlugin

DllPlugin 可以将特定的类库提前打包然后引入。这种方式可以极大的减少打包类库的次数，只有当类库更新版本才有需要重新打包，并且也实现了将公共代码抽离成单独文件的优化方案。DllPlugin的使用方法如下：

// 单独配置在一个文件中

// webpack.dll.conf.js

const path = require('path')

const webpack = require('webpack')

module.exports = {

  entry: {

    // 想统一打包的类库

    vendor: ['react']

  },

  output: {

    path: path.join(__dirname, 'dist'),

    filename: '[name].dll.js',

    library: '[name]-[hash]'

  },

  plugins: [

    new webpack.DllPlugin({

      // name 必须和 output.library 一致

      name: '[name]-[hash]',

      // 该属性需要与 DllReferencePlugin 中一致

      context: __dirname,

      path: path.join(__dirname, 'dist', '[name]-manifest.json')

    })

  ]

}

然后需要执行这个配置文件生成依赖文件，接下来需要使用 DllReferencePlugin 将依赖文件引入项目中

// webpack.conf.js

module.exports = {

  // ...省略其他配置

  plugins: [

    new webpack.DllReferencePlugin({

      context: __dirname,

      // manifest 就是之前打包出来的 json 文件

      manifest: require('./dist/vendor-manifest.json'),

    })

  ]

}

（4）代码压缩

在 Webpack3 中，一般使用 UglifyJS 来压缩代码，但是这个是单线程运行的，为了加快效率，可以使用 webpack-parallel-uglify-plugin 来并行运行 UglifyJS，从而提高效率。

在 Webpack4 中，不需要以上这些操作了，只需要将 mode 设置为 production 就可以默认开启以上功能。代码压缩也是我们必做的性能优化方案，当然我们不止可以压缩 JS 代码，还可以压缩 HTML、CSS 代码，并且在压缩 JS 代码的过程中，我们还可以通过配置实现比如删除 console.log 这类代码的功能。

（5）其他

可以通过一些小的优化点来加快打包速度

• resolve.extensions：用来表明文件后缀列表，默认查找顺序是 ['.js', '.json']，如果你的导入文件没有添加后缀就会按照这个顺序查找文件。我们应该尽可能减少后缀列表长度，然后将出现频率高的后缀排在前面


• resolve.alias：可以通过别名的方式来映射一个路径，能让 Webpack 更快找到路径


• module.noParse：如果你确定一个文件下没有其他依赖，就可以使用该属性让 Webpack 不扫描该文件，这种方式对于大型的类库很有帮助

2. 如何减少 Webpack 打包体积

（1）按需加载

在开发 SPA 项目的时候，项目中都会存在很多路由页面。如果将这些页面全部打包进一个 JS 文件的话，虽然将多个请求合并了，但是同样也加载了很多并不需要的代码，耗费了更长的时间。那么为了首页能更快地呈现给用户，希望首页能加载的文件体积越小越好，这时候就可以使用按需加载，将每个路由页面单独打包为一个文件。当然不仅仅路由可以按需加载，对于 loadash 这种大型类库同样可以使用这个功能。

按需加载的代码实现这里就不详细展开了，因为鉴于用的框架不同，实现起来都是不一样的。当然了，虽然他们的用法可能不同，但是底层的机制都是一样的。都是当使用的时候再去下载对应文件，返回一个 Promise，当 Promise 成功以后去执行回调。

（2）Scope Hoisting

Scope Hoisting 会分析出模块之间的依赖关系，尽可能的把打包出来的模块合并到一个函数中去。

比如希望打包两个文件：

// test.js

export const a = 1

// index.js

import { a } from './test.js'

对于这种情况，打包出来的代码会类似这样：

[

  /* 0 */

  function (module, exports, require) {

    //...

  },

  /* 1 */

  function (module, exports, require) {

    //...

  }

]

但是如果使用 Scope Hoisting ，代码就会尽可能的合并到一个函数中去，也就变成了这样的类似代码：

[

  /* 0 */

  function (module, exports, require) {

    //...

  }

]

这样的打包方式生成的代码明显比之前的少多了。如果在 Webpack4 中你希望开启这个功能，只需要启用 optimization.concatenateModules 就可以了：

module.exports = {

  optimization: {

    concatenateModules: true

  }

}

（3）Tree Shaking

Tree Shaking 可以实现删除项目中未被引用的代码，比如：

// test.js

export const a = 1

export const b = 2

// index.js

import { a } from './test.js'

对于以上情况，test 文件中的变量 b 如果没有在项目中使用到的话，就不会被打包到文件中。

如果使用 Webpack 4 的话，开启生产环境就会自动启动这个优化功能。

3. 如何⽤webpack来优化前端性能？

⽤webpack优化前端性能是指优化webpack的输出结果，让打包的最终结果在浏览器运⾏快速⾼效。

• 压缩代码：删除多余的代码、注释、简化代码的写法等等⽅式。可以利⽤webpack的 UglifyJsPlugin 和 ParallelUglifyPlugin 来压缩JS⽂件， 利⽤ cssnano （css-loader?minimize）来压缩css


• 利⽤CDN加速: 在构建过程中，将引⽤的静态资源路径修改为CDN上对应的路径。可以利⽤webpack对于 output 参数和各loader的 publicPath 参数来修改资源路径


• Tree Shaking: 将代码中永远不会⾛到的⽚段删除掉。可以通过在启动webpack时追加参数 --optimize-minimize 来实现


• Code Splitting: 将代码按路由维度或者组件分块(chunk),这样做到按需加载,同时可以充分利⽤浏览器缓存


• 提取公共第三⽅库: SplitChunksPlugin插件来进⾏公共模块抽取,利⽤浏览器缓存可以⻓期缓存这些⽆需频繁变动的公共代码

4. 如何提⾼webpack的构建速度？

1. 多⼊⼝情况下，使⽤ CommonsChunkPlugin 来提取公共代码


2. 通过 externals 配置来提取常⽤库


3. 利⽤ DllPlugin 和 DllReferencePlugin 预编译资源模块 通过 DllPlugin 来对那些我们引⽤但是绝对不会修改的npm包来进⾏预编译，再通过 DllReferencePlugin 将预编译的模块加载进来。


4. 使⽤ Happypack 实现多线程加速编译


5. 使⽤ webpack-uglify-parallel 来提升 uglifyPlugin 的压缩速度。 原理上 webpack-uglify-parallel 采⽤了多核并⾏压缩来提升压缩速度


6. 使⽤ Tree-shaking 和 Scope Hoisting 来剔除多余代码

问题

在本地用代理请求服务端接口，解决跨域问题后，发生了一件极其诡异的事情，明明登录成功了，但是请求每个接口都返回未登录的报错信息。

原因

该套系统是采用会话cookie进行登录用户的身份认证，故查看每个请求的Request Headers中的cookie的值，发现原本如下图中的红框区域的SESSION不见了。

而明明登录接口的Response Headers中是存在set-cookie。

set-cookie会是把其值中的SESSION存储到浏览器的cookie中，存储成功后，每次请求服务端时，都会去浏览器中的cookie中读取SESSION，然后通过Request Headers中的cookie传递到服务端，完成身份认证。

另外set-cookie的值是服务端设置的，我们来认真观察一下set-cookie的值

SESSION=NjE1MTNmZWI1N2ExNDYyZGE4MWE0YmZjNjgwMmFmZGY=; Path=/api/operation/; HttpOnly; SameSite=Lax

复制代码

里面除SESSION，还有Path、HttpOnly、SameSite，而Path就是导致SESSION无法存储到客户端中的元凶，其中Path的值/api/operation/表示该cookie只有在用请求路径的前缀为/api/operation/才能使用。

回到代理配置中一看，

proxy: getProxy({

  '/dev': { 

    target: 'https://xxx.xxx.com',

    pathRewrite: { '^/dev': '/api' },

    secure: false,

    changeOrigin: true

  }

}),

复制代码

代理后，请求服务端的地址为xxx.xxx.com/dev/operati… ，其路径为 dev/operation/xxx，自然与/api/operation/不匹配，导致该cookie无法使用，自然无法将SESSION保存到浏览器的cookie中。

解决

找到原因了，问题很好解决，只要更改一下代理配置。

proxy: getProxy({

  '/api': { 

    target: 'https://xxx.xxx.com',

    pathRewrite: { '^/api': '/api' },

    secure: false,

    changeOrigin: true

  }

}),

复制代码

此外不要忘记更改 axios 的配置中的baseURL，将其改为/api/。

输入URL发生了啥？

• 1、浏览器的地址栏输入URL并按下回车。


• 2、浏览器查找当前URL是否存在缓存，并比较缓存是否过期。


• 3、DNS解析URL对应的IP。


• 4、根据IP建立TCP连接（三次握手）。


• 5、HTTP发起请求。


• 6、服务器处理请求，浏览器接收HTTP响应。


• 7、渲染页面，构建DOM树。


• 8、关闭TCP连接（四次挥手）。

永恒钻石

1. 浏览器应该具备什么功能？

• 1、网络：浏览器通过网络模块来下载各式各样的资源，例如HTML文本，JavaScript代码，CSS样式表，图片，音视频文件等。网络部分尤为重要，因为它耗时长，而且需要安全访问互联网上的资源


• 2、资源管理：从网络下载，或者本地获取到的资源需要有高效的机制来管理他们。例如如何避免重复下载，资源如何缓存等等


• 3、网页浏览：这是浏览器的核心也是最基本的功能，最重要的功能。这个功能决定了如何将资源转变为可视化的结果


• 4、多页面管理


• 5、插件与管理


• 6、账户和同步


• 7、安全机制


• 8、开发者工具

浏览器的主要功能总结起来就是一句话:将用户输入的url转变成可视化的图像。

2. 浏览器的内核

在浏览器中有一个最重要的模块，它主要的作用是把一切请求回来的资源变成可视化的图像，这个模块就是浏览器内核，通常他也被称为渲染引擎。

下面是浏览器内核的总结：

• 1、IE：Trident


• 2、Safari：WebKit。WebKit本身主要是由两个小引擎构成的，一个正是渲染引擎“WebCore”，另一个则是javascript解释引擎“JSCore”，它们均是从KDE的渲染引擎KHTML及javascript解释引擎KJS衍生而来。


• 3、Chrome：Blink。在13年发布的Chrome 28.0.1469.0版本开始，Chrome放弃Chromium引擎转而使用最新的Blink引擎（基于WebKit2——苹果公司于2010年推出的新的WebKit引擎），Blink对比上一代的引擎精简了代码、改善了DOM框架，也提升了安全性。


• 4、Opera：2013年2月宣布放弃Presto，采用Chromium引擎，又转为Blink引擎


• 5、Firefox：Gecko

3. 进程和线程

• 1、进程：程序的一次执行，它占有一片独有的内存空间，是操作系统执行的基本单元


• 2、线程：是进程内的一个独立执行单元，是CPU调度的最小单元，程序运行的基本单元


• 3、一个进程中至少有一个运行的线程：主线程。它在进程启动后自动创建


• 4、一个进程可以同时运行多个线程，我们常说程序是多线程运行的，比如你使用听歌软件，这个软件就是一个进程，而你在这个软件里听歌，收藏歌，点赞评论，这就是一个进程里的多个线程操作


• 5、一个进程中的数据可以供其中的多个线程直接共享，但是进程与进程之间的数据时不能共享的


• 6、JS引擎是单线程运行的

4. 浏览器渲染引擎的主要模块

• 1、HTML解析器：解释HTML文档的解析器，主要作用是将HTML文本解释为DOM树


• 2、CSS解析器：它的作用是为DOM中的各个元素对象计算出样式信息，为布局提供基础设施


• 3、JavaScript引擎：JavaScript引擎能够解释JavaScript代码，并通过DOM接口和CSS接口来修改网页内容 和样式信息，从而改变渲染的结果


• 4、布局（layout）：在DOM创建之后，WebKit需要将其中的元素对象同样式信息结合起来，计算他们的大小位置等布局信息，形成一个能表达着所有信息的内部表示模型


• 5、绘图模块（paint）：使用图形库将布局计算后的各个网页的节点绘制成图像结果

5. 大致的渲染过程

第1题的第7点，渲染页面，构建DOM树，接下来说说大致的渲染过程

• 1、浏览器会从上到下解析文档


• 2、遇见HTML标记，调用HTML解析器解析为对应的token(一个token就是一个标签文本的序列化)并构建DOM树(就是一块内存，保存着tokens，建立他们之间的关系)


• 3、遇见style/link标记调用相应解析器处理CSS标记，并构建出CSS样式树


• 4、遇见script标记，调用JavaScript引擎处理script标记，绑定事件，修改DOM树/CSS树等


• 5、将DOM树与CSS合并成一个渲染树


• 6、根据渲染树来渲染，以计算每个节点的几何信息(这一过程需要依赖GPU)


• 7、最终将各个节点绘制在屏幕上

至尊星耀

6. CSS阻塞情况以及优化

• 1、style标签中的样式：由HTML解析器进行解析，不会阻塞浏览器渲染(可能会产生“闪屏现象”)，不会阻塞DOM解析


• 2、link引入的CSS样式：由CSS解析器进行解析，会阻塞浏览器渲染，会阻塞后面的js语句执行，不阻塞DOM的解析


• 3、优化：使用CDN节点进行外部资源加速，对CSS进行压缩，优化CSS代码(不要使用太多层选择器)

注意：看下图，HTML和CSS是并行解析的，所以CSS不会阻塞HTML解析，但是，会阻塞整体页面的渲染(因为最后要渲染必须CSS和HTML一起解析完并合成一处)

7. JS阻塞问题

• 1、js会阻塞后续DOM的解析，原因是：浏览器不知道后续脚本的内容，如果先去解析了下面的DOM，而随后的js删除了后面所有的DOM，那么浏览器就做了无用功，浏览器无法预估脚本里面具体做了什么操作，例如像document.write这种操作，索性全部停住，等脚本执行完了，浏览器再继续向下解析DOM


• 2、js会阻塞页面渲染，原因是：js中也可以给DOM设置样式，浏览器等该脚本执行完毕，渲染出一个最终结果，避免做无用功。


• 3、js会阻塞后续js的执行，原因是维护依赖关系，例如：必须先引入jQuery再引入bootstrap

8. 资源加载阻塞

无论css阻塞，还是js阻塞，都不会阻塞浏览器加载外部资源（图片、视频、样式、脚本等）

原因：浏览器始终处于一种：“先把请求发出去”的工作模式，只要是涉及到网络请求的内容，无论是：图片、样式、脚本，都会先发送请求去获取资源，至于资源到本地之后什么时候用，由浏览器自己协调。这种做法效率很高。

9. 为什么CSS解析顺序从右到左

如果是从左到右的话：

• 1、第一次从爷节点 -> 子节点 -> 孙节点1


• 2、第一次从爷节点 -> 子节点 -> 孙节点2


• 3、第一次从爷节点 -> 子节点 -> 孙节点3

如果三次都匹配不到的话，那至少也得走三次：爷节点 -> 子节点 -> 孙节点，这就做了很多无用功啊。

如果是从右到左的话：

• 1、第一次从孙节点1，找不到，停止


• 2、第一次从孙节点2，找不到，停止


• 3、第一次从孙节点3，找不到，停止

这样的话，尽早发现找不到，尽早停止，可以少了很多无用功。

最强王者

10. 什么是重绘回流

• 1、重绘：重绘是一个元素外观的改变所触发的浏览器行为，例如改变outline、背景色等属性。浏览器会根据元素的新属性重新绘制，使元素呈现新的外观。重绘不会带来重新布局，所以并不一定伴随重排。


• 2、回流：渲染对象在创建完成并添加到渲染树时，并不包含位置和大小信息。计算这些值的过程称为布局或重排，或回流


• 3、"重绘"不一定需要"重排"，比如改变某个网页元素的颜色，就只会触发"重绘"，不会触发"重排"，因为布局没有改变。


• 4、"重排"大多数情况下会导致"重绘"，比如改变一个网页元素的位置，就会同时触发"重排"和"重绘"，因为布局改变了。

11. 触发重绘的属性

* color * background * outline-color * border-style * background-image * outline * border-radius * background-position * outline-style * visibility * background-repeat * outline-width * text-decoration * background-size * box-shadow

12. 触发回流的属性

* width * top * text-align * height * bottom * overflow-y * padding * left * font-weight * margin * right * overflow * display * position * font-family * border-width * float * line-height * border * clear * vertival-align * min-height * white-space

13. 常见触发重绘回流的行为

• 1、当你增加、删除、修改 DOM 结点时，会导致 Reflow , Repaint。


• 2、当你移动 DOM 的位置


• 3、当你修改 CSS 样式的时候。


• 4、当你Resize窗口的时候（移动端没有这个问题，因为移动端的缩放没有影响布局视口)


• 5、当你修改网页的默认字体时。


• 6、获取DOM的height或者width时，例如clientWidth、clientHeight、clientTop、clientLeft、offsetWidth、offsetHeight、offsetTop、offsetLeft、scrollWidth、scrollHeight、scrollTop、scrollLeft、scrollIntoView()、scrollIntoViewIfNeeded()、getComputedStyle()、getBoundingClientRect()、scrollTo()

14. 针对重绘回流的优化方案

• 1、元素位置移动变换时尽量使用CSS3的transform来代替top，left等操作


• 2、不要使用table布局


• 3、将多次改变样式属性的操作合并成一次操作


• 4、利用文档素碎片（documentFragment），vue使用了该方式提升性能


• 5、动画实现过程中，启用GPU硬件加速：transform:tranlateZ(0)


• 6、为动画元素新建图层，提高动画元素的z-index


• 7、编写动画时，尽量使用requestAnimationFrame

15. 浏览器缓存分类

1. 强缓存
   
   
   
   1. 不会向服务器发送请求，直接从本地缓存中获取数据
   
   
   2. 请求资源的的状态码为: 200 ok(from memory cache)
   
   
   3. 优先级：cache-control > expires
   
   
   
   


2. 协商缓存
   
   
   
   1. 向服务器发送请求，服务器会根据请求头的资源判断是否命中协商缓存
   
   
   2. 如果命中，则返回304状态码通知浏览器从缓存中读取资源
   
   
   3. 优先级：Last-Modified与ETag是可以一起使用的，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304

进入正题

面试环节对面试官的一些挑战

• 面试官和候选人的知识结构可能有差异 => 可能会错过优秀的人


• 遇到「面霸」，频繁面试刷题，但是实际能力一般 => 招到不合适的人


• 要在短短半个小时到一个小时内判断一个人，其实很难

相对靠谱的做法

• 笔试："Talk is cheap, show me the code"

笔试常见的问题

• 考通用算法，Google 能直接搜到，失去考察意义


• 题目难度设计有问题。要么满分，要么零分，可能错过还不错的同学


• 和实际工作内容脱节

我认为好的笔试题

• 上手门槛低，所有人多多少少都能写一点，不至于开天窗


• 考点多，通过一道题可以基本摸清候选人的代码综合素养


• 给高端的人有足够的发挥空间。同样的结果，不同的实现方式可以看出候选人的技术深度

我常用的一道笔试题

很普通的一道题

// 假设本地机器无法做加减乘除运算，需要通过远程请求让服务端来实现。

// 以加法为例，现有远程API的模拟实现



const addRemote = async (a, b) => new Promise(resolve => {

  setTimeout(() => resolve(a + b), 1000)

});



// 请实现本地的add方法，调用addRemote，能最优的实现输入数字的加法。

async function add(...inputs) {

  // 你的实现

}



// 请用示例验证运行结果:

add(1, 2)

  .then(result => {

    console.log(result); // 3

});





add(3, 5, 2)

  .then(result => {

    console.log(result); // 10

})

答案一
最基本的答案，如果写不出来，那大概率是通过不了了

async function add(...args) {

  let res = 0;

  if (args.length <= 2) return res;



  for (const item of args) {

    res = await addRemote(res, item);

  }

  return res;

}

递归版本

async function add(...args) {

  let res = 0;

  if (args.length === 0) return res;

  if (args.length === 1) return args[0];

  

  const a = args.pop();

  const b = args.pop();

  args.push(await addRemote(a, b));

  return add(...args);

}

常见的问题：

• 没有判断入参个数


• 仍然用了本地加法

答案二
有候选人的答案如下：

// Promise链式调用版本

async function add(...args) {

  return args.reduce((promiseChain, item) => {

    return promiseChain.then(res => {

      return addRemote(res, item);

    });

  }, Promise.resolve(0));



}

从这个实现可以看出：

• 对 Array.prototype.reduce 的掌握


• 对于 Promise 链式调用的理解


• 考察候选人对 async function 本质的理解

这个版本至少能到 70 分

答案三
之前的答案结果都是对的，但是我们把耗时打出来，可以看到耗时和参数个数成线性关系，因为所有计算都是串行的，显然不是最优的解

更好一点的答案：

function add(...args) {

  if (args.length <= 1) return Promise.resolve(args[0])

  const promiseList = []

  for (let i = 0; i * 2 < args.length - 1; i++) {

    const promise = addRemote(args[i * 2], args[i * 2 + 1])

    promiseList.push(promise)

  }



  if (args.length % 2) {

    const promise = Promise.resolve(args[args.length - 1])

    promiseList.push(promise)

  }



  return Promise.all(promiseList).then(results => add(...results));

}

可以看到很明显的优化。

答案四
还能再优化吗？
有些同学会想到加本地缓存

const cache = {};



function addFn(a, b) {

  const key1 = `${a}${b}`;

  const key2 = `${b}${a}`;

  const cacheVal = cache[key1] || cache[key2];

  

  if (cacheVal) return Promise.resolve(cacheVal);

  

  return addRemote(a, b, res => {

    cache[key1] = res;

    cache[key2] = res;

    return res;

  });

}

加了缓存以后，我们再第二次执行相同参数加法时，可以不用请求远端，直接变成毫秒级返回

还能再优化吗？交给大家去思考

其他考察点

有些时候会让候选人将代码提交到 Github 仓库，以工作中一个实际的模块标准来开发，可以考察：

• git 操作，commit 规范


• 工程化素养


• 是否有单元测试


• 覆盖率是否达标


• 依赖的模块版本如何设置


• 如何配置 ci/cd


• 文档、注释


• ...

更加开放的一种笔试形式

• 给一道题目，让候选人建一个 Github 仓库来完成


• 题目有一定难度，但是可以 Google，也可以用三方模块，和我们平时做项目差不多


• 通常面向级别较高的候选人

实际题目

// 有一个 10G 文件，每一行是一个时间戳，

// 现在要在一台 2C4G 的机器上对它进行排序，输出排序以后的文件



// 案例输入

// 1570593273487

// 1570593273486

// 1570593273488

// …



// 输出

// 1570593273486

// 1570593273487

// 1570593273488

// …

先看一个答案，看看哪里有问题

async function sort(inputFile, outputFile) {

  const input = fs.createReadStream(inputFile);

  const rl = readline.createInterface({ input });

  const arr = [];

  for await (const line of rl) {

    const item = Number(line);

    arr.push(item);

  }

  arr.sort((a, b) => a - b);



  fs.writeFileSync(outputFile, arr.join('\n'));

}

10GB 的文件无法一次性放进内存里处理，内存只有 4GB

再看一个神奇的答案，只有一行代码，而且从结果来说是正确的。但不是我们笔试想要的答案。

const cp = require('child_process');



function sort(inputFile, outputFile) {

 cp.exec(`sort -n ${inputFile} > ${outputFile}`);

}

解题思路

• 既然没办法一次性在内存中排序，那我们能否将 10GB 的文件拆分成若干个小文件


• 小文件先分别排序，然后再合并成一个大的文件

再将问题拆解

• 拆分大文件到小文件


• 小文件在内存里排序


• 合并所有小文件成一个整体排序过的大文件

本题最难的点在于如何合并所有小文件。代码如何实现？

• 这里需要用到一种数据结构：堆


• 堆：就是用数组实现的一个二叉树


• 堆分为：最大堆和最小堆，下面是一个最小堆（父节点小于它的子节点）

堆有一些特性：

• 对于一个父节点来说
  
  
  
  • 左节点位置：父节点位置 * 2 + 1
  
  
  • 右节点位置：父节点位置 * 2 + 2
  
  
  
  


• 很容易查找最大值 / 最小值

我们尝试把下面数组构造成一个最小堆

• 从最后一个非叶子节点开始往前处理


• 10 比 5 大，所以交换它们的位置

• 然后是节点 2，符合要求不需要处理


• 最后到顶点 3，它比左子节点大，所以要交换

完整的实现参考：github.com/gxcsoccer/e…

前言

一切的一切，都是因为群里的一个问题

虽然说最近在做 webpack 相关的事情，但是也没有对着干问题做过相关的研究，网上很多文章包括 vue 都介绍了建议使用 import ，但是没有说为什么要使用 import，对于开发者来说，调用的方式是没有区别的，那么为什么 import 的包就要比 require 的包小呢

这里暂时就不说什么调用方式了，什么动态加载（require）、静态编译（import）的，这个网上都有，这篇文章就是分析一下为什么要用 import，而不用 require

正文

首先本地先基于 webpack 搭建一个环境只是为了测试，不需要搭建太复杂的内容

基础文件内容

// webpack.config.js

module.exports = {

  mode: 'development',

  entry: './src/index.js'

}

在 index.js 内添加两种调用方式

function test() {

  const { b } = import('./importtest')

  console.log(b()) 

}

test()



// or



function test() {

  const { b } = require('./requiretest')

  console.log(b()) 

}

test()

importtest.js 中也是简单输出一下

// importtest.js

export default {

  b: function () {

    return {

      name: 'zhangsan'

    }

  }

}

requiretest.js 也是如此

// requiretest.js

module.exports = {

  b: function() {

    return {

      name: 'lisi'

    }

  }

}

上述的方式分别执行 webpack 后，输出的内容分别如下

import 输出

在打包时一共输出了两个文件：main.js 和 src_importtest_js.js，main.js 里面输出的内容如下

main.js 里面就是 index.js 里面的内容，importtest 里面的内容，是通过一个索引的方式引用过来的，引用的地址就是 src_importtest_js.js

require 输出

require 打包时，直接输出了一个文件，就只有一个 main.js，main.js 里面输出的内容如下

main.js 里面的内容是 index.js 和 requiretest.js 里面的所有内容

综上所述，我们从数据角度来看 import 的包是要大于 require 的，但通过打包文件来看，由业务代码导致的文件大小其实 import 是要小于 require 的

复制代码

多引用情况下导致的打包变化

这个时候我们大概知道了 import 和 require 打包的区别，接下来我们可以模拟一下一开始那位同学的问题，直接修改一下 webpack.config.js 的入口即可

module.exports = {

  mode: 'development',

  entry: {

    index: './src/index.js',

    index1: './src/index1.js'

  }

}

复制代码

这里直接保证 index.js 和 index1.js 的内容一样即可，还是先测试一下 import 的打包

这里的内容和单入口时打包的 import 基本一致，里面出了本身的内容外，都是引用的 src_importtest_js 的地址，那么在看看 require 的包

这里内容和单入口打包的 require 基本一致，都是把 requiretest 的内容复制到了对应的文件内

虽然我们现在看的感觉多入口打包，还是 import 的文件要比 require 的文件大，但是核心问题在于测试案例的业务代码量比较少，所以看起来感觉 import 要比 require 大，当我们的业务代码量达到实际标准的时候，区别就看出来了

总结

import: 打包的内容是给到一个路径，通过该路径来访问对应的内容

require: 把当前访问资源的内容，打包到当前的文件内

到这里就可以解释为什么 vue 官方和网上的文章说推荐 import 而不推荐 require，因为每一个使用 require 的文件会把当前 require 的内容打包到当前文件内，所以导致了文件的过大，使用 import，抛出来的是一个索引，所以不会导致重复内容的打包，就不会出现包大的情况

当然这也不是绝对的，就好像上述案例那种少量的业务代码，使用 import 的代码量其实要比 require 大，所以不建议大家直接去确定某一种方式是最好的，某一种方式就是不行的，依场景选择方法

尾声

这篇文章就是一个简单的平时技术方面基础研究的简介，不是特别高深的东西，还希望对大家有所帮助，如果有覆盖面不够，或者场景不全面的情况，还希望大家提出，我在继续补充

这种类型的文章不是我擅长的方向，还是喜欢研究一些新的东西，欢迎大家指教：

使用场景

小程序从A页面跳转到B页面，在B页面选择一个值后返回到A页面，在A页面使用在B页面选中的值。例如：在购买订单页面跳转到地址列表，选择完地址以后回退到订单页面，订单页面的配送地址需要同步更新。

解决方案

常见的比容要容易解决的方案是使用小程序的全局存储globalData、本地缓存storage、获取小程序的页面栈，调用上一个Page的setData方法、以及利用wx.navigateTo的events属性监听被打开页面发送到当前页面的数据。下面给大家简单对比下四种方法的优缺点：

1、使用globalData实现

//page A

const app = getApp() //获取App.js实例

onShow() {//生命周期函数--监听页面显示

  if (app.globalData.backData) {

    this.setData({ //将B页面更新完的值渲染到页面上

      backData: app.globalData.backData

    },()=>{

     	delete app.globalData.backData //删除数据 避免onShow重复渲染

    })

  }

}

//page B

const app = getApp() //获取App.js实例

changeBackData(){

   app.globalData.backData = '我被修改了'

   wx.navigateBack()

}

2、使用本地缓存Storage实现

//page A

  onShow: function () {

    let backData = wx.getStorageSync('backData')

    if(backData){

       this.setData({

     		 backData

    	},()=>{

     		 wx.removeStorageSync('backData')

    	})

    }

  },

 //page B

 changeBackData(){

    wx.setStorageSync('backData', '我被修改了')

    wx.navigateBack()

 },

3、使用小程序的Page页面栈实现

使小程序的页面栈，比其他两种方式会更方便一点而且渲染的会更快一些，不需要等回退到A页面上再把数据渲染出来，在B页面上的直接就会更新A页面上的值，回退到A页面的时候，值已经被更新了。globalData和Storage实现的原理都是在B页面上修改完值以后，回退到A页面，触发onShow生命周期函数，来更新页面渲染。

//page B

changeBackData(){

    const pages = getCurrentPages();

    const beforePage = pages[pages.length - 2]

    beforePage.setData({  //会直接更新A页面的数据，A页面不需要其他操作

      backData: "我被修改了"

    })

4、使用wx.navigateTo API的events实现

wx.navigateTo的events的实现原理是利用设计模式的发布订阅模式实现的，有兴趣的同学可以自己动手实现一个简单的，也可以实现相同的效果。

//page A

 goPageB() {

    wx.navigateTo({

      url: 'B',

      events: {

        getBackData: res => { //在events里面添加监听事件

          this.setData({

            backData: res.backData

          })

        },

      },

    })

  },

//page B	

changeBackData(){

    const eventChannel = this.getOpenerEventChannel()

       eventChannel.emit('getBackData', {  

     	 backData: '我被修改了'

    });

     wx.navigateBack()

 }

总结

1和2两种方法在页面渲染效果上比后面两种稍微慢一点，3和4两种方法在B页面回退到A页面之前已经触发了更新，而1和2两种方法是等返回到A页面之后，在A页面才触发更新。并且1和2两种方式，要考虑到A页面更新完以后要删除globalData和Storage的数据，避免onShow方法里面重复触发setData更新页面，所以个人更推荐大家使用后面的3和4两种方式。

原理图解

• 1、首先肯定是要先解析入口文件entry，将其转为AST(抽象语法书)，使用@babel/parser


• 2、然后使用@babel/traverse去找出入口文件所有依赖模块


• 3、然后使用@babel/core+@babel/preset-env将入口文件的AST转为Code


• 4、将2中找到的入口文件的依赖模块，进行遍历递归，重复执行1，2，3


• 5。重写require函数，并与4中生成的递归关系图一起，输出到bundle中

代码实现

webpack具体实现原理是很复杂的，这里只是简单实现一下，让大家粗略了解一下，webpack是怎么运作的。在代码实现过程中，大家可以自己console.log一下，看看ast，dependcies，code这些具体长什么样，我这里就不展示了，自己去看会比较有成就感，嘿嘿！！

目录