vue优化

  1. 代码格式
    代码格式问题完全可以通过自动化工具来解决。标准的 eslint 规则( 如 Airbnb 或公司统一推出的 eslint 规则) + husky( 本地 pre-commit 校验 ) + 远端 CI 流水线 eslint 校验(开启 cache,增量校验)就可以解决。

2.1 是否存在会导致内存泄露的代码

对于 SPA 应用,用户无需刷新浏览器,所以要想确保垃圾回收生效,我们需要在组件对应生命周期里做主动销毁。

1)存在不必要的全局变量且未及时解除引用

全局变量,除非你关闭窗口或者刷新页面,才会被释放,如果缓存大量数据,很可能导致内存泄露。比如,我们之前就遇到过把 IM SDK 放在全局 window 上,但在页面卸载时却没有解除引用。

mounted () { window.im = TWebLive.createIM({ SDKAppID }); }

解决方案:在页面卸载时解除该全局引用。

destroyed () { window.im = null; }

其实该 im 实例也不需要挂在 window 上,直接绑定在 vue 实例上即可,组件销毁时该实例也会销毁;但没有绑定在 vue 实例上的一定要主动销毁。

2)闭包内部变量未被销毁

来看一个容易忽视的闭包引发内存泄漏的例子。outer 函数内部定义了两个函数: unused 和 foo。虽然 inner 函数中并没有使用 outer 函数中的变量,但是由于 unsed 函数使用了 outer 函数的 bar 变量,bar 也不会被释放,所以 foo 相当于隐式持有了 bar。每次执行 outer,bar 都会指向上一次的 foo;而 foo 也会隐式持有 bar,这样的引用关系导致 bar 和 foo 都无法释放。

`let foo = null;

function outer() {
let bar = foo;

// 该函数历史原因,调用方被注释掉。并无调用
function unused () {
doSomething();
console.log(unused ${bar})
}

// foo赋值
foo = {
bigData: new Array(10000),
inner: function () {
doSomething();
}
}
}

for (let i = 0; i < 1000; i++) {
outer();
}`

解决方案:在 outer 执行完毕时手动释放 bar。这样,隐式持有 bar 的 foo 也没有其他变量引用,也会被回收了。

`let foo = null;

function outer() {
let bar = foo;

// 该函数历史原因,调用方被注释掉。并无调用
function unused () {
doSomething();
console.log(unused ${bar})
}

// foo赋值
foo = {
bigData: new Array(10000),
inner: function () {
doSomething();
}
}

bar = null; // 手动释放bar
}

for (let i = 0; i < 1000; i++) {
outer();
}`

3)定时器是否及时清理

常见的情况是 mounted 设置了定时任务,但却没有及时清理。

mounted () { this.timer = setTimeout(() => { doSomething(); }, 300) }

参考写法,页面销毁时需清理定时器:

destroyed () { if (this.timer) { clearTimeout(this.timer) } }

4)监听事件是否有解绑

window/body 等事件需要解绑:

mounted() { window.addEventListener(‘resize’, this.func) } beforeDestroy () { window.removeEventListener('resize', this.func); }

5)第三方库的销毁函数,在页面卸载时也需要调用,比如 EventBus:

destroyed () { this.eventBus.off() }

6)v-if 指令导致的内存泄露

拿 vue 官网避免内存泄漏 的例子来看下。

v-if 指令只是控制虚拟 DOM 的添加和移除,但是由 Choices.js 添加的 DOM 片段并没有被移除。
`

`

解决办法是在 hide 方法里调用 Choices.js 的 API 来清理 DOM 片段:
hide: function() { this.choicesSelect.destroy(); }

以下是优化前、后的 JS Heap 对比图:

图片

2.2 异步操作是否有异常处理

异步操作拿接口请求来说,大家都知道的是,使用 promise 时要有.catch 处理。但使用 async/await 时,有.catch 处理的,也有 try...catch 处理的使用方法。这里推荐使用.catch。原因在于:

  • 可以控制接口请求出错后,是否要阻塞后续业务逻辑执行
  • .catch里的 error 能明确知道是接口请求导致的错误,而不需要再对 error 进行分类判断,是接口 200 返回后的业务逻辑处理报错还是接口报错。

