摘要：回過(guò)頭來(lái)發(fā)現(xiàn)，我們的項(xiàng)目，雖然在服務(wù)端層面做好了日志和性能統(tǒng)計(jì)，但在前端對(duì)異常的監(jiān)控和性能的統(tǒng)計(jì)。對(duì)于前端的性能與異常上報(bào)的可行性探索是有必要的。這是我們頁(yè)面加載性能優(yōu)化需求中主要上報(bào)的相關(guān)信息。

對(duì)于后臺(tái)開發(fā)來(lái)說(shuō)，記錄日志是一種非常常見的開發(fā)習(xí)慣，通常我們會(huì)使用try...catch代碼塊來(lái)主動(dòng)捕獲錯(cuò)誤、對(duì)于每次接口調(diào)用，也會(huì)記錄下每次接口調(diào)用的時(shí)間消耗，以便我們監(jiān)控服務(wù)器接口性能，進(jìn)行問(wèn)題排查。

剛進(jìn)公司時(shí)，在進(jìn)行Node.js的接口開發(fā)時(shí)，我不太習(xí)慣每次排查問(wèn)題都要通過(guò)跳板機(jī)登上服務(wù)器看日志，后來(lái)慢慢習(xí)慣了這種方式。

舉個(gè)例子：

/**
 * 獲取列表數(shù)據(jù)
 * @parma req, res
 */
exports.getList = async function (req, res) {
    //獲取請(qǐng)求參數(shù)
    const openId = req.session.userinfo.openId;
    logger.info(`handler getList, user openId is ${openId}`);

    try {
        // 拿到列表數(shù)據(jù)
        const startTime = new Date().getTime();
        let res = await ListService.getListFromDB(openId);
        logger.info(`handler getList, ListService.getListFromDB cost time ${new Date().getTime() - startDate}`);
        // 對(duì)數(shù)據(jù)處理，返回給前端
        // ...
    } catch(error) {
        logger.error(`handler getList is error, ${JSON.stringify(error)}`);
    }
};

以下代碼經(jīng)常會(huì)出現(xiàn)在用Node.js的接口中，在接口中會(huì)統(tǒng)計(jì)查詢DB所耗時(shí)間、亦或是統(tǒng)計(jì)RPC服務(wù)調(diào)用所耗時(shí)間，以便監(jiān)測(cè)性能瓶頸，對(duì)性能做優(yōu)化；又或是對(duì)異常使用try ... catch主動(dòng)捕獲，以便隨時(shí)對(duì)問(wèn)題進(jìn)行回溯、還原問(wèn)題的場(chǎng)景，進(jìn)行bug的修復(fù)。

而對(duì)于前端來(lái)說(shuō)呢？可以看以下的場(chǎng)景。

最近在進(jìn)行一個(gè)需求開發(fā)時(shí)，偶爾發(fā)現(xiàn)webgl渲染影像失敗的情況，或者說(shuō)影像會(huì)出現(xiàn)解析失敗的情況，我們可能根本不知道哪張影像會(huì)解析或渲染失??；又或如最近開發(fā)的另外一個(gè)需求，我們會(huì)做一個(gè)關(guān)于webgl渲染時(shí)間的優(yōu)化和影像預(yù)加載的需求，如果缺乏性能監(jiān)控，該如何統(tǒng)計(jì)所做的渲染優(yōu)化和影像預(yù)加載優(yōu)化的優(yōu)化比例，如何證明自己所做的事情具有價(jià)值呢？可能是通過(guò)測(cè)試同學(xué)的黑盒測(cè)試，對(duì)優(yōu)化前后的時(shí)間進(jìn)行錄屏，分析從進(jìn)入頁(yè)面到影像渲染完成到底經(jīng)過(guò)了多少幀圖像。這樣的數(shù)據(jù)，可能既不準(zhǔn)確、又較為片面，設(shè)想測(cè)試同學(xué)并不是真正的用戶，也無(wú)法還原真實(shí)的用戶他們所處的網(wǎng)絡(luò)環(huán)境?；剡^(guò)頭來(lái)發(fā)現(xiàn)，我們的項(xiàng)目，雖然在服務(wù)端層面做好了日志和性能統(tǒng)計(jì)，但在前端對(duì)異常的監(jiān)控和性能的統(tǒng)計(jì)。對(duì)于前端的性能與異常上報(bào)的可行性探索是有必要的。

對(duì)于前端來(lái)說(shuō)，我們需要的異常捕獲無(wú)非為以下兩種：

