## 前言

Redux是 JavaScript 状态容器，我们通常会在React的项目中搭配这个库用来处理复杂的业务逻辑。

在学习使用Redux一阶段以后，觉得有必要看一下源码，一方面提高对Redux的理解，另一方面也可以通过阅读源码来提高自身的程序设计水平。



## Redux基本使用

从实际使用出发，我们才能更加容易理解Redux的源码。

下面是Redux的基本使用。

```javascript
import { createStore } from 'redux';
const store = createStore(reducer, preloadedState, enhancer) 
// 设置监听函数
store.subscribe(listener);
// 使用
// 首先，用户派发action
store.dispatch(action);
// 然后，Store自动调用Reducer，并且传入两个参数：当前State和收到的Action。Reducer会返回新的State
let nextState = reducer(previousState, action);
// State一旦有变化，Store就会调用监听函数，监听函数更新state，重新render
function listerner() {
  let newState = store.getState();
  component.setState(newState);   
}
listener();

```

#### 流程图解

在利用Redux进行状态管理时，用户在UI层面触发行为，一个action对象通过`store.dispatch`派发到Reducer进行触发，接下来Reducer会根据type来更新对应的Store上的状态树，更改后的state会触发对应组件的重新渲染。

如果存在中间件的话，一个action对象在通过`store.dispatch`派发，在调用reducer函数前，会先经过一个中间件环节。在一个Redux架构中可以用多个中间件，这些中间件一起组织处理请求的“管道”。一个中间件是一个独立的函数，可以组合使用，中间件有一个统一的接口，正因为一个中间件只能完成一个特定的功能，所以把多个中间件组合在一起才能满足比较丰富的应用需求。当然在使用时，也需要按照顺序依次处理传入的action，只有排在前面的中间件完成任务之后，后面的中间件才能有机会继续处理action。

## 源码简介

先开看下 Redux 的源码的目录结构，没错，只有下面几个js，果然是短小精悍，只有2kb，而且生产环境几乎没有什么外部的依赖。虽然结构看起来并不复杂，内容也不是很长，但是Redux 作为函数式编程的典型代表，理解起来并不简单。

我们截取了 github上 的源码，如下图。