`// CASE 1: 接口报错,阻塞业务逻辑执行
async fetchList() {
const res = await someApi().catch(error => {
// error处理逻辑
})
if (res) {
doA();
}
}

// CASE 2: 接口报错,不阻塞业务逻辑执行
async fetchList() {
const res = await someApi().catch(error => {
// error处理逻辑
})
doA();
}

// CASE 3:使用try...catch的情况
async fetchList() {
try {
const res = await someApi()
doA();
} catch (error) {
// 接口请求出错 + 接口响应成功后业务逻辑处理出错都会进入catch block。需要进一步区分错误类型
if (error.bizcode !== 0 || error.retcode !== 0) {
reportApiError(error)
} else {
reportBusinessError(error)
}
}
}`

2.3 取值时是否进行了空判断、调用函数时是否进行了类型判断

拿医典 3 月中下旬的错误日志来说,这类错误在错误日志中占了 1/3。

图片

如果项目里已经全量使用了 Typescript,这类错误应该都可以避免。但如果项目里还存在 js 代码,可以使用lodash.get来做空判断,在调用函数之前要对函数做类型判断。

2.4 存在无意义的 if else 代码块或考虑漏的条件

无意义的 if else 代码块,指的不仅是空的 if else 代码块,还有只写了 console.log 的情况。另外,也存在条件判断过于复杂,else 情况考虑不全,导致逻辑没有正常处理的情况。

`// else 代码块里只写了console.log
if (a) {
} else {
console.log('something')
}

// 条件判断过于复杂,else情况考虑不全,导致逻辑不能正常处理
if ((a && (b || c)) || d || (e && (f || g))) {
} else {
doSomething()
}`

解决办法:开启 eslint no-empty 规则,不允许有空的 block。但这个插件的问题在于,如果是无效的代码块,比如在 else 代码块只做了 console.log 操作,并不会检测出来。另外,较为复杂的条件判断尽量拆成单独的变量,并分别配上注释说明,这样可以防止逻辑处理漏。

2.5 存在无意义的 catch 代码块

和无意义的 else 代码块一样,也存在空 catch 代码块、只有 console.log 的 catch 代码块的情况。

`// bad case
try {
doSomething();
} catch (e) {
}

// bad case
try {
doSomething();
} catch (e) {
console.log(e);
}

// bad case
somePromise().then(() => {
doSomething()
}).catch(() => {
})

somePromise().then(() => {
doSomething()
}).catch((e) => {
console.log(e)
})`

为了解决这个问题,医典这边做了一个 eslint 插件@tencent/eslint-plugin-medical,能够检查 try catch 里的 catch 代码块、promise 的 catch 代码块,是否为空,是否只有 console 调用。当然,有些时候,并不需要对异常逻辑进行额外业务逻辑处理,catch 里可以加一个上报。

2.6 是否含有安全风险的代码

这一步可以在流水线里接入安全风险检测插件进行处理。以下是医典接入后的一个示例分析。

图片

确实存在一些误判,比如会把mixin关键字当做泄露人名来进行告警,开发人员可以对照分析是否需要处理。

前端常见的硬编码场景有:

  • 请求参数和返回对象 比如之前就遇到过,开发同学把 mock 的请求参数 id,放到了线上的情况。(因为该接口是根据医生 id,拉取评论,评论也是后端灌的假数据,所以在测试阶段都没发现)

// 请求参数硬编码 getCommentsApi({ doctorId: 1 }).then((res) => { doSomething() }).catch(() => { handleError(); }) 

也出现过 ABtest 接口,开发同学本地模拟返回对象,忘记删除硬编码的情况