接口調(diào)用情況；

頁(yè)面邏輯是否錯(cuò)誤，例如，用戶進(jìn)入頁(yè)面后頁(yè)面顯示白屏；

對(duì)于接口調(diào)用情況，在前端通常需要上報(bào)客戶端相關(guān)參數(shù)，例如：用戶OS與瀏覽器版本、請(qǐng)求參數(shù)（如頁(yè)面ID）；而對(duì)于頁(yè)面邏輯是否錯(cuò)誤問(wèn)題，通常除了用戶OS與瀏覽器版本外，需要的是報(bào)錯(cuò)的堆棧信息及具體報(bào)錯(cuò)位置。

可以通過(guò)全局監(jiān)聽異常來(lái)捕獲，通過(guò)window.onerror或者addEventListener，看以下例子：

window.onerror = function(errorMessage, scriptURI, lineNo, columnNo, error) {
  console.log("errorMessage: " + errorMessage); // 異常信息
  console.log("scriptURI: " + scriptURI); // 異常文件路徑
  console.log("lineNo: " + lineNo); // 異常行號(hào)
  console.log("columnNo: " + columnNo); // 異常列號(hào)
  console.log("error: " + error); // 異常堆棧信息
  // ...
  // 異常上報(bào)
};
throw new Error("這是一個(gè)錯(cuò)誤");

通過(guò)window.onerror事件，可以得到具體的異常信息、異常文件的URL、異常的行號(hào)與列號(hào)及異常的堆棧信息，再捕獲異常后，統(tǒng)一上報(bào)至我們的日志服務(wù)器。

亦或是，通過(guò)window.addEventListener方法來(lái)進(jìn)行異常上報(bào)，道理同理：

window.addEventListener("error", function() {
  console.log(error);
  // ...
  // 異常上報(bào)
});
throw new Error("這是一個(gè)錯(cuò)誤");

使用try... catch雖然能夠較好地進(jìn)行異常捕獲，不至于使得頁(yè)面由于一處錯(cuò)誤掛掉，但try ... catch捕獲方式顯得過(guò)于臃腫，大多代碼使用try ... catch包裹，影響代碼可讀性。

通常情況下，我們會(huì)把靜態(tài)資源，如JavaScript腳本放到專門的靜態(tài)資源服務(wù)器，亦或者CDN，看以下例子：

// error.js
throw new Error("這是一個(gè)錯(cuò)誤");

結(jié)果顯示，跨域之后window.onerror根本捕獲不到正確的異常信息，而是統(tǒng)一返回一個(gè)Script error，

解決方案：對(duì)script標(biāo)簽增加一個(gè)crossorigin=”anonymous”，并且服務(wù)器添加Access-Control-Allow-Origin。

通常在生產(chǎn)環(huán)境下的代碼是經(jīng)過(guò)webpack打包后壓縮混淆的代碼，所以我們可能會(huì)遇到這樣的問(wèn)題，如圖所示：

我們發(fā)現(xiàn)所有的報(bào)錯(cuò)的代碼行數(shù)都在第一行了，為什么呢？這是因?yàn)樵谏a(chǎn)環(huán)境下，我們的代碼被壓縮成了一行：

!function(e){var n={};function r(o){if(n[o])return n[o].exports;var t=n[o]={i:o,l:!1,exports:{}};return e[o].call(t.exports,t,t.exports,r),t.l=!0,t.exports}r.m=e,r.c=n,r.d=function(e,n,o){r.o(e,n)||Object.defineProperty(e,n,{enumerable:!0,get:o})},r.r=function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},r.t=function(e,n){if(1&n&&(e=r(e)),8&n)return e;if(4&n&&"object"==typeof e&&e&&e.__esModule)return e;var o=Object.create(null);if(r.r(o),Object.defineProperty(o,"default",{enumerable:!0,value:e}),2&n&&"string"!=typeof e)for(var t in e)r.d(o,t,function(n){return e[n]}.bind(null,t));return o},r.n=function(e){var n=e&&e.__esModule?function(){return e.default}:function(){return e};return r.d(n,"a",n),n},r.o=function(e,n){return Object.prototype.hasOwnProperty.call(e,n)},r.p="",r(r.s=0)}([function(e,n){throw window.onerror=function(e,n,r,o,t){console.log("errorMessage: "+e),console.log("scriptURI: "+n),console.log("lineNo: "+r),console.log("columnNo: "+o),console.log("error: "+t);var l={errorMessage:e||null,scriptURI:n||null,lineNo:r||null,columnNo:o||null,stack:t&&t.stack?t.stack:null};if(XMLHttpRequest){var u=new XMLHttpRequest;u.open("post","/middleware/errorMsg",!0),u.setRequestHeader("Content-Type","application/json"),u.send(JSON.stringify(l))}},new Error("這是一個(gè)錯(cuò)誤")}]);