![](https://p.ipic.vip/jnt0eo.jpg)

所有的js源码文件如下

- applyMiddleware.js     // Redux的插件机制实现
- bindActionCreators.js  // 将ActionCreator和dispatch绑定的工具
- combineReducers.js     // 将store分层的工具
- compose.js             // 将数个函数合并嵌套执行
- createStore.js         // 核心，生成store
- index.js               // 入口


## 源码解析

入口文件index.js和bindActionCreators这边就不做介绍了。下面展示的源码部分都是精简版的，去掉了一些注释和无关主逻辑的代码。

### createStore

首先来看createStore ，它的作用就是创建全局的store对象。在 Redux 中，整个应用只能有一个 Store，全局的state对象就保存在这个全局的store对象中。

#### 语法

* 参数
  * reducer
    * 数据类型：函数
    * 参数含义：接受当前state对象和action作为参数，用于处理state逻辑
  * preloadedState
    * 数据类型：：对象
    * 参数含义：初始的state
  * enhancer：
    * 数据类型：函数
    * 参数含义：store的增强器。这个函数由redux提供的applyMiddleware 函数来进行生成
* 返回值
  * store
    * 数据类型：对象
    * 该对象最常用的有三个属性getState，subscribe，dispatch。都是函数类型的

#### 源码

```javascript
import $$observable from 'symbol-observable'
import ActionTypes from './utils/actionTypes'
import isPlainObject from './utils/isPlainObject'

export default function createStore(reducer, preloadedState, enhancer) {
  // 判断 enhancer 是否是函数，enhancer 实际上就是中间件
  if (typeof enhancer !== 'undefined') {
    if (typeof enhancer !== 'function') {
      throw new Error(...)
    }
    return enhancer(createStore)(reducer, preloadedState)
  }
  // 判断reducer是否是函数
  if (typeof reducer !== 'function') {
    throw new Error(...)
  }
  
	// 当前reducer
  let currentReducer = reducer
  // 当前状态state
  let currentState = preloadedState
  // 当前的监听器队列
  let currentListeners = []
  // 未来的监听器队列
  let nextListeners = currentListeners
  // 是否处于再派发action的状态，即是否在执行reducer函数。这是为了避免死循环。默认为false。
  let isDispatching = false
	// 这个函数用于确保currentListeners 和 nextListeners 是不同的引用
  function ensureCanMutateNextListeners() {
    if (nextListeners === currentListeners) {
      nextListeners = currentListeners.slice()
    }
  }

  // 返回当前的state
  function getState() {
    if (isDispatching) {
      throw new Error(...)
    }
    return currentState
  }

  // 订阅监听函数
  function subscribe(listener) {
    if (typeof listener !== 'function') {
      throw new Error(...)
    }
    if (isDispatching) {
      throw new Error(...)
    }
    let isSubscribed = true
    // 这里Redux维护了两个队列，currentListeners和nextListeners
    // 考虑到只存在 currentListeners 的情况，如果我在执行某个 listener 中再次执行 subscribe或者 unsubscribe，会导致索引出错
    // 只有当下一次dispatch前，nextListeners又被同步给了currentListeners，之前的注册注销才会生效                
    ensureCanMutateNextListeners()
    nextListeners.push(listener)
    return function unsubscribe() {
      if (!isSubscribed) {
        return
      }
      if (isDispatching) {
        throw new Error(...)
      }
      isSubscribed = false
      ensureCanMutateNextListeners()
      const index = nextListeners.indexOf(listener)
      nextListeners.splice(index, 1)
    }
  }

	// 派发action
  function dispatch(action) {
    // action必须是一个对象
    if (!isPlainObject(action)) {
      throw new Error(...)
    }
    // type必须要有属性，不能是undefined
    if (typeof action.type === 'undefined') {
      throw new Error(...)
    }
    // 禁止在reducers中进行dispatch，因为这样做可能导致分发死循环
    if (isDispatching) {
      throw new Error(...)
    }
    try {
      isDispatching = true
      // 将当前的状态和action传给当前的reducer，用于生成最新的state 
      currentState = currentReducer(currentState, action)
    } finally {
      // 派发完毕
      isDispatching = false
    }	
    const listeners = (currentListeners = nextListeners)
    // 在得到新的状态后，依次调用每个监听器函数
    for (let i = 0; i < listeners.length; i++) {
      const listener = listeners[i]
      listener()
    }
    return action
  }

  dispatch({ type: ActionTypes.INIT })

  return {
    dispatch,
    subscribe,
    getState,
    replaceReducer,
    [$$observable]: observable
  }
}
```

#### 总结

createStore就是封装了一些api，通过闭包的形式，保存了两个重要的私有变量，state和listener。

**getState**：用来获取store中的state的。因为redux是不允许用户直接操作state，对于state的获取，是得通过getState的api来获取store内部的state。

**subscribe**：可以给 store 的状态添加订阅监听，一旦我们调用了 dispatch 来分发 action ，所有的监听函数就会执行。实际使用中用的不多，是因为react-redux 隐式的为我们帮我们完成了这方面的工作。

**dispatch**：是redux中一个非常核心的方法，也是我们在日常开发中最常用的方法之一。dispatch函数是用来触发状态改变的，它接受一个 action 对象作为参数，然后 reducer 就可以根据 action 的属性以及当前 store 的状态，来生成一个新的状态，从而改变 store 的状态；



### compose

compose 可以接受一组函数作为参数，从右到左来组合多个函数，然后返回一个组合函数。其实就是函数的合并，它想要实现的效果就像下面这样。

```javascript
compose(a, b, c) === (...args) => a(b(c(...args)))
```

#### 语法

- 参数
  - funcs：
    - 数据类型：函数
    - 参数含义：若干个用于组合的函数
- 返回值
  - func：
    - 数据类型：函数
    - 参数含义：执行该函数返回多个函数连续执行的结果

#### 源码

```javascript
export default function compose(...funcs) {
  if (funcs.length === 0) {
    return arg => arg
  }
  if (funcs.length === 1) {
    return funcs[0]
  }
  return funcs.reduce((a, b) => (...args) => a(b(...args)))
}
```

underscore 的 compose 函数的实现，可以对比一下

```javascript
function compose() {
    var args = arguments;
    var start = args.length - 1;
    return function() {
        var i = start;
        var result = args[start].apply(this, arguments);
        while (i--) result = args[i].call(this, result);
        return result;
    };
};
```

#### 总结

compose函数理解并不困难，就是将多个函数依次进行组合，将后者的返回结果作为前者的参数。很多js库也都有类似的函数实现，redux利用了数组reduce方法的特性巧妙得用一行代码实现了功能。

### applyMiddleware

Redux 中最难的还是applyMiddleware的理解。这个插件机制是Redux一个很重要的功能，使得我们可以很方便的对action做各种各样的操作。比如日志打印，异步数据获取等等，只要添加一个middleware，就可以实现。这个类似于Express或者Koa中的中间件机制。

你可以这样理解函数柯里化，通过闭包保存了外部的一个变量，然后返回一个接收参数的函数，在该函数中使用了保存的变量，然后再返回值。

分析applyMiddleware的代码结构。 是个三级**柯里化**的高阶函数。它将依次获得三个参数：第一个是 middlewares 数组，第二个是 Redux 原生的 createStore，最后一个是 reducer。

#### 语法

- 参数
  - middlewares
    - 数据类型：函数
    - 参数含义：若干个中间件函数
- 返回值
  - func
    - 数据类型：函数
    - 参数含义：高阶函数，并作为函数creatStore的参数之一，连续执行该函数可以得到最终的store对象

#### 源码

```javascript
// 一个最简单的中间件
// 所有的中间件都必须遵循这样的格式，这个是因为applyMiddleware函数决定的
({getState, dispatch}) => next => action => next(action);

export default function applyMiddleware(...middlewares) {
  return createStore => (...args) => {
    // 利用传入的createStore和reducer创建一个store
    const store = createStore(...args)
    // 这个dispatch并不是最后在中间件里
    let dispatch = () => {
      throw new Error(...)
    }
    // 传给中间件第一层函数的参数                  
    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args)
    }
    // 让每个 middleware 执行一遍，并传入两个参数getState和dispatch
    const chain = middlewares.map(middleware => middleware(middlewareAPI))
    // 上面提到compose的作用就是组合函数，结合中间件函数的格式，举个例子
    // 如果存在三个中间件a,b,c。在通过上面的函数执行过后，每个中间件返回的是next => action => {}这样的函数。函数的参数都是next函数，再返回一个函数，并通过闭包的形式把next函数保存起来。
    // 执行compose(...chain)(store.dispatch)
    // c最先执行，参数是store.dispatch，执行返回action=>{dosomethingC();return dispatch(action)}
    // b接着执行，参数是c的返回结果，然后返回action=>{dosomethingB();dosomethingA();return dispatch(action)}
    // a接着执行，参数是b的返回结果，然后返回action=>{dosomethingA();dosomethingB();dosomethingC();return dispatch(action)}，并且赋值给变量dispatch
    dispatch = compose(...chain)(store.dispatch)
    return {
      ...store,
      dispatch
    }
  }
}
```

#### 中间件的执行顺序

还有特别重要的就是关于中间件的执行顺序。下面是一个测试的demo。

```javascript
function middleware1({dispatch,getState}) {
  return function(next) {
    console.log('middleware1 next层',next);
    return function(action) {
      console.log('middleware1 action层 开始')
      next(action)
      console.log('middleware1 action层 结束')
    }
  }
}
function middleware2({dispatch,getState}) {
  return function(next) {
    console.log('middleware2 next层',next);
    return function(action) {
      console.log('middleware2 action层 开始')
      next(action)
      console.log('middleware2 action层 结束')
    }
  }
}
function middleware3({dispatch,getState}) {
  return function(next) {
    console.log('middleware3 next层',next);
    return function(action) {
      console.log('middleware3 action层 开始')
      next(action)
      console.log('middleware3 action层 结束')
    }
  }
}

let noop = ()=>{}
// 执行第一层函数
const chain = [middleware1, middleware2, middleware3].map(middleware => middleware({noop,noop}))
// 执行第二层函数
let dispatch = compose(...chain)(noop)
// 结果如下 
/**	
  middleware3 next层 ()=>{}
 	middleware2 next层 ƒ (action) {
    console.log('middleware3 action层 开始')
    next(action)
    console.log('middleware3 action层 结束')
   }
  middleware1 next层 ƒ (action) {
    console.log('middleware2 action层 开始')
    next(action)
    console.log('middleware2 action层 结束')
  }
**/

// 执行第三层函数
dispatch()
// 结果如下 
/**	
  middleware1 action层 开始
  middleware2 action层 开始
  middleware3 action层 开始
  middleware3 action层 结束
  middleware2 action层 结束
  middleware1 action层 结束
**/
```

#### 总结

中间件链的最内环是接受`store.dispatch`作为参数，最后返回的dispatch是增强的dispatch。每个中间件的next也是一次封装增强后的dispath。



### combineReducers

这个函数是用来整合多个reducers的， 因为createStore只接受一个reducer作为参数。

#### 语法

- 参数
  - reducer
    - 数据类型：对象
    - 参数含义：属性值是所有的reducer函数
- 返回值
  - finalreducer：
    - 数据类型：函数
    - 参数含义：reducer合并返回最终的reducer函数

#### 源码

```javascript
export default function combineReducers(reducers) {
  // 获取该对象的 key 值
  const reducerKeys = Object.keys(reducers)
  // 有效的reducer列表
  const finalReducers = {}
  // 过滤无效的reducer
  for (let i = 0; i < reducerKeys.length; i++) {
    const key = reducerKeys[i]
    if (process.env.NODE_ENV !== 'production') {
      if (typeof reducers[key] === 'undefined') {
        warning(`No reducer provided for key "${key}"`)
      }
    }
    if (typeof reducers[key] === 'function') {
      finalReducers[key] = reducers[key]
    }
  }
  // 拿到过滤后的reducers的key值
  const finalReducerKeys = Object.keys(finalReducers)
	// 返回最终生成的reducer
  return function combination(state = {}, action) {
    // 定义state是否改变，默认false
    let hasChanged = false
    // 定义新的nextState
    const nextState = {}
    // 遍历reducers对象中的有效key，执行该key对应的value函数，即子reducer函数，并得到对应的state对象,将新的子state挂到新的nextState对象上
    for (let i = 0; i < finalReducerKeys.length; i++) {
      const key = finalReducerKeys[i]
      const reducer = finalReducers[key]
      // state树下的key是与 finalReducers下的key相同的
      const previousStateForKey = state[key]
      const nextStateForKey = reducer(previousStateForKey, action)
      nextState[key] = nextStateForKey
      // 如果存在触发某个reducer函数返回的state发生了改变，hasChanged置为true
      hasChanged = hasChanged || nextStateForKey !== previousStateForKey
    }
     // 遍历一遍看是否发生改变，发生改变了返回新的state，否则返回原先的state
    return hasChanged ? nextState : state
  }
}
```

#### 总结

这个combineReducers函数分为两部分，第一部分是检验传入的reducers的准确性，得到一个过滤后的对象 finalReducers。第二部分就是计算state，根据传入的action，遍历finalReducers，执行每个对象中的每个reducer函数，并将最终的state返回。注意的是，在reducer的代码处理逻辑中，如果没有返回一个新的state独享，而是在原有的state对象上增加或删除某个属性并返回。在比较新旧state的时候，会认为两个对象是一样的，最终不会



## 总结

Redux设计巧妙，思维严谨，整个代码没有特别臃肿的部分。虽然个人还存在不理解的部分，比如creatstore的设计思想等等。下面还要继续学习，下一步的阅读计划是react-redux和redux-thunk，希望能趁热打铁把react全家桶的相关代码都阅读学习一遍。

redux源码浅读

## 前言

前端性能关系到页面的用户体验，页面的用户体验影响了产品的留存率，而产品则直接决定了一个公司的生死存亡。

Global Web Performance Matters for ecommerce的报告中指出：

![](https://p.ipic.vip/eclvaq.png)

- 57%的用户更在乎网页在3秒内是否完成加载。

- 52%的在线用户认为网页打开速度影响到他们对网站的忠实度。

- 每慢1秒造成页面 PV 降低11%，用户满意度也随之降低降低16%。

- 近半数移动用户因为在10秒内仍未打开页面从而放弃。

在我们做前端性能优化的时候，我们必须知道我们所做的优化到底能提升多少性能，这时候就有必要对前端性能进行监控。当然，我们现在这边讨论的前端性能，是关于页面加载和延迟方面的性能，暂时不讨论对错误处理的相关内容。



## Performance

首先简单介绍一下前端相关的性能指标，我们关注的几个指标如下。

- 白屏时间 = 地址栏输入URL回车 - 浏览器出现第一个元素
- 首屏时间 = 地址栏输入URL回车 - 浏览器第一屏渲染完成
- 用户可操作时间
- 页面总下载时间

对开发人员而言，我们常用的性能指标API就是Performance。Performance 接口可以获取到当前页面与性能相关的信息。

我们使用`window.performance`就可以获得 performance对象。

在控制台我们打印performance，可以看到performance对象包含五个属性。

* navigation 提供了在指定的时间段里发生的操作相关信息，包括页面是加载还是刷新、发生了多少次重定向等等。

* timing 对象包含延迟相关的性能信息，也是这次我们需要
* memory 对象
  * jsHeapSizeLimit: 内存大小限制
  * totalJSHeapSize: 可使用的内存
  * usedJSHeapSize: JS 对象占用的内存

* timeOrigin 返回性能测量开始时的时间的高精度时间戳


我这边先给出上述字段的含义，个人认为比较重要的节点加粗了

- **navigationStart: 表示从上一个文档卸载结束时的 unix 时间戳，如果没有上一个文档，这个值将和 fetchStart 相等**。
- unloadEventStart: 表示前一个网页（与当前页面同域）unload 的时间戳，如果无前一个网页 unload 或者前一个网页与当前页面不同域，则值为 0。
- unloadEventEnd: 返回前一个页面 unload 时间绑定的回掉函数执行完毕的时间戳。
- redirectStart: 第一个 HTTP 重定向发生时的时间。有跳转且是同域名内的重定向才算，否则值为 0。
- redirectEnd: 最后一个 HTTP 重定向完成时的时间。有跳转且是同域名内部的重定向才算，否则值为 0。
- **fetchStart: 浏览器准备好使用 HTTP 请求抓取文档的时间，这发生在检查本地缓存之前**。
- domainLookupStart/domainLookupEnd: DNS 域名查询开始/结束的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
- connectStart: HTTP（TCP）开始/重新 建立连接的时间，如果是持久连接，则与 fetchStart 值相等。
- connectEnd: HTTP（TCP） 完成建立连接的时间（完成握手），如果是持久连接，则与 fetchStart 值相等。
- secureConnectionStart: HTTPS 连接开始的时间，如果不是安全连接，则值为 0。
- requestStart: HTTP 请求读取真实文档开始的时间（完成建立连接），包括从本地读取缓存。
- **responseStart: HTTP 开始接收响应的时间（获取到第一个字节），包括从本地读取缓存**。
- **responseEnd: HTTP 响应全部接收完成的时间（获取到最后一个字节），包括从本地读取缓存**。
- domLoading: 开始解析渲染 DOM 树的时间，此时 Document.readyState 变为 loading，并将抛出 readystatechange 相关事件。
- domInteractive: 完成解析 DOM 树的时间，Document.readyState 变为 interactive，并将抛出 readystatechange 相关事件，注意只是 DOM 树解析完成，这时候并没有开始加载网页内的资源。
- **domContentLoadedEventStart: DOM 解析完成后，网页内资源加载开始的时间，在 DOMContentLoaded 事件抛出前发生。**
- **domContentLoadedEventEnd: DOM 解析完成后，网页内资源加载完成的时间（如 JS 脚本加载执行完毕）。**
- domComplete: DOM 树解析完成，且资源也准备就绪的时间，Document.readyState 变为 complete，并将抛出 readystatechange 相关事件。
- **loadEventStart: load 事件发送给文档，也即 load 回调函数开始执行的时间。**
- **loadEventEnd: load 事件的回调函数执行完毕的时间。**

(1) DOMContentLoaded 是指页面元素加载完毕，但是一些资源比如图片还无法看到，但是这个时候页面是可以正常交互的，比如滚动，输入字符等。 jQuery 中经常使用的 `$(document).ready()` 其实监听的就是 DOMContentLoaded 事件。

(2) load 是指页面上所有的资源（图片，音频，视频等）加载完成。jQuery 中 `$(document).load()` 监听的是 load 事件。

## 实战测试

由于上面的一些字段解释源于网上的文档和资料，所以我自己需要做一些代码上的测试。

#### 一、 **domContentLoadedEventStart** 和 **domContentLoadedEventEnd** 区别

代码如下，我们计算了**DOMContentLoaded**的回调执行时间。

```javascript
window.addEventListener('DOMContentLoaded', () => {
  console.time('DOMContentLoaded')
  for (let i=0;i<1000000000;i++){
  }
  console.timeEnd('DOMContentLoaded')
})
```

在浏览器控制台，我们打印了这两个字段的差值，发现两个字段的差值刚好等于**DOMContentLoaded**的回调执行时间，网上关于字段的解释正确。并且，真正触发**DOMContentLoaded**事件应该是**domContentLoadedEventStart**对应的时间。

#### 二、DOMContentLoaded 是对应**domContentLoadedEventStart** 和 **domContentLoadedEventEnd** 哪个字段。

在浏览器控制台，我们打印了它和**navigationStart**的差值。

![](https://raw.githubusercontent.com/only-twj520Q/pic_bed/master/blog/202407291637855.png)

在浏览器network的下面，我们看到显示的DOMContentLoaded时间是1.34秒

![](https://raw.githubusercontent.com/only-twj520Q/pic_bed/master/blog/202407291641866.png)

结论：浏览器上的**DOMContentLoaded**的时间实际代表的是**domContentLoadedEventEnd** 的时间。

#### 三、 当前网页load事件还没有发生，返回0。

在**DOMContentLoaded**事件的回调里，我们发现**loadEventStart**和**loadEventEnd**都是0。在load事件的回调里，我们发现loadEventStart有值，loadEventEnd是0。

结论：如果需要计算load的时间的话，一定要注意代码在页面load事件触发以后再去计算。

## 性能指标的计算

#### 一、白屏时间

再明确一下白屏时间的定义，用户从打开页面开始到页面开始有东西呈现为止。

**如果是chrome高版本，直接可以通过下面代码获得**

```
// 白屏时间
(chrome.loadTimes().firstPaintTime - chrome.loadTimes().startLoadTime)*1000;
```

**如果是没有该API的普通浏览器**

我们通常认为浏览器开始渲染 `<body>` 或者解析完 `<head>` 的时间是白屏结束的时间点。

所以，白屏时间 = 开始渲染时间 + 头部资源加载时间

##### 1、开始渲染时间

```javascript
//开始渲染时间
startTime = performance.timing.domLoading - performance.timing.navigationStart;
```

##### 2、头部资源加载时间

我们在`<head>`的前面计时开始，在`<head>`最末尾计时结束，中间的差值就是头部资源加载时间。

```html
<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <script>
      var start_time = new Date; //测试时间起点，实际统计起点为 DNS 查询
  </script>
  <script>
    for(let i=0; i<10000000000; i++){
    }
  </script>
  
  <link rel="stylesheet" href="xx.css">
  <script>
    var end_time = +new Date; //时间终点
    var headTime = end_time - start_time; //头部资源加载时间
  </script>
</head>
<body>
</body>
</html>
```

所以最终，白屏时间 =  开始渲染时间(startTime) + 头部资源加载时间(headTime)

#### 二、首屏时间

再明确一下首屏时间的定义，用户浏览器首屏内所有内容都呈现出来所花费的时间。

影响首屏的主要因素是图片的加载。基本流程如下

```html
首屏位置调用 API 开始统计 -> 绑定首屏内所有图片的 load 事件 -> 页面加载完后判断图片是否在首屏内，找出加载最慢的一张 -> 首屏时间
```

对于网页高度小于屏幕的网站来说，只要在页面底部加上脚本打印当前时间即可；或者对于网页高度大于一屏的网页来说，只要在估算接近于一屏幕的元素的位置后，打印一下当前时间。当然这个时间要得把首屏中所有图片的加载时间也算上。

#### 三、用户可操作时间

**用户可操作时间**影响交互体验，通常我们把所有事件的绑定都放在domReady以后，所以用户可操作的时间可以等于DOM解析完毕的时间。

```javascript
用户可操作时间 = performance.timing.domInteractive - performance.timing.navigationStart
```

#### 四、页面总下载时间

**页面总下载时间**可以统计**onload**时间，load事件必须等到页面内包括图片的所有元素加载完毕后才能触发。

```javascript
页面总下载时间 = performance.timing.loadEventEnd - performance.timing.navigationStart
```

#### 五、常见的指标

```javascript
// 计算加载时间
function getPerformanceTiming() {
    var t = performance.timing
    var times = {}
    // 页面加载完成的时间，用户等待页面可用的时间
    times.loadPage = t.loadEventEnd - t.navigationStart
    // 解析 DOM 树结构的时间
    times.domReady = t.domComplete - t.responseEnd
    // 重定向的时间
    times.redirect = t.redirectEnd - t.redirectStart
    // DNS 查询时间
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart
    // 读取页面第一个字节的时间
    times.ttfb = t.responseStart - t.navigationStart
    // 资源请求加载完成的时间
    times.request = t.responseEnd - t.requestStart
    // 执行 onload 回调函数的时间
    times.loadEvent = t.loadEventEnd - t.loadEventStart
    // DNS 缓存时间
    times.appcache = t.domainLookupStart - t.fetchStart
    // 卸载页面的时间
    times.unloadEvent = t.unloadEventEnd - t.unloadEventStart
    // TCP 建立连接完成握手的时间
    times.connect = t.connectEnd - t.connectStart
    return times
}
```



## 性能工具

页面性能的评估与监控有很多工具，下面简单介绍几个常用的工具：

* Page Speed: 谷歌开发的分析和优化网页的工具，可以作为浏览器插件使用　　

* WebPageTest：一款非常优秀的网页前端性能测试工具。使用 WebPagetest，你可以详细掌握网站加载过程中的瀑布流、性能得分、元素分布、视图分析等数据。其中比较直观的视图分析功能可以直接看到页面加载各个阶段的截屏。国内也有利用 WebPagetest 搭建的性能测试平台，推荐使用阿里测。　

* PhantomJS：自动化监测，模拟Phantom JS 是一个服务器端的 JavaScript API 的 WebKit，基于它可以轻松实现 web 自动化测试。类似的有berserkJS。但是都是服务器模拟测试，不能监控用户真实环境。

前端性能监控

## 前言

什么是babel？你可以理解它就是一个语法转器，简单来说就是 ES6、ES7等等的新语法转化为ES5或能让低端浏览器正常运行的代码。比如我们经常使用的async、promise语法，在低端浏览器上可能就无法使用，会引起故障，但是只要我们合理使用babel，我们就可以放心大胆地使用新语法。

下面阐述的内容都是基于Babel 7的使用和总结，因babel 6 和babel 7在使用上存在较大差异，所以需要提前说明一下。



## 核心原理

这边简单介绍一下babel的工作原理，其实就是利用了抽象语法树，又称AST。所有的babel插件也是基于AST。

#### Babel的处理步骤

* 解析。将源代码变成AST。babel的解析器使用的是babylon。在解析过程中有两个阶段：**词法分析**和**语法分析**，词法分析阶段把字符串形式的代码转换为**令牌**（tokens）流，令牌类似于AST中节点；而语法分析阶段则会把一个令牌流转换成 AST的形式，同时这个阶段会把令牌中的信息转换成AST的表述结构。

* 转化。操作AST，去改变代码。babel转化器使用的是babel-traverse。babel使用提供的API对AST进行深度优先遍历，在此过程中对节点进行添加、更新及移除操作。

* 生成。将更改后的AST，再变回代码。babel生成器使用的是babel-generator。将经过转换的AST通过babel-generator再转换成js代码，过程就是深度优先遍历整个AST，然后构建可以表示转换后代码的字符串。

我们编写的代码在编译阶段就被解析成AST，为什么要转化成AST，是因为方便计算机更好地理解代码，方便开发人员更好地操作代码。因为对于计算机或者编辑器而言，代码其实本质上就是字符串。

可以使用这个链接[在线测试](https://astexplorer.net/)观察代码生成的AST是什么样的。

```javascript
{
    "type": "Program",
    "start": 0,
    "end": 52,
    "body": [...]
}
```

你会发现抽象语法树中不同层级有着相似的结构，这样的结构叫做节点，一个AST是由多个或单个这样的节点组成，节点内部还可以嵌套有多个这样的子节点。

#### 实际使用

```javascript
import * as babylon from 'babylon';
import traverse from 'babel-traverse';
import generate from 'babel-generator';

const code = `function double(x) {
  return x;
}`;
const ast = babylon.parse(code);
traverse(ast, {
  enter(path) {
    if (
      path.node.type === "Identifier" &&
      path.node.name === "x"
    ) {
      path.node.name = "xx";
    }
  }
});
const output = generate(ast, code);
console.log('output', output)

// 输出结果
{
  code: "function double(xx) {↵  return xx;↵}"
  map: null
  rawMappings: null
}
```

## 基本用法

一般而言，babel的使用存在两种方式。

* 命令行
* 结合构建工具

通常说来，后者更常见。如果结合webpack使用，我们需要在`webpack.config.js`中的配置项`rules`属性中配置`babel-loader`，然后在项目根目录中新增`.babelrc`文件，这个文件就是对babel的配置。

`webpack.config.js`部分配置

```javascript
module: {
  rules: [
    {
      test: /\.js$/,
      include: path.resolve('src'),
      loader: 'babel-loader'
    },
    ...
  ]
 }
```

`.babelrc`部分配置

```javascript
{
  "presets": [
    [ 
      "@babel/preset-env", {
        "targets": {
          "chrome": "52",
          "ie": "8"
        },
        "useBuiltIns": false,
        "corejs": false
    	}
    ]
  ]
 }
```

`babel-loader`使用前需要使用`npm`安装，并且它默认会读取根目录下的`.babelrc`的配置，或者直接在`babel-loader`的配置options也是可以的。注意`.babelrc`文件的内容格式是JSON。



## 常见名词

#### @babel/core

babel的核心包，它主要的作用就是编译。

#### @babel/cli

只有@babel/core是无法在命令行使用这些功能的，@babel/cli支持你直接在命令行中编译代码。

```javascript
./node_modules/.bin/babel src --out-dir lib
```

上面的命令会编译src目录下的所有js代码，并编译成最终的代码（`babel.config.js`或者`.babelrc`配置的），并输出到lib目录下。`--out-dir`代表输出到哪个目录下。

#### @babel/node 

`babel-node` 命令并非独立安装，在babel 7以前，需要通过安装 `babel-cli` 包获得。而在babel 7以后，babel 的模块被拆分。因此需要安装 `@babel/core`和 `@babel/node` 两个包来获取。

```javascript
// 安装
npm i -g @babel/core @babel/node
// 使用
babel-node test.js
```

#### @babel/polyfill

babel默认只转化js语法，比如对let ，const，class等。它不转换新的API，比如Set、Map、Reflect、Symbol、Promise 等全局对象，包括全局对象上的方法，比如`Object.assign`。

我们使用babel官网提供的的`try out`功能做演示。

![](https://img.ikstatic.cn/MTU3MzczMTMxOTQ5OCM1MzkjanBn.jpg)

如图，我们可以看到babel插件默认只会对class，箭头函数这些js语法糖进行转化。但是对新的API它默认不会进行支持，比如上图中的Promise。所以我们可以引入`@babel/polyfill`。这个库包含了`core-js`和`regenerator-runtime`。它是对完整的ES6环境的模拟，我们需要在入口文件或者所有代码的前面引入这个库。

```js
import '@babel/polyfill'
// 等同于
import "core-js/shim";
import "regenerator-runtime/runtime";
```

但是这个库有两个很不可忽略的问题。

* 体积太大。在非压缩的前提下，能达到几百K，而且如果我们只是使用了其中某个特性的情况下，这会造成很大的浪费。
* 会污染全局变量，因为它会增加很多全局变量API，或者在很多类的原型链上都作了修改，从而实现增加实例方法。如果我们开发的也是一个类库供其他开发者使用，这种情况就会变得非常不可控。

至于说解决方案下面会提到。



## 核心使用

需要记住的是，babel本身不具有任何转化能力，我们把它转化的功能都分解到一个个插件中去。所以，当我们不配置任何插件的时候，输入和输出的代码都是一样的。

在配置文件中，我们主要是由两个配置项，分别是预设preset和插件plugins。

新的babel 7已经使用了新的插件语法。

### 预设preset

先解释一下什么是预设，在没有预设这个概念之前，当我们需要使用箭头函数的时候，我们使用`@babel/plugin-transform-arrow-functions`插件，它的作用就是将ES6的箭头函数转换成普通函数，但是ES6的语法太多了，如果我们单纯依靠引入一个个依赖的插件就太麻烦，而且容易出错。所以预设的出现就解决了这个问题，它可以理解为插件的组合，比如`@babel/preset-es2015`是对整个ES6语法的插件集合，还有`@babel/preset-es2016`等等，不过现在这些类似的这些预设官方也不推荐使用了，推荐使用`@babel/preset-env`。目前常见的预设有`@babel/preset-env`，`@babel/preset-react`，`@babel/preset-typescript`。

#### @babel/preset-env（重点）

重点介绍`@babel/preset-env`。这是一个能根据配置的运行环境特点，为代码做相应和必要的编译，同时支持浏览器和node，比如如果你要求的运行环境浏览器版本比较低，转化的代码可能会比较多，如果要求支持的是高版本浏览器，可能你都不需要转化ES6的语法，从而节省了很多空间。如果不写任何配置项，env 等价于 latest，也等价于` es2015 + es2016 + es2017` 三个相加(不包含 `stage-x` 中的插件)。env 包含的插件列表维护在[这里](https://github.com/babel/babel-preset-env/blob/master/data/plugin-features.js)

```javascript
// 浏览器
{
  "presets": [
    ["@babel/preset-env", {
      "targets": {
        "browsers": ["last 2 versions", "safari >= 7"]
      }
    }]
  ]
}
// node
{
  "presets": [
    ["@babel/preset-env", {
      "targets": {
        "node": "6.10"
      }
    }]
  ]
}

```

此外babel 7的还有一个重要的变化是删除了`stage-x`的相关插件，这是一个实验性的语法插件，所有针对处于标准提案阶段的功能所编写的预设（stage preset）都已被弃用。`@babel/preset-env`将只支持到`stage-4`。stage 是向下兼容 0>1>2>3>4 所包含的插件数量依次减少。

简单说明一下，TC39 将提案分为以下几个阶段：

* Stage 0 - 设想（Strawman）：只是一个想法，可能有 Babel插件。
* Stage 1 - 建议（Proposal）：这是值得跟进的。
* Stage 2 - 草案（Draft）：初始规范。
* Stage 3 - 候选（Candidate）：完成规范并在浏览器上初步实现。
* Stage 4 - 完成（Finished）：将添加到下一个年度版本发布中。

#### useBuiltIns配置

这是一个`preset-env`的重要配置选项，它的出现是为了解决上述提到`@babel/polyfill`的缺陷，它将会自动检测语法帮你require你代码中使用的部分polyfill。

```javascript
{
  "presets": [
    ["@babel/preset-env", {
      "useBuiltIns": "usage",
      "corejs": 2,
      "targets": {
        "browsers": ["last 2 versions", "safari >= 7"]
      }
    }]
  ]
}
```

这个字段的可选值包括：usage、entry 和 false， 默认为 false，表示不对 polyfills 处理。

* usage：它会在你使用到 ES6 新特性时，自动从`core-js`中添加相关的模块和方法，不会造成全局污染。
* entry：需要在入口使用`import "@babel/polyfill"`，将 polyfill 拆分引入，仅引入有浏览器不支持的 polyfill

![image-20191114175843871](https://img.ikstatic.cn/MTU3MzczMTQyMTY3MiM4NjEjanBn.jpg)

如上图，配置了entry以后，`import @babel/polyfill`会被分拆成很多`require("core-js/modules/xxx")`，它其实会根据`@babel/preset-env`配置的目标环境将一个大的库分拆引入。事实上，`@babel/polyfill`这个包本身是没有内容的，它依赖于`core-js`和`regenerator-runtime`这两个包，这两个包提供了ES6规范的运行时环境。因此当我们不需要按需polyfill时直接引入`@babel-polyfill`就行了，它会把`core-js`和`regenerator-runtime`全部导入，当我们配置了entry以后，它会根据目标环境自动按需引入`core-js`和`regenerator-runtime`。

![](https://img.ikstatic.cn/MTU3MzczMTU1MzU4NCMgIDQjanBn.jpg)

如上图，当配置了usage以后，我们无需手动`import '@babel/polyfill'`，它会根据我们的实际代码结合配置的目标环境，自动引入相应的库。

所以，比较这两个配置字段，我更倾向于使用usage这种方式，事实上，它才是真正做到了按需引入。

### 插件plugin

插件的作用是为了实现某个具体功能，比如预设不能支持的，比如`@babel/plugin-proposal-decorators`是为了解决装饰器的问题，比如`@babel/plugin-syntax-dynamic-import`是为了解决webpack动态引入某个模块的问题。

#### @babel/plugin-transform-runtime（重点）  

这个插件能解决`@babel/polyfill`提供的类或者实例方法污染全局作用域的情况的。它的作用和上面的useBuiltIns很类似。

`@babel/plugin-transform-runtime`插件是为了解决

- 运行时引入，为了解决多个文件重复引用相同helpers 
- 局部引入，为了解决新API方法全局污染

![](https://img.ikstatic.cn/MTU3MzczMTcyNjEwNyM2NTIjanBn.jpg)

![](https://img.ikstatic.cn/MTU3MzczMTg4MTc5MyM2MjUjanBn.jpg)

对比上面的两个图，我们用class举例，可以发现，如果使用这个插件，它会在每个模块的内部重复定义这个相同的函数方法，虽然最后的结果也没有问题，但是会造成出现很多重复代码，并且增大了体积。而如果使用了插件以后，我们发现从定义方法改成引用，那重复定义就变成了重复引用，就不存在代码重复的问题了。如上图，可以发现，class这个helper 就是通过 `require` 引入的，这样就不会存在代码重复的问题了。

在使用 `babel-plugin-transform-runtime` 的时候必须把 `babel-runtime` 当做依赖。

 `babel-runtime`内部集成了

* `core-js`：转换一些内置类 (`Promise`, `Symbols`等等) 和静态方法 (`Array.from` 等)。绝大部分转换是这里做的，自动引入。
* `regenerator`：作为 `core-js` 的拾遗补漏，主要是对 `generator/yield` 和 `async/await` 两组的支持。当代码中有使用 `generators/async` 时自动引入。
* `helpers`： 如上面的 `asyncToGenerator` 就是其中之一，其他还有如 `jsx`, `classCallCheck` 等等，可以查看 [babel-helpers](https://github.com/babel/babel/blob/6.x/packages/babel-helpers/src/helpers.js)。

但是这个插件也有**缺点：**`babel-plugin-transform-runtime` **不支持** 类的实例方法 (比如数组的`filter`方法等)

还有一个需要**注意**的是，我发现默认情况下这个插件不会对ES6新的API进行polyfill，就是说它默认不会转化新的特性比如Promise、`Object.assign`。所以我们还需要配置corejs这个字段，并安装对应的依赖`@babel/runtime-corejs2`。

```javascript
npm install --save @babel/runtime-corejs2

{
 "plugins": [
    [
      "@babel/plugin-transform-runtime",
      {
        "helpers": true,
        "regenerator": true,
        "useESModules": false,
        "corejs": 2
      }
    ]
	] 
}
```

### 注意

当plugins 与 presets 同时存在的情况，执行顺序如下

> 这意味着如果两个转换插件都将处理程序的某个代码片段，则将根据转换插件或 preset 的排列顺序依次执行。
>
> - 先执行 plugins 的配置项,再执行 Preset 的配置项；
> - plugins 配置项，按照声明顺序执行。
> - Preset 配置项，按照声明逆序执行。

### Babel插件方案对比

|              方案               |                             优点                             |                    缺点                    |
| :-----------------------------: | :----------------------------------------------------------: | :----------------------------------------: |
| @babel/plugin-transform-runtime |                     按需引入, 打包体积小                     |              不能兼容实例方法              |
|         @babel/polyfill         |                      完整模拟 ES6 环境                       | 打包体积过大, 污染全局对象和内置的对象原型 |
|        @babel/preset-env        | 按需引入, 可配置性高，并且通过配置useBuiltIns实现按需加载@babel/polyfill |                  暂未发现                  |

### 结论

`@babel/plugin-transform-runtime`和`useBuiltIns`配置可以解决替代@babel/polyfill。



## babel使用总结

综上，我个人对于babel 7的配置方案总结如下

* @babel/preset-env + targets + useBuiltins: usage
* @babel/plugin-transform-runtime
* 引入必要的plugin