fetchABTestApi().then((res) => { // res.data const obj = { imgSrc: 'xxx', name: 'qinmu' } }) 

接口 mock 的硬编码,完全可以通过使用 mock 平台来解决。推荐使用专业的接口管理平台来进行接口管理、mock 等,这里我们使用的是腾讯内部接口管理平台 tolstoy。该产品还未正式开源,欢迎提前关注。

  • 路由参数

`// bad case 硬编码1001
const isActive = this.$route.query.id === '1001'

// good case 写到配置信息中。这样,id和状态的对应关系一目了然,便于管理和维护。
const idConfig = {
1001: STATUS.ACTIVE
}
const isActive = idConfig[this.$route.query.id] === STATUS.ACTIVE`

2.7 格式校验

输入框的校验规则除了满足产品需求,比如多少字符以内、允许哪些字符,还有一个点:前后端需要校验规则保持一致。最好用统一的正则表达式,不然容易造成前端校验通过、后端校验不通过的情况。

上传文件,前后端需求校验文件格式、文件大小。尤其是后端,需要对 content-type 为 text/html 的加以限制,防止出现安全问题。我们已经有过此类安全问题的工单了。

3. 代码习惯

图片

3.1 if-else 嵌套不能超过 4 层

拒绝面条代码,减少代码中各种结构的嵌套,例如 if-else、try-catch、循环等。尽量控制在三层以内,增加可读性、降低圈层复杂度。你肯定不愿意维护这样辣眼睛的代码:

async getConfig(id, type = '', isReset = false) { try { if (liveid) { const res = await someApi(id); if (res && res.info) { const { status } = res.info status === 2 && doA({id, type}); if (status === 1 || status === 2 || status === 4) { this.setData({ info: res.info, status, }) if (isReset) { this.setData({ current: 0, index: 0 }) status === 2 && doB(); } return { code: 0}; } return doC(); } else if (isReset) { resetSomething(); } else if (isReset && type === someType) { handleType(); } return wx.showModal({ //... }) } } catch (error) { if (error.code === 1001) { reportA(); } else { reportB(); doD(); } } } 

3.2 Don't repeat yourself

逻辑相同或相似的代码,应封装为函数进行调用。

`// bad case 都有展示modal的逻辑,开发同学直接复制粘贴
function handleA(msg) {
wx.showModal({
title: '提示',
content: msg,
showCancel: false,
confirmText: '确定',
confirmColor: '#02BACC',
success: (res) => {
if (res.confirm) {
doA();
}
},
});
}

function handleB(msg) {
wx.showModal({
title: '提示',
content: msg,
showCancel: false,
confirmText: '确定',
confirmColor: '#02BACC',
success: (res) => {
if (res.confirm) {
doB();
}
},
});
}

function handleC(msg) {
wx.showModal({
title: '提示',
content: msg,
showCancel: false,
confirmText: '确定',
confirmColor: '#02BACC',
success: (res) => {
if (res.confirm) {
doC();
}
},
});
}`

解决方案,封装 showModal 函数。

`function showModal (msg) {
return new Promise((resolve, reject) => {
wx.showModal({
title: '提示',
content: msg,
showCancel: false,
confirmText: '确定',
confirmColor: '#02BACC',
success: (res) => {
if (res.confirm) resolve()
},
fail: (err) => {
reject(err)
}
})
})
}

funtion handleA(msg) {
showModal(msg).then(
doA();
).catch(() => { catchHandler();})
}

funtion handleB(msg) {
showModal(msg).then(
doB();
).catch(() => { catchHandler();})
}

funtion handleC(msg) {
showModal(msg).then(
doC();
).catch(() => { catchHandler();})
}`

3.3 不建议直接修改 Object 原型(或者 Function, Array 原型等)

在 Object.prototype 上定义方法就相当于 C++里定义宏, 而且还是 #define private public 这种。从可靠性来说,多人协作很容易出现冲突。从兼容性来说,你不能保证后续推出的原生方法实现和你现有的一致,也不能保证多个库之间对该方法的实现一致。比较有名的故事是 prototype 库的 getElementsByClassName。在还没有这个原生方法之前,prototype 这个库实现的是返回 Array,并且加了“each”方法:document.getElementsByClassName('myclass').each(doSomething);但原生方法出来后,返回的是 NodeList,并没有 each 方法;所以就悲剧了。

详细说明可以看:Nicholas C. Zakas 的 Maintainable JavaScript: Don’t modify objects you don’t own

3.4 回调嵌套不建议超过 3 层回调嵌套

减少回调的嵌套,避免产生callback hell:

fs.readdir(source, function (err, files) { if (err) { console.log('Error finding files: ' + err) } else { files.forEach(function (filename, fileIndex) { console.log(filename) gm(source + filename).size(function (err, values) { if (err) { console.log('Error identifying file size: ' + err) } else { console.log(filename + ' : ' + values) aspect = (values.width / values.height) widths.forEach(function (width, widthIndex) { height = Math.round(width / aspect) console.log('resizing ' + filename + 'to ' + height + 'x' + height) this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) { if (err) console.log('Error writing file: ' + err) }) }.bind(this)) } }) }) } }) 

建议使用 promise、async/await 的方式让代码更为清晰可读;也可以将 callback 要做的事拆成独立的 function,并分别对 err 进行处理。

3.5 函数不超过 80 行

函数尽量精简在 80 行以内,并且以小 function 进行组织,方便维护、复用。

3.6 缺少注释及注释规范化

除了知道下面的逻辑是在绘制 canvas,其他逻辑你能看懂吗?

`function doSomething() {
let count;
if ((count = width * height / 1000000) > 1) {
count = ~~(Math.sqrt(count) + 1);
const nw = ~~(width / count);
const nh = ~~(height / count);
const tCanvas = document.createElement('canvas');
const tctx = tCanvas.getContext('2d');
tCanvas.width = nw;
tCanvas.height = nh;

    for (let i = 0; i < count; i++) {
      for (let j = 0; j < count; j++) {
        tctx.drawImage(img, i * nw * ratio, j * nh * ratio, nw * ratio, nh * ratio, 0, 0, nw, nh);
        ctx.drawImage(tCanvas, i * nw, j * nh, nw, nh);
      }
    }
  } else {
    ctx.drawImage(img, 0, 0, width, height);
  }

}`

常用的注释分类有这些,建议参考 JSDoc:1)文件注释 2)变量注释 3)常量注释 4)函数注释 5)枚举注释 6)类的注释

  1. 类的属性注释