在我的開發(fā)過(guò)程中也遇到過(guò)這個(gè)問(wèn)題，我在開發(fā)一個(gè)功能組件庫(kù)的時(shí)候，使用npm link了我的組件庫(kù)，但是由于組件庫(kù)被npm link后是打包后的生產(chǎn)環(huán)境下的代碼，所有的報(bào)錯(cuò)都定位到了第一行。

解決辦法是開啟webpack的source-map，我們利用webpack打包后的生成的一份.map的腳本文件就可以讓瀏覽器對(duì)錯(cuò)誤位置進(jìn)行追蹤了。此處可以參考webpack document。

其實(shí)就是webpack.config.js中加上一行devtool: "source-map"，如下所示，為示例的webpack.config.js：

var path = require("path");
module.exports = {
    devtool: "source-map",
    mode: "development",
    entry: "./client/index.js",
    output: {
        filename: "bundle.js",
        path: path.resolve(__dirname, "client")
    }
}

在webpack打包后生成對(duì)應(yīng)的source-map，這樣瀏覽器就能夠定位到具體錯(cuò)誤的位置：

開啟source-map的缺陷是兼容性，目前只有Chrome瀏覽器和Firefox瀏覽器才對(duì)source-map支持。不過(guò)我們對(duì)這一類情況也有解決辦法。可以使用引入npm庫(kù)來(lái)支持source-map，可以參考mozilla/source-map。這個(gè)npm庫(kù)既可以運(yùn)行在客戶端也可以運(yùn)行在服務(wù)端，不過(guò)更為推薦的是在服務(wù)端使用Node.js對(duì)接收到的日志信息時(shí)使用source-map解析，以避免源代碼的泄露造成風(fēng)險(xiǎn)，如下代碼所示：

const express = require("express");
const fs = require("fs");
const router = express.Router();
const sourceMap = require("source-map");
const path = require("path");
const resolve = file => path.resolve(__dirname, file);
// 定義post接口
router.get("/error/", async function(req, res) {
    // 獲取前端傳過(guò)來(lái)的報(bào)錯(cuò)對(duì)象
    let error = JSON.parse(req.query.error);
    let url = error.scriptURI; // 壓縮文件路徑
    if (url) {
        let fileUrl = url.slice(url.indexOf("client/")) + ".map"; // map文件路徑
        // 解析sourceMap
        let consumer = await new sourceMap.SourceMapConsumer(fs.readFileSync(resolve("../" + fileUrl), "utf8")); // 返回一個(gè)promise對(duì)象
        // 解析原始報(bào)錯(cuò)數(shù)據(jù)
        let result = consumer.originalPositionFor({
            line: error.lineNo, // 壓縮后的行號(hào)
            column: error.columnNo // 壓縮后的列號(hào)
        });
        console.log(result);
    }
});
module.exports = router;

如下圖所示，我們已經(jīng)可以看到，在服務(wù)端已經(jīng)成功解析出了具體錯(cuò)誤的行號(hào)、列號(hào)，我們可以通過(guò)日志的方式進(jìn)行記錄，達(dá)到了前端異常監(jiān)控的目的。

在我的項(xiàng)目中就遇到這樣的問(wèn)題，使用了js-tracker這樣的插件來(lái)統(tǒng)一進(jìn)行全局的異常捕獲和日志上報(bào)，結(jié)果發(fā)現(xiàn)我們根本捕獲不到Vue組件的異常，查閱資料得知，在Vue中，異?？赡鼙?b>Vue自身給try ... catch了，不會(huì)傳到window.onerror事件觸發(fā)，那么我們?nèi)绾伟?b>Vue組件中的異常作統(tǒng)一捕獲呢？

使用Vue.config.errorHandler這樣的Vue全局配置，可以在Vue指定組件的渲染和觀察期間未捕獲錯(cuò)誤的處理函數(shù)。這個(gè)處理函數(shù)被調(diào)用時(shí)，可獲取錯(cuò)誤信息和Vue 實(shí)例。

Vue.config.errorHandler = function (err, vm, info) {
  // handle error
  // `info` 是 Vue 特定的錯(cuò)誤信息，比如錯(cuò)誤所在的生命周期鉤子
  // 只在 2.2.0+ 可用
}

