掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
前端優(yōu)化是一個(gè)大的課題，需要花好多時(shí)間才能理解，之前對(duì)前端優(yōu)化陸陸續(xù)續(xù)有一些了解。所以這次從渲染優(yōu)化，打包優(yōu)化，代碼優(yōu)化做了一個(gè)系統(tǒng)的總結(jié)，并且引申出了幾個(gè)需要關(guān)注的問題，文章可能有點(diǎn)長，大家一定要看到最后。最后寫作不易，希望覺得還可以的話，幫忙點(diǎn)贊一波，提前感謝了。當(dāng)然如果有寫不好的地方，也請(qǐng)指出來，我會(huì)積極改進(jìn)，共同成長。
創(chuàng)新互聯(lián)-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比溫宿網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式溫宿網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋溫宿地區(qū)。費(fèi)用合理售后完善，十載實(shí)體公司更值得信賴。
渲染優(yōu)化
渲染優(yōu)化是前端優(yōu)化中一個(gè)很重要的部分，一個(gè)好的首屏?xí)r間能給用戶帶來很好的體驗(yàn)，這里要說的一點(diǎn)是關(guān)于首屏?xí)r間的定義，不同的團(tuán)隊(duì)對(duì)首屏?xí)r間定義不一樣，有的團(tuán)隊(duì)認(rèn)為首屏?xí)r間就是白屏?xí)r間，是從頁面加載到第一個(gè)畫面出現(xiàn)的時(shí)間。但是當(dāng)我們說到用戶體驗(yàn)的時(shí)候，僅僅是這樣還達(dá)不到效果，所以有的前端團(tuán)隊(duì)認(rèn)為，首屏?xí)r間應(yīng)該是從頁面加載到用戶可以進(jìn)行正常的頁面操作時(shí)間，那么我們就依照后者來進(jìn)行說明
js css 加載順序
說渲染優(yōu)化之前，我們還需要說一個(gè)小插曲，就是比較經(jīng)典的一道問題"瀏覽器地址欄輸入url發(fā)生了什么"，理解了這個(gè)我們才可以更清楚js,css加載順序?qū)︿秩镜挠绊?/p>
問題 1：地址欄輸入url 發(fā)生了什么
這個(gè)問題經(jīng)常被人提起，有人回答比較簡潔點(diǎn)，有人可能回答的比較詳細(xì)，下面就說一下主要流程
問題 2：js css 順序?qū)η岸藘?yōu)化影響
上面我們說到了整個(gè)渲染流程，但是沒有說到 css 和 js 對(duì)渲染的影響。渲染樹的構(gòu)成必須要 DOM 樹和 CSSOM 樹的，所以盡快的構(gòu)建 CSSOM 樹是一個(gè)重要的優(yōu)化手段，如果 css 文件放在尾部，那么整個(gè)過程就是一個(gè)串行的過程先解析了 dom，再去解析 css。所以 css 我們一般都是放在頭部，這樣 DOM 樹和 CSSOM 樹的構(gòu)建是同步進(jìn)行的。
再來看 js，因?yàn)?js 的運(yùn)行會(huì)阻止 DOM 樹的渲染的，所以一旦我們的 js 放在了頭部，而且也沒有異步加載這些操作的話，js 一旦一直在運(yùn)行，DOM 樹就一直構(gòu)建不出來，那么頁面就會(huì)一直出現(xiàn)白屏界面，所以一般我們會(huì)把 js 文件放在尾部。當(dāng)然放到尾部也不是就沒有問題了，只是問題相對(duì)較小，放到尾部的 js 文件如果過大，運(yùn)行時(shí)間長，代碼加載時(shí)，就會(huì)有大量耗時(shí)的操作造成頁面不可點(diǎn)擊，這就是另一個(gè)問題，但這肯定比白屏要好，白屏是什么頁面都沒有，這種是頁面有了只是操作不流暢。
js 腳本放在尾部還有一個(gè)原因，有時(shí)候 js 代碼會(huì)有操作 dom 節(jié)點(diǎn)的情況，如果放在頭部執(zhí)行，DOM樹還沒有構(gòu)建，拿不到 DOM 節(jié)點(diǎn)但是你又去使用就會(huì)出現(xiàn)報(bào)錯(cuò)情況，錯(cuò)誤沒處理好的話頁面會(huì)直接崩掉
問題 3：重排重繪為什么會(huì)影響渲染，如何避免?
重排和重繪為什么會(huì)影響渲染，哪個(gè)影響更大，如何避免是經(jīng)常被問到的一道題目，我們先來說一下重繪
重繪指的是不影響界面布局的操作，比如更改顏色，那么根據(jù)上面的渲染講解我們知道，重繪之后我們只需要在重復(fù)進(jìn)行一下樣式計(jì)算，就可以直接渲染了，對(duì)瀏覽器渲染的影響相對(duì)較小
重排指的是影響界面布局的操作，比如改變寬高，隱藏節(jié)點(diǎn)等。對(duì)于重排就不是一個(gè)重新計(jì)算樣式那么簡單了，因?yàn)楦淖兞瞬季郑鶕?jù)上面的渲染流程來看涉及到的階段有樣式計(jì)算，布局樹 重新生成，分層樹重新生成，所以重排對(duì)瀏覽器的渲染影響是比較高的
問題 4：瀏覽器緩存機(jī)制
瀏覽器緩存是比較常見的問題，我會(huì)從瀏覽器緩存的方式，緩存的實(shí)現(xiàn)， 緩存在哪里這幾個(gè)點(diǎn)來說明
緩存方式
我們經(jīng)常說的瀏覽器緩存有兩種，一種是強(qiáng)制緩存，一種是協(xié)商緩存，因?yàn)橄旅嬗芯唧w實(shí)現(xiàn)講解，所以這里就說一下概念
協(xié)商緩存意思是文件已經(jīng)被緩存了，但是否從緩存中讀取是需要和服務(wù)器進(jìn)行協(xié)商，具體如何協(xié)商要看請(qǐng)求頭/響應(yīng)頭的字段設(shè)置，下面會(huì)說到。需要注意的是協(xié)商緩存還是發(fā)了請(qǐng)求的
強(qiáng)制緩存就是文件直接從緩存中獲取，不需要發(fā)送請(qǐng)求
緩存實(shí)現(xiàn)
強(qiáng)制緩存在 http1.0 的時(shí)候用的是 Expires，是響應(yīng)頭里面的一個(gè)字段表示的是文件過期時(shí)間。是一個(gè)絕對(duì)時(shí)間，正因?yàn)槭墙^對(duì)時(shí)間所以在某些情況下，服務(wù)器的時(shí)區(qū)和瀏覽器時(shí)區(qū)不一致的時(shí)候就會(huì)導(dǎo)致緩存失效。為了解決這個(gè)問題，HTPP1.1 引入了一個(gè)新的響應(yīng)頭 cache-control 它的可選值如下
cache-control
HTTP1.1 利用的就是 max-age:600 來強(qiáng)制緩存，因?yàn)槭窍鄬?duì)時(shí)間，所以不會(huì)出現(xiàn) Expires 問題
協(xié)商緩存是利用 Last-Modified/if-Modified-Since,Etag/if-None-Match 這兩對(duì)請(qǐng)求、響應(yīng)頭。
Last-Modified/if-Modified-Since
Etag/If-None-Match
由于 Last-Modified 的時(shí)間粒度是秒，有的文件在 1s 內(nèi)可能被改動(dòng)多次。這種方式在這種特殊情況下還是會(huì)失效，所以HTTP1.1又引入了 Etag 字段。這個(gè)字段是根據(jù)文件內(nèi)容生成一個(gè)標(biāo)記符比如"W/"5f9583bd-10a8""，然后再和 If-None-Match 進(jìn)行對(duì)比就能更準(zhǔn)確的知道文件有沒有被改動(dòng)過
緩存在哪里
知道了緩存方式和實(shí)現(xiàn)，再來說一下緩存存在哪個(gè)地方，我們打開掘金可以看到如下的信息 。緩存的來源有兩個(gè)地方 from dist cache,from memeory cache
form memory cache
這個(gè)是緩存在內(nèi)存里面，優(yōu)點(diǎn)是快速，但是具有時(shí)效性，當(dāng)關(guān)閉 tab 時(shí)候緩存就會(huì)失效。
from dist cache
這個(gè)是緩存在磁盤里面，雖然慢但是還是比請(qǐng)求快，優(yōu)點(diǎn)是緩存可以一直被保留，即使關(guān)閉 tab 頁，也會(huì)一直存在
何時(shí)緩存在memory,合適緩存在dist？
這個(gè)問題網(wǎng)上很少找的到標(biāo)準(zhǔn)答案，大家一致的說法是js,圖片文件瀏覽器會(huì)自動(dòng)保存在memory中，css文件因?yàn)椴怀Ｐ薷谋４嬖赿ist里面，我們可以打開掘金網(wǎng)站，很大一部分文件都是按照這個(gè)規(guī)則來的，但是也有少數(shù)js文件也是緩存在dist里面。所以他的存放機(jī)制到底是什么樣了？我?guī)е@個(gè)疑問查了好多文章，雖然最后沒有確切找到答案，但是一個(gè)知乎的回答可以給我們提供思路，下面引用一個(gè)知乎回答者一段話
上面幾點(diǎn)是雖然很幽默，但是卻可以從中找到一部分答案，但是我覺得另一個(gè)知乎回答我更贊同
瀏覽器運(yùn)行的時(shí)候也是由幾個(gè)進(jìn)程協(xié)作的，所以操作系統(tǒng)為了節(jié)省內(nèi)存，會(huì)把一部分內(nèi)存里的資源交換回磁盤的交換區(qū)，當(dāng)然交換是有策略的，比如最常用的就是LRU。
什么時(shí)候存dist，什么時(shí)候存memoey都是在瀏覽器控制下的，memory不夠了可能就會(huì)考慮去存dist了，所以經(jīng)過上面所說我自己總結(jié)結(jié)果如下
問題 5：https 和 http 的區(qū)別
說到https和http的區(qū)別，可以說一下https服務(wù)器和客戶端連接的差異，以及https特定的加密算法協(xié)商，甚至可能還要說到對(duì)稱加密，非對(duì)稱加密和證書等，篇幅很長，請(qǐng)看我之前單獨(dú)寫的一篇https詳解，里面講的非常詳細(xì)。
請(qǐng)求優(yōu)化
講請(qǐng)求優(yōu)化的之前先來總結(jié)下上面說到的js, css文件順序優(yōu)化，為了讓渲染更快，我們需要把js放到尾部，css放到頭部，然后還要注意在書寫js的時(shí)候盡量減少重排，重繪。書寫html,css的時(shí)候盡量簡潔，不要冗余，目的是為了更快的構(gòu)建DOM樹和CSSOM樹。好了下面我們?cè)趤碚f說請(qǐng)求優(yōu)化，請(qǐng)求優(yōu)化可以從請(qǐng)求數(shù)量和請(qǐng)求時(shí)間兩方面入手
減少請(qǐng)求數(shù)量
減少請(qǐng)求時(shí)間
webpack優(yōu)化
介紹了渲染優(yōu)化，現(xiàn)在來看看webpack優(yōu)化，自己平常寫demo給團(tuán)隊(duì)做培訓(xùn)的時(shí)候都是自己手寫webpack配置，雖然也就幾十行，但每次都能讓我鞏固webpack的基本配置，下面直接說一下webpack優(yōu)化手段有哪些
基礎(chǔ)配置優(yōu)化
- resolve: {
- extensions: ['.ts', '.tsx', '.js']
- }
這個(gè)配置表示webpack會(huì)根據(jù)extensions去尋找文件后綴名，所以如果我們的項(xiàng)目主要用ts寫的話，那我們就可以.tsx和.ts寫前面，目的是為了讓webpack能夠快速解析
- resolve: {
- alias: {
- Components: path.resolve(__dirname, './src/components')
- }
- }
noParse表示不需要解析的文件，有的文件可能是來自第三方的文件，被 providePlugin引入作為windows上的變量來使用，這樣的文件相對(duì)比較大，并且已經(jīng)是被打包過的，所以把這種文件排除在外是很有必要的，配置如下
- module: {
- noParse: [/proj4\.js/]
- }
某些loader會(huì)有這樣一個(gè)屬性，目的是指定loader作用的范圍，exclude表示排除某些文件不需要babel-loader處理，loader的作用范圍小了，打包速度自然就快了，用babel-loader舉一個(gè)簡單例子
- {
- test: /\.js$/,
- loader: "babel-loader",
- exclude: path.resolve(__dirname, 'node_modules')
- }
這個(gè)配置是一個(gè)調(diào)試項(xiàng)，不同的配置展示效果不一樣，打包大小和打包速度也不一樣，比如開發(fā)環(huán)境下cheap-source-map肯定比source-map快，至于為什么，強(qiáng)烈推薦自己之前寫的這一篇講解devtool的文章：webpack devtools篇講的非常詳細(xì)。
- {
- devtool: 'cheap-source-map'
- }
.eslintignore
這個(gè)雖不是webpack配置但是對(duì)打包速度優(yōu)化還是很有用的，在我的實(shí)踐中eslint檢查對(duì)打包的速度影響很大，但是很多情況我們不能沒有這個(gè)eslint檢查，eslint檢查如果僅僅在vs里面開啟的話，可能不怎么保險(xiǎn)。
因?yàn)橛锌赡苣鉽s中的eslint插件突然關(guān)閉了或者某些原因vs不能檢查了，只能靠webpack構(gòu)建去幫你攔住錯(cuò)誤代碼的提交，即使這樣還不能確保萬無一失，因?yàn)槟憧赡苣骋淮翁峤淮a很急沒有啟動(dòng)服務(wù)，直接盲改提交上去了。這個(gè)時(shí)候只能通過最后一道屏障給你保護(hù)，就是在CI的時(shí)候。比如我們也會(huì)是在jenkins構(gòu)建的時(shí)候幫你進(jìn)行eslint檢查，三道屏障確保了我們最終出的鏡像是不會(huì)有問題的。
所以eslint是很重要的，不能刪掉，在不能刪掉的情況下怎么讓檢查的時(shí)間更少了，我們就可以通過忽略文件，讓不必要的文件禁止eslint,只對(duì)需要的文件eslint可以很大程度提高打包速度
loader,plugins優(yōu)化
上述說了幾個(gè)基礎(chǔ)配置優(yōu)化，應(yīng)該還有其他的基礎(chǔ)配置，今后遇到了再繼續(xù)添加，現(xiàn)在在來講講利用某些loader,plugins來提高打包速度的例子
這個(gè)loader就是在第一次打包的時(shí)候會(huì)緩存打包的結(jié)果，在第二次打包的時(shí)候就會(huì)直接讀取緩存的內(nèi)容，從而提高打包效率。但是也需要合理利用，我們要記住一點(diǎn)你加的每一個(gè)loader，plugins都會(huì)帶來額外的打包時(shí)間。這個(gè)額外時(shí)間比他帶來的減少時(shí)間多，那么一味的增加這個(gè)loader就沒意義，所以cache-loader最好用在耗時(shí)比較大的loader上，配置如下
- {
- rules: [
- {
- test: /\.vue$/,
- use: [
- 'cache-loader',
- 'vue-loader'
- ],
- include: path.resolve(__dirname, './src')
- }
- ]
- }
在上面的渲染優(yōu)化中我們已經(jīng)知道，文件越小渲染的速度是越快的。所以我們?cè)谂渲脀ebpack時(shí)候經(jīng)常會(huì)用到壓縮，但是壓縮也是需要消耗時(shí)間的，所以我們我們經(jīng)常會(huì)用到上面三個(gè)插件之一來開啟并行壓縮，減少壓縮時(shí)間，我們用webpack4推薦使用的terse-webpack-plugin做例子來說明
- optimization: {
- minimizer: [
- new TerserPlugin({
- parallel: true,
- cache: true
- })
- ],
- }
這幾個(gè)loader/plugin和上面一樣也是開啟并行的，只不過是開啟并行構(gòu)建。由于happypack的作者說自己的興趣已經(jīng)不再js上了，所以已經(jīng)沒有維護(hù)了，并推薦如果使用的是webpack4的話，就去使用thread-loader?；九渲萌缦?/p>
- {
- test: /\.js$/,
- use: [
- {
- loader: "thread-loader",
- options: threadLoaderOptions
- },
- "babel-loader",
- ],
- exclude: /node_modules/,
- }
上面說的幾個(gè)并行插件理論上是可以增加構(gòu)建速度，網(wǎng)上很多文章都是這么說的，但是我在實(shí)際的過程中使用，發(fā)現(xiàn)有時(shí)候不僅沒提升反而還降低了打包速度，網(wǎng)速查閱給的理由是可能你的電腦核數(shù)本來就低，或者當(dāng)時(shí)你CPU運(yùn)行已經(jīng)很高了，再去開啟多進(jìn)程導(dǎo)致構(gòu)建速度降低。
上面說的幾個(gè)并行插件可能在某些情況下達(dá)不到你想要的效果，然而在我們團(tuán)隊(duì)優(yōu)化webpack性能經(jīng)驗(yàn)來看，這次所說的兩個(gè)插件是很明顯并且每次都能提高打包速度的。原理就是先把第三方依賴先打包一次生成一個(gè)js文件，然后真正打包項(xiàng)目代碼時(shí)候，會(huì)根據(jù)映射文件直接從打包出來的js文件獲取所需要的對(duì)象，而不用再去打包第三方文件。只不過這種情況打包配置稍微麻煩點(diǎn)，需要寫一個(gè)webpack.dll.js。大致如下
webpack.dll.js
- const path = require('path');
- const webpack = require('webpack');
- module.exports = {
- entry: {
- library: ["vue", "moment"]
- },
- output: {
- filename: '[name].dll.js',
- path: path.resolve(__dirname, 'json-dll'),
- library: '[name]'
- },
- plugins: [
- new webpack.DllPlugin({
- path: './json-dll/library.json',
- name: '[name].json'
- })
- ]
- }
webpack.dev.js
- new AddAssetHtmlWebpack({
- filepath: path.resolve(__dirname, './json-dll/library.dll.js')
- }),
- ew webpack.DllReferencePlugin({
- manifest: require("./json-dll/library.json")
- })
其他優(yōu)化配置
這些插件就簡單的介紹下，在我的個(gè)人項(xiàng)目中已經(jīng)使用過，自我感覺還可以，具體使用可以查閱npm或者github
這個(gè)插件可以用可視化幫我們分析打包體積，從而來采用合適的優(yōu)化方式去改進(jìn)我們的webpack配置
這個(gè)插件可以告訴我們打包時(shí)候每一個(gè)loader或者plugin花費(fèi)了多少時(shí)間，從而對(duì)耗時(shí)比較長的plugin和loader做優(yōu)化
這個(gè)插件可以幫我們優(yōu)化打包日志，我們打包時(shí)候經(jīng)?？吹胶荛L一個(gè)日志信息，有的時(shí)候是不需要的，也不會(huì)去看所以可以用這個(gè)插件來簡化
代碼優(yōu)化
這是最后一部分代碼優(yōu)化了，這里的代碼性能優(yōu)化我只說我在工作中感受到的，至于其他的比較小的優(yōu)化點(diǎn)比如createDocumentFragment使用可以查查其他文章
能不操作dom不要操作dom，哪怕有時(shí)候需要改設(shè)計(jì)
很多情況下我們都能用css還原設(shè)計(jì)稿，但是有些時(shí)候單單從css沒法還原，尤其組件還不是你寫的時(shí)候，比如我們團(tuán)隊(duì)用的就是antd,有時(shí)候的產(chǎn)品設(shè)計(jì)單從css上沒法實(shí)現(xiàn)，只能動(dòng)用js，刪除，增加節(jié)點(diǎn)在配合樣式才能完成。
由于我們又是一個(gè)做大數(shù)據(jù)的公司，這個(gè)時(shí)候就會(huì)出現(xiàn)性能問題，最開始寫代碼時(shí)候，產(chǎn)品說什么就是什么，說什么我都會(huì)想辦法搞出來，不管用什么方法。后來到客戶現(xiàn)場大數(shù)據(jù)請(qǐng)況下，性能缺點(diǎn)立馬暴露的出來。
所以代碼優(yōu)化的原則之一我認(rèn)為是能不寫的代碼就不寫，當(dāng)然這是要從性能角度出發(fā)，通過性能分析給產(chǎn)品說出理由，并且最好還能提供更好的解決方案，這個(gè)才是我們需要考慮的。
如果用的是react 一定用寫shouldComponentUpdate這個(gè)生命周期函數(shù)，不然打印的時(shí)候你會(huì)發(fā)現(xiàn)，你自己都迷糊為什么執(zhí)行了這么多遍
將復(fù)雜的比對(duì)，變成簡單比對(duì)
這句話是什么意思了？我們就拿shouldComponentUpdate舉例子，用這個(gè)函數(shù)沒問題，但是可以做的更好，我們?cè)诠ぷ髦薪?jīng)常這么寫
- shouldComponentUpdate(nextPrpops) {
- return JSON.stringify(nextPrpops.data) !== JSON.stringify(this.props.data)
- }
如果這是一個(gè)分頁表格，data是每一頁數(shù)據(jù)，數(shù)據(jù)改變了重新渲染，在小數(shù)據(jù)場景下這本身是沒有問題。但是如果在大數(shù)據(jù)的場景下可能會(huì)有問題，可能有人有疑問，既然做了分頁怎么還會(huì)有大數(shù)據(jù)了，因?yàn)槲覀兊漠a(chǎn)品是做大數(shù)據(jù)分析日志的，一頁十條日志，有的日志可能非常的長，也就是說就算是10條數(shù)據(jù)比對(duì)起來也是很耗時(shí)，所以當(dāng)時(shí)想法能不能找到其他的替代變量來表示數(shù)據(jù)變了？比如下面這樣
- shouldComponentUpdate(nextPrpops) {
- return nextPrpops.data[0].id !== this.props.data[0].id
- }
第一條的id不一樣就表示數(shù)據(jù)變化了行不行，顯然在某種情況下是存在的，也有人會(huì)說可能會(huì)出現(xiàn)id一樣，那如果換成下面這種了?
- shouldComponentUpdate(nextPrpops) {
- return nextPrpops.current !== this.props.current
- }
將data的比對(duì)轉(zhuǎn)換成了current的比對(duì)，因?yàn)轫摂?shù)變了，數(shù)據(jù)基本都是變了，對(duì)于我們自己日志的展示來說基本不存在兩頁數(shù)據(jù)是一模一樣的，如果有那可能是后臺(tái)問題。然后在好好思考這個(gè)問題，即使存在了兩頁數(shù)據(jù)一摸一樣，頂多就是這個(gè)表格不重新渲染，但是兩頁數(shù)據(jù)一摸一樣不重新渲染是不是也沒有問題，因?yàn)閿?shù)據(jù)是一樣的?；蛘呷绻氵€是不放心，那下面這種會(huì)不會(huì)好點(diǎn)
- this.setState({
- data,
- requestId: guid()
- })
- shouldComponentUpdate(nextPrpops) {
- return nextPrpops.requestId !== this.props.requestId
- }
給一個(gè)requestId跟宗data，后面就只比對(duì)requestId。上面的寫法可能都有問題，但是主要是想說的是我們?cè)趯懘a時(shí)候可以想想是不是可以"將復(fù)雜的比對(duì)，變成簡單比對(duì)"
學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu)和算法，一定會(huì)在你的工作中派上用場
我們經(jīng)常會(huì)聽到學(xué)習(xí)數(shù)據(jù)結(jié)構(gòu)和算法沒有什么大的用處，因?yàn)楣ぷ骰居貌簧稀＿@句話我之前覺得沒錯(cuò)，現(xiàn)在看來錯(cuò)的很嚴(yán)重。我們所學(xué)的每一樣技能，都會(huì)在將來的人生中派上用場。之前寫完代碼就丟了不去優(yōu)化所以我覺得算法沒意義，又難又容易忘記。但現(xiàn)在要求自己做完需求，開啟mock，打開perfermance進(jìn)行大數(shù)據(jù)量的測試，看著那些標(biāo)紅的火焰圖和肉眼可見的卡頓，就明白了算法和數(shù)據(jù)結(jié)構(gòu)的重要性，因?yàn)榇藭r(shí)你只能從它身上獲取優(yōu)化，平時(shí)你很排斥它，到優(yōu)化的時(shí)候你是那么想擁有它。我拿自己之前寫的代碼舉例，由于公司代碼是保密的我就把變量換一下，偽代碼如下
- data.filter(({id}) => {
- return selectedIds.includes(id);
- })
就是這樣幾行代碼，邏輯就是篩選出data里面已經(jīng)被勾選的數(shù)據(jù)。基本上很多人都可能這么寫，因?yàn)槲铱次覀儓F(tuán)隊(duì)里面都是這么寫的。產(chǎn)品當(dāng)時(shí)已經(jīng)限制data最多200數(shù)據(jù)，所以寫完完全沒壓力，性能沒影響。但是秉著對(duì)性能優(yōu)化的原則（主要是被現(xiàn)場環(huán)境搞怕了~~~），我開啟了mock服務(wù)，將數(shù)據(jù)調(diào)到了2萬條再去測試，代碼弊端就暴露出來了，界面進(jìn)入卡頓，重新選擇的時(shí)候也會(huì)卡頓。然后就開始了優(yōu)化，當(dāng)時(shí)具體的思路如下
按照現(xiàn)在的代碼來看，這是一個(gè)兩層循環(huán)的暴力搜索時(shí)間復(fù)雜度為O(n^2)。所以想著能不能降一下復(fù)雜度至少是O(nlogn)，看了一下代碼只能從selectedIds.includes(id)這句入手，于是想著可不可以用二分，但是立馬被否定因?yàn)槎质切枰行虻?，我這數(shù)組都是字符串怎么二分。
安靜了一下之后，回想起看過的算法課程和書籍以及做的算法題，改變暴力搜索的方法基本都是
1：上指針
2：數(shù)組升維
3：利用hash表
前兩者被我否定了因?yàn)槲矣X得還沒那么復(fù)雜，于是利用hash表思想解決這個(gè)問題，因?yàn)閖s里面有一個(gè)天然的hash表結(jié)構(gòu)就是對(duì)象。我們知道hash表的查詢是O(1)的，所以我將代碼改寫如下
- const ids = {};
- selectedIds.forEach(id => ids[id] = 1);
- data.filter(({id}) => {
- return !!ids[id];
- })
將從selectedIds查詢變成從ids查詢，這樣時(shí)間復(fù)雜度就從O(n^2)變成了O(n)了，這段代碼增加了
- const ids = {};
- selectedIds.forEach(id => ids[id] = 1);
其實(shí)增加了一個(gè)selectedIds遍歷也是一個(gè)O(n)的復(fù)雜度，總來說復(fù)雜度是O(2n),但是從時(shí)間復(fù)雜度長期期望來看還是一個(gè)O(n)的時(shí)間復(fù)雜度，只不過額外增加了一個(gè)對(duì)象，所以這也是一個(gè)典型的空間換時(shí)間的例子，但是也不要擔(dān)心，ids用完之后垃圾回收機(jī)制會(huì)把他回收的。
最后
其實(shí)這篇文章寫出來還是對(duì)自己幫助很大，讓自己系統(tǒng)的梳理了一下自己理解的前端優(yōu)化，希望對(duì)你們也有幫助。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)