3.7 注释与实现功能不符

这一条在团队里是出现过现网 bug 的。

故事背景是开发 M 在重构代码时,设置底部栏状态这一逻辑已经封装出来,所以根据注释,下面几行代码做的事情也是设置底部栏状态,开发 M 就把这几行代码都删掉了。但是注释下面的代码,除了做设置底部栏状态的事情,还有一个 setBanner 函数,是为了设置 banner 位的,也被连同删掉,进而导致了 bug。

追溯原因,设置底部栏状态是 A 同学做的,设置 banner 位是 B 同学做的,B 同学在没有看注释的情况下,直接把 setBanner 放在了错误的位置上。

`function fetchData() {
// ...
doManythings();

// 设置底部栏状态
setBanner();
fetchStatusApi().then(res => {
// ...
}).catch(() => {
// ...
})
}`

3.8 避免存在大量注释掉的无用代码

git 的版本管理能帮我们回溯之前的代码。如果项目里存在大量注释掉的代码,会降低可读性。

3.9 避免遗留大量多余的 console.log 调试日志

虽然 console.log 调试日志在生产环境构建时不会输出,但就本地开发环境来说,代码里惨杂过多 console.log 调试日志,控制台满屏的调试日志,对于每个接手的开发都是噩梦。另外,就像上面说的一样,catch 处理或 else 分支里存在只打 console.log 而不做任何处理的情况。尽量避免少使用 console.log,也可以减少这类意外的发生。

所以,日常开发调试建议使用浏览器 sources tab 的断点调试;另外,就算要输出调试日志,也不止有 console.log 可以使用,参考这篇文章。你可以使用 console.table 等来格式化输出

图片

3.10 存在很多 eslint-disable 注释