在React中，可以使用ErrorBoundary組件包括業(yè)務(wù)組件的方式進(jìn)行異常捕獲，配合React 16.0+新出的componentDidCatch API，可以實(shí)現(xiàn)統(tǒng)一的異常捕獲和日志上報(bào)。

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  componentDidCatch(error, info) {
    // Display fallback UI
    this.setState({ hasError: true });
    // You can also log the error to an error reporting service
    logErrorToMyService(error, info);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return 
Something went wrong.
;
    }
    return this.props.children;
  }
}

使用方式如下：

最常見的性能監(jiān)控需求則是需要我們統(tǒng)計(jì)用戶從開始請(qǐng)求頁(yè)面到所有DOM元素渲染完成的時(shí)間，也就是俗稱的首屏加載時(shí)間，DOM提供了這一接口，監(jiān)聽document的DOMContentLoaded事件與window的load事件可統(tǒng)計(jì)頁(yè)面首屏加載時(shí)間即所有DOM渲染時(shí)間：

對(duì)于使用框架，如Vue或者說(shuō)React，組件是異步渲染然后掛載到DOM的，在頁(yè)面初始化時(shí)并沒有太多的DOM節(jié)點(diǎn)，可以參考下文關(guān)于首屏?xí)r間采集自動(dòng)化的解決方案來(lái)對(duì)渲染時(shí)間進(jìn)行打點(diǎn)。

但是以上時(shí)間的監(jiān)控過(guò)于粗略，例如我們想統(tǒng)計(jì)文檔的網(wǎng)絡(luò)加載耗時(shí)、解析DOM的耗時(shí)與渲染DOM的耗時(shí)，就不太好辦到了，所幸的是瀏覽器提供了window.performance接口，具體可見MDN文檔

幾乎所有瀏覽器都支持window.performance接口，下面來(lái)看看在控制臺(tái)打印window.performance可以得到些什么：

可以看到，window,performance主要包括有memory、navigation、timing以及timeOrigin及onresourcetimingbufferfull方法。

navigation對(duì)象提供了在指定的時(shí)間段里發(fā)生的操作相關(guān)信息，包括頁(yè)面是加載還是刷新、發(fā)生了多少次重定向等等。

timing對(duì)象包含延遲相關(guān)的性能信息。這是我們頁(yè)面加載性能優(yōu)化需求中主要上報(bào)的相關(guān)信息。

memory為Chrome添加的一個(gè)非標(biāo)準(zhǔn)擴(kuò)展，這個(gè)屬性提供了一個(gè)可以獲取到基本內(nèi)存使用情況的對(duì)象。在其它瀏覽器應(yīng)該考慮到這個(gè)API的兼容處理。

timeOrigin則返回性能測(cè)量開始時(shí)的時(shí)間的高精度時(shí)間戳。如圖所示，精確到了小數(shù)點(diǎn)后四位。

onresourcetimingbufferfull方法，它是一個(gè)在resourcetimingbufferfull事件觸發(fā)時(shí)會(huì)被調(diào)用的event handler。這個(gè)事件當(dāng)瀏覽器的資源時(shí)間性能緩沖區(qū)已滿時(shí)會(huì)觸發(fā)?？梢酝ㄟ^(guò)監(jiān)聽這一事件觸發(fā)來(lái)預(yù)估頁(yè)面crash，統(tǒng)計(jì)頁(yè)面crash概率，以便后期的性能優(yōu)化，如下示例所示：

function buffer_full(event) {
  console.log("WARNING: Resource Timing Buffer is FULL!");
  performance.setResourceTimingBufferSize(200);
}
function init() {
  // Set a callback if the resource buffer becomes filled
  performance.onresourcetimingbufferfull = buffer_full;
}

使用performance的timing屬性，可以拿到頁(yè)面性能相關(guān)的數(shù)據(jù)，這里在很多文章都有提到關(guān)于利用window.performance.timing記錄頁(yè)面性能的文章，例如alloyteam團(tuán)隊(duì)寫的初探 performance – 監(jiān)控網(wǎng)頁(yè)與程序性能，對(duì)于timing的各項(xiàng)屬性含義，可以借助摘自此文的下圖理解，以下代碼摘自此文作為計(jì)算網(wǎng)站性能的工具函數(shù)參考：

// 獲取 performance 數(shù)據(jù)
var performance = {  
    // memory 是非標(biāo)準(zhǔn)屬性，只在 Chrome 有
    // 財(cái)富問(wèn)題：我有多少內(nèi)存
    memory: {
        usedJSHeapSize:  16100000, // JS 對(duì)象（包括V8引擎內(nèi)部對(duì)象）占用的內(nèi)存，一定小于 totalJSHeapSize
        totalJSHeapSize: 35100000, // 可使用的內(nèi)存
        jsHeapSizeLimit: 793000000 // 內(nèi)存大小限制
    },
 
    //  哲學(xué)問(wèn)題：我從哪里來(lái)？
    navigation: {
        redirectCount: 0, // 如果有重定向的話，頁(yè)面通過(guò)幾次重定向跳轉(zhuǎn)而來(lái)
        type: 0           // 0   即 TYPE_NAVIGATENEXT 正常進(jìn)入的頁(yè)面（非刷新、非重定向等）
                          // 1   即 TYPE_RELOAD       通過(guò) window.location.reload() 刷新的頁(yè)面
                          // 2   即 TYPE_BACK_FORWARD 通過(guò)瀏覽器的前進(jìn)后退按鈕進(jìn)入的頁(yè)面（歷史記錄）
                          // 255 即 TYPE_UNDEFINED    非以上方式進(jìn)入的頁(yè)面
    },
 
    timing: {
        // 在同一個(gè)瀏覽器上下文中，前一個(gè)網(wǎng)頁(yè)（與當(dāng)前頁(yè)面不一定同域）unload 的時(shí)間戳，如果無(wú)前一個(gè)網(wǎng)頁(yè) unload ，則與 fetchStart 值相等
        navigationStart: 1441112691935,
 
        // 前一個(gè)網(wǎng)頁(yè)（與當(dāng)前頁(yè)面同域）unload 的時(shí)間戳，如果無(wú)前一個(gè)網(wǎng)頁(yè) unload 或者前一個(gè)網(wǎng)頁(yè)與當(dāng)前頁(yè)面不同域，則值為 0
        unloadEventStart: 0,
 
        // 和 unloadEventStart 相對(duì)應(yīng)，返回前一個(gè)網(wǎng)頁(yè) unload 事件綁定的回調(diào)函數(shù)執(zhí)行完畢的時(shí)間戳
        unloadEventEnd: 0,
 
        // 第一個(gè) HTTP 重定向發(fā)生時(shí)的時(shí)間。有跳轉(zhuǎn)且是同域名內(nèi)的重定向才算，否則值為 0 
        redirectStart: 0,
 
        // 最后一個(gè) HTTP 重定向完成時(shí)的時(shí)間。有跳轉(zhuǎn)且是同域名內(nèi)部的重定向才算，否則值為 0 
        redirectEnd: 0,
 
        // 瀏覽器準(zhǔn)備好使用 HTTP 請(qǐng)求抓取文檔的時(shí)間，這發(fā)生在檢查本地緩存之前
        fetchStart: 1441112692155,
 
        // DNS 域名查詢開始的時(shí)間，如果使用了本地緩存（即無(wú) DNS 查詢）或持久連接，則與 fetchStart 值相等
        domainLookupStart: 1441112692155,
 
        // DNS 域名查詢完成的時(shí)間，如果使用了本地緩存（即無(wú) DNS 查詢）或持久連接，則與 fetchStart 值相等
        domainLookupEnd: 1441112692155,
 
        // HTTP（TCP） 開始建立連接的時(shí)間，如果是持久連接，則與 fetchStart 值相等
        // 注意如果在傳輸層發(fā)生了錯(cuò)誤且重新建立連接，則這里顯示的是新建立的連接開始的時(shí)間
        connectStart: 1441112692155,
 
        // HTTP（TCP） 完成建立連接的時(shí)間（完成握手），如果是持久連接，則與 fetchStart 值相等
        // 注意如果在傳輸層發(fā)生了錯(cuò)誤且重新建立連接，則這里顯示的是新建立的連接完成的時(shí)間
        // 注意這里握手結(jié)束，包括安全連接建立完成、SOCKS 授權(quán)通過(guò)
        connectEnd: 1441112692155,
 
        // HTTPS 連接開始的時(shí)間，如果不是安全連接，則值為 0
        secureConnectionStart: 0,
 
        // HTTP 請(qǐng)求讀取真實(shí)文檔開始的時(shí)間（完成建立連接），包括從本地讀取緩存
        // 連接錯(cuò)誤重連時(shí)，這里顯示的也是新建立連接的時(shí)間
        requestStart: 1441112692158,
 
        // HTTP 開始接收響應(yīng)的時(shí)間（獲取到第一個(gè)字節(jié)），包括從本地讀取緩存
        responseStart: 1441112692686,
 
        // HTTP 響應(yīng)全部接收完成的時(shí)間（獲取到最后一個(gè)字節(jié)），包括從本地讀取緩存
        responseEnd: 1441112692687,
 
        // 開始解析渲染 DOM 樹的時(shí)間，此時(shí) Document.readyState 變?yōu)?loading，并將拋出 readystatechange 相關(guān)事件
        domLoading: 1441112692690,
 
        // 完成解析 DOM 樹的時(shí)間，Document.readyState 變?yōu)?interactive，并將拋出 readystatechange 相關(guān)事件
        // 注意只是 DOM 樹解析完成，這時(shí)候并沒有開始加載網(wǎng)頁(yè)內(nèi)的資源
        domInteractive: 1441112693093,
 
        // DOM 解析完成后，網(wǎng)頁(yè)內(nèi)資源加載開始的時(shí)間
        // 在 DOMContentLoaded 事件拋出前發(fā)生
        domContentLoadedEventStart: 1441112693093,
 
        // DOM 解析完成后，網(wǎng)頁(yè)內(nèi)資源加載完成的時(shí)間（如 JS 腳本加載執(zhí)行完畢）
        domContentLoadedEventEnd: 1441112693101,
 
        // DOM 樹解析完成，且資源也準(zhǔn)備就緒的時(shí)間，Document.readyState 變?yōu)?complete，并將拋出 readystatechange 相關(guān)事件
        domComplete: 1441112693214,
 
        // load 事件發(fā)送給文檔，也即 load 回調(diào)函數(shù)開始執(zhí)行的時(shí)間
        // 注意如果沒有綁定 load 事件，值為 0
        loadEventStart: 1441112693214,
 
        // load 事件的回調(diào)函數(shù)執(zhí)行完畢的時(shí)間
        loadEventEnd: 1441112693215
 
        // 字母順序
        // connectEnd: 1441112692155,
        // connectStart: 1441112692155,
        // domComplete: 1441112693214,
        // domContentLoadedEventEnd: 1441112693101,
        // domContentLoadedEventStart: 1441112693093,
        // domInteractive: 1441112693093,
        // domLoading: 1441112692690,
        // domainLookupEnd: 1441112692155,
        // domainLookupStart: 1441112692155,
        // fetchStart: 1441112692155,
        // loadEventEnd: 1441112693215,
        // loadEventStart: 1441112693214,
        // navigationStart: 1441112691935,
        // redirectEnd: 0,
        // redirectStart: 0,
        // requestStart: 1441112692158,
        // responseEnd: 1441112692687,
        // responseStart: 1441112692686,
        // secureConnectionStart: 0,
        // unloadEventEnd: 0,
        // unloadEventStart: 0
    }
};