我能想到的允许 eslint-disable 的场景只有一种,那就是解构后端返回对象。后端返回对象属性名是下划线,这个时候可能需要 // eslint-disable-next-line camelcase。其他情况我都不建议使用 eslint-disable,尤其是整个文件全局 eslint-disable。

之前遇到过某文件全局禁用"no-undef"规则,结果代码里使用了未定义的变量,导致现网 bug。如果你有全局定义的变量,建议写在 eslintrc.js 的 globals 字段里。当然,就正如上文代码错误-内存泄露提到的一样,非必要情况,不建议使用全局变量。

3.11 没有使用空行对代码分组

为了增强可读性,建议使用空行对代码分组。

3.12 命名规范

常见的不规范命名有这些,会让之后维护的同学很懵逼:

  • 单词拼写错误,比如 submitForm,写成 submitFrom。
  • 中英文混用。比如 gotoZaihai。你能知道这是什么意思吗?其实是跳到灾害专区活动页。goToDisasterZone 是不是要好一点,同学?
  • 以 1-9、a-z 命名 在项目里我曾经见过不知道怎么命名,就 type1、type2、type3 直接上了,也不写注释。非常让人抓狂。
  • 混用命名格式 就评论列表,代码里有 comments、commentList、也有 commentData、commentsData。???能规范统一一下吗。
  • 单复数不分 明明是一个列表数据,非要用单数表示,比如 disease。建议区分下单复数,如果是数组就用List 来表示。
  • 动词、名词、形容词不分 比如,一个函数名,命名为名词“doctor”;而一个 Vue computed 属性,又命名为 getUserInfo;表示关闭状态,命名为“close”;真是让人非常头疼。

`// bad case 1
function doctor () {}

// bad case 2
computed: {
getUserInfo() {}
}

// bad case 3
close = false;`

同学,就不能好好写代码吗?

`// good case 1
function getDoctorInfo() {}

// good case 2
computed: {
userInfo() {}
}

// good case 3
closed = false`

3.13 过多的非业务逻辑相关代码(如超过 10 行的上报, 参杂在业务逻辑里)

如果在业务逻辑里掺杂太多的上报,后续理解业务逻辑时需要看上报逻辑,查上报逻辑的时候也需要理解大量的业务代码。点击埋点和曝光埋点都可以以属性的形式挂在元素上,通过冒泡,统一进行处理。

如果你上报的参数需要根据不同渠道来配置,建议封装出来,不要和业务逻辑耦合了。

3.14 没有 README 文档、或者 README 太简单、太作用有限

除了项目的 READMD,每个模块都应该有各自的 README,说明这个模块的功能点、技术实现方案等。看个人习惯,你也可以写在 iwiki 里,在 README 放一个 iwiki 的链接。

3.15 尽量使用 export 而 不是 export default 来导出

export default 有两个问题:1)不利于 tree shaking 2)如果使用了一个导出对象上不存在的属性,要运行时才能发现。

4.代码优化【持续更新中】

图片

4.1 避免大量直接操作 dom 节点

直接操作 DOM 的性能损耗至少有两个地方:进行 DOM 操作的时候上下文切换 + DOM 操作引起的页面重绘

4.2 避免使用 delete

delete 操作符并不会释放内存,而且会使得附加到对象上的 hidden class 失效,让对象变成 slow object。(hidden class 是 V8 为了优化属性访问时间而创建的隐藏类)来看一下执行速度对比:undefined > delete > omit

图片

4.3 是否引用了不必要的 npm 包

比如做一个简单图表的需求,不选轻量的库,非要整一个 echarts;或者实现一个简单的代码编辑器,monaco-editor 有 min 版本不使用,非要引用一整个 monaco-editor。还有,lodash 没法做 tree-shaking,要么引用一个具体的子包lodash.get,要么引用lodash-es,非要引用一整个 lodash。

4.4 尽量使用 CDN 地址的图片

如果代码里引用的是本地图片,构建打包会有耗时。可以在引用之前就把图片传到 cdn 上,代码里直接使用 cdn 地址。

以上就是 CR 的细则了。

你可能感兴趣的:(vue优化)