// 計(jì)算加載時(shí)間
function getPerformanceTiming() {
    var performance = window.performance;
    if (!performance) {
        // 當(dāng)前瀏覽器不支持
        console.log("你的瀏覽器不支持 performance 接口");
        return;
    }
    var t = performance.timing;
    var times = {};
    //【重要】頁(yè)面加載完成的時(shí)間
    //【原因】這幾乎代表了用戶等待頁(yè)面可用的時(shí)間
    times.loadPage = t.loadEventEnd - t.navigationStart;
    //【重要】解析 DOM 樹結(jié)構(gòu)的時(shí)間
    //【原因】反省下你的 DOM 樹嵌套是不是太多了！
    times.domReady = t.domComplete - t.responseEnd;
    //【重要】重定向的時(shí)間
    //【原因】拒絕重定向！比如，http://example.com/ 就不該寫成 http://example.com
    times.redirect = t.redirectEnd - t.redirectStart;
    //【重要】DNS 查詢時(shí)間
    //【原因】DNS 預(yù)加載做了么？頁(yè)面內(nèi)是不是使用了太多不同的域名導(dǎo)致域名查詢的時(shí)間太長(zhǎng)？
    // 可使用 HTML5 Prefetch 預(yù)查詢 DNS ，見：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)            
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;
    //【重要】讀取頁(yè)面第一個(gè)字節(jié)的時(shí)間
    //【原因】這可以理解為用戶拿到你的資源占用的時(shí)間，加異地機(jī)房了么，加CDN 處理了么？加帶寬了么？加 CPU 運(yùn)算速度了么？
    // TTFB 即 Time To First Byte 的意思
    // 維基百科：https://en.wikipedia.org/wiki/Time_To_First_Byte
    times.ttfb = t.responseStart - t.navigationStart;
    //【重要】?jī)?nèi)容加載完成的時(shí)間
    //【原因】頁(yè)面內(nèi)容經(jīng)過(guò) gzip 壓縮了么，靜態(tài)資源 css/js 等壓縮了么？
    times.request = t.responseEnd - t.requestStart;
    //【重要】執(zhí)行 onload 回調(diào)函數(shù)的時(shí)間
    //【原因】是否太多不必要的操作都放到 onload 回調(diào)函數(shù)里執(zhí)行了，考慮過(guò)延遲加載、按需加載的策略么？
    times.loadEvent = t.loadEventEnd - t.loadEventStart;
    // DNS 緩存時(shí)間
    times.appcache = t.domainLookupStart - t.fetchStart;
    // 卸載頁(yè)面的時(shí)間
    times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;
    // TCP 建立連接完成握手的時(shí)間
    times.connect = t.connectEnd - t.connectStart;
    return times;
}

對(duì)于日志上報(bào)使用多帶帶的日志域名的目的是避免對(duì)業(yè)務(wù)造成影響。其一，對(duì)于服務(wù)器來(lái)說(shuō)，我們肯定不希望占用業(yè)務(wù)服務(wù)器的計(jì)算資源，也不希望過(guò)多的日志在業(yè)務(wù)服務(wù)器堆積，造成業(yè)務(wù)服務(wù)器的存儲(chǔ)空間不夠的情況。其二，我們知道在頁(yè)面初始化的過(guò)程中，會(huì)對(duì)頁(yè)面加載時(shí)間、PV、UV等數(shù)據(jù)進(jìn)行上報(bào)，這些上報(bào)請(qǐng)求會(huì)和加載業(yè)務(wù)數(shù)據(jù)幾乎是同時(shí)刻發(fā)出，而瀏覽器一般會(huì)對(duì)同一個(gè)域名的請(qǐng)求量有并發(fā)數(shù)的限制，如Chrome會(huì)有對(duì)并發(fā)數(shù)為6個(gè)的限制。因此需要對(duì)日志系統(tǒng)多帶帶設(shè)定域名，最小化對(duì)頁(yè)面加載性能造成的影響。

對(duì)于多帶帶的日志域名，肯定會(huì)涉及到跨域的問(wèn)題，采取的解決方案一般有以下兩種：

一種是構(gòu)造空的Image對(duì)象的方式，其原因是請(qǐng)求圖片并不涉及到跨域的問(wèn)題；

var url = "xxx";
new Image().src = url;

利用Ajax上報(bào)日志，必須對(duì)日志服務(wù)器接口開啟跨域請(qǐng)求頭部Access-Control-Allow-Origin:*，這里Ajax就并不強(qiáng)制使用GET請(qǐng)求了，即可克服URL長(zhǎng)度限制的問(wèn)題。

if (XMLHttpRequest) {
  var xhr = new XMLHttpRequest();
  xhr.open("post", "https://log.xxx.com", true); // 上報(bào)給node中間層處理
  xhr.setRequestHeader("Content-Type", "application/json"); // 設(shè)置請(qǐng)求頭
  xhr.send(JSON.stringify(errorObj)); // 發(fā)送參數(shù)
}

在我的項(xiàng)目中使用的是第一種的方式，也就是構(gòu)造空的Image對(duì)象，但是我們知道對(duì)于GET請(qǐng)求會(huì)有長(zhǎng)度的限制，需要確保的是請(qǐng)求的長(zhǎng)度不會(huì)超過(guò)閾值。

對(duì)于我們上報(bào)日志，其實(shí)對(duì)于客戶端來(lái)說(shuō)，并不需要考慮上報(bào)的結(jié)果，甚至對(duì)于上報(bào)失敗，我們也不需要在前端做任何交互，所以上報(bào)來(lái)說(shuō)，其實(shí)使用HEAD請(qǐng)求就夠了，接口返回空的結(jié)果，最大地減少上報(bào)日志造成的資源浪費(fèi)。

類似于雪碧圖的思想，如果我們的應(yīng)用需要上報(bào)的日志數(shù)量很多，那么有必要合并日志進(jìn)行統(tǒng)一的上報(bào)。

解決方案可以是嘗試在用戶離開頁(yè)面或者組件銷毀時(shí)發(fā)送一個(gè)異步的POST請(qǐng)求來(lái)進(jìn)行上報(bào)，但是嘗試在卸載（unload）文檔之前向web服務(wù)器發(fā)送數(shù)據(jù)。保證在文檔卸載期間發(fā)送數(shù)據(jù)一直是一個(gè)困難。因?yàn)橛脩舸硗ǔ?huì)忽略在卸載事件處理器中產(chǎn)生的異步XMLHttpRequest，因?yàn)榇藭r(shí)已經(jīng)會(huì)跳轉(zhuǎn)到下一個(gè)頁(yè)面。所以這里是必須設(shè)置為同步的XMLHttpRequest請(qǐng)求嗎？

window.addEventListener("unload", logData, false);

function logData() {
    var client = new XMLHttpRequest();
    client.open("POST", "/log", false); // 第三個(gè)參數(shù)表明是同步的 xhr
    client.setRequestHeader("Content-Type", "text/plain;charset=UTF-8");
    client.send(analyticsData);
}

使用同步的方式勢(shì)必會(huì)對(duì)用戶體驗(yàn)造成影響，甚至?xí)層脩舾惺艿綖g覽器卡死感覺，對(duì)于產(chǎn)品而言，體驗(yàn)非常不好，通過(guò)查閱MDN文檔，可以使用sendBeacon()方法，將會(huì)使用戶代理在有機(jī)會(huì)時(shí)異步地向服務(wù)器發(fā)送數(shù)據(jù)，同時(shí)不會(huì)延遲頁(yè)面的卸載或影響下一導(dǎo)航的載入性能。這就解決了提交分析數(shù)據(jù)時(shí)的所有的問(wèn)題：使它可靠，異步并且不會(huì)影響下一頁(yè)面的加載。此外，代碼實(shí)際上還要比其他技術(shù)簡(jiǎn)單！

下面的例子展示了一個(gè)理論上的統(tǒng)計(jì)代碼模式——通過(guò)使用sendBeacon()方法向服務(wù)器發(fā)送數(shù)據(jù)。

window.addEventListener("unload", logData, false);

function logData() {
    navigator.sendBeacon("/log", analyticsData);
}

作為前端開發(fā)者而言，要對(duì)產(chǎn)品保持敬畏之心，時(shí)刻保持對(duì)性能追求極致，對(duì)異常不可容忍的態(tài)度。前端的性能監(jiān)控與異常上報(bào)顯得尤為重要。

代碼難免有問(wèn)題，對(duì)于異常可以使用window.onerror或者addEventListener的方式添加全局的異常捕獲偵聽函數(shù)，但可能使用這種方式無(wú)法正確捕獲到錯(cuò)誤：對(duì)于跨域的腳本，需要對(duì)script標(biāo)簽增加一個(gè)crossorigin=”anonymous”；對(duì)于生產(chǎn)環(huán)境打包的代碼，無(wú)法正確定位到異常產(chǎn)生的行數(shù)，可以使用source-map來(lái)解決；而對(duì)于使用框架的情況，需要在框架統(tǒng)一的異常捕獲處埋點(diǎn)。

而對(duì)于性能的監(jiān)控，所幸的是瀏覽器提供了window.performance API，通過(guò)這個(gè)API，很便捷地獲取到當(dāng)前頁(yè)面性能相關(guān)的數(shù)據(jù)。

而這些異常和性能數(shù)據(jù)如何上報(bào)呢？一般說(shuō)來(lái)，為了避免對(duì)業(yè)務(wù)產(chǎn)生的影響，會(huì)多帶帶建立日志服務(wù)器和日志域名，但對(duì)于不同的域名，又會(huì)產(chǎn)生跨域的問(wèn)題。我們可以通過(guò)構(gòu)造空的Image對(duì)象來(lái)解決，亦或是通過(guò)設(shè)定跨域請(qǐng)求頭部Access-Control-Allow-Origin:*來(lái)解決。此外，如果上報(bào)的性能和日志數(shù)據(jù)高頻觸發(fā)，則可以在頁(yè)面unload時(shí)統(tǒng)一上報(bào)，而unload時(shí)的異步請(qǐng)求又可能會(huì)被瀏覽器所忽略，且不能改為同步請(qǐng)求。此時(shí)navigator.sendBeacon API可算幫了我們大忙，它可用于通過(guò)HTTP將少量數(shù)據(jù)異步傳輸?shù)?b>Web服務(wù)器。而忽略頁(yè)面unload時(shí)的影響。