咨询企业网站模板,数据分析师课程,北京中关村在线官网,wordpress 微信 抓取前言—在 web 开发场景#xff0c;减少代码体积虽然是性能优化的一个方向#xff0c;还没到锱铢必较的程度。但是在小程序场景#xff0c;由于代码包上传阶段限制了主包 2M 和总包 16M#xff08;近期微信官方正在内测将总包上限调整至 20M #xff09;的尺寸#xff0c;… 前言—在 web 开发场景减少代码体积虽然是性能优化的一个方向还没到锱铢必较的程度。但是在小程序场景由于代码包上传阶段限制了主包 2M 和总包 16M近期微信官方正在内测将总包上限调整至 20M 的尺寸超过就会面临无法发版的风险代码包体积的优化就变得特别重要了。京喜小程序首页作为微信购物的大入口承载大量流量功能复杂模块众多又要与其他核心业务和公共组件共享 2M 的主包空间因此代码包瘦身的工作在持续不断进行否则无法满足业务的快速增长。本文将结合以往优化策略与最近一次的瘦身实践分享小程序代码瘦身的经验与思考。常见的瘦身方式—京喜首页项目是一个优化良好的项目对于常见的优化措施已经有过很好的实践就让我们我们先回顾一下有哪些常见的优化策略吧代码分包将相对独立的页面和组件拆分到分包可以解决主包体积受限问题依赖分析移除未引用的页面、组件和其他文件避免使用本地资源除了兜底图片其他都尽可能使用 url 的方式由于 base64 图本质上是将信息编码成长字符串也会占用很多空间不建议使用对所有类型的文件都进行压缩并清理注释包括了js、wxml、wxss、json此外京喜首页团队还针对 Taro 开发场景进行了如下优化分析出编译后每个文件的高频重复代码如处理兼容性的 pollyfill 代码拆分生成公共文件替换原引用以实现共用。标准和工具—在开始正式介绍瘦身实践之前我们先来明确一下代码包体积的衡量标准和统计方式吧。小程序上传代码以代码包尺寸为准所谓 2M 的限制就是指该尺寸不能超过 2048KB。从信息传输角度来说Gzip 等压缩工具可以进行很多信息化编码优化因此一些内容重复是可以容忍的但是由于我们的目标是为了解决小程序上传限制就只有对代码包尺寸锱铢必较了。在开发者工具-详情-基本信息-上次预览或上次上传可以查看到最近一次的代码包体积本文接下来所介绍的优化都是以缩小这个体积为目的。查看代码包尺寸但是代码上传生成模板速度很慢如果每次都要根据这里的数据来统计体积变化效率太低了。在未改动项目配置的情况下我们就可以间接以代码目录的文件体积大小作为变化参照。怎么方便的统计文件体积呢这里我用了tree-cli[1]利用它提供的参数可以输出具备尺寸统计和排序功能的代码文件清单npm install -g tree-cli // 目标目录 cd target-directory // 输出文件为 size-analysis.md tree -s --sortsize -o size-analysis.md 清单内容格式如下. ├── [ 1000] index.js ├── [ 500] index.wxss ├── [ 500] index.wxml ├── [ 500] index.json ├── [ 4000] components │   ├── [ 4000] child │   │   ├── [ 1000] index.js │   │   ├── [ 1000] index.wxml │   │   ├── [ 1000] index.wxss └── └── └── [ 1000] index.json6500 bytes used in 2 directories, 8 files 瘦身实践—前面说到京喜首页优化措施都做的很好了下面即将分享的是一些不那么常见的优化方式优化空间有大有小想要优化小程序代码包建议先尽量完成前文提到的优化方案这样获得的收益最明显然后再来看接下来提到的这些方式吧~一、字体和颜色的全局共用小程序文档内关于继承样式的说明为继承样式如font,color, 会从组件外继承到组件内。分析项目现状我们通常会把字体定义放在公共 css 文件内随着页面或组件引入公共 cssfont 也将被重复引入可以通过改造把 font 的定义仅放在 app.wxss 内取消组件和页面的引入可以达到减少整体代码包体积的目的。关于这一项首页项目体积减少 1%预估整个项目还有 20kb 左右的 font 定义可清理。如果有全局的颜色定义也可以进行类似的优化。二、样式补全功能的使用作为 web 开发者对 -webkit- 这种前缀一定不陌生为了适配不同浏览器内核通常我们会在编译阶段使用 autoprefixer 进行样式的自动补全。而小程序开发者工具也提供了样式补全的能力详情-本地设置-可以勾选「上传代码时样式自动补全」这个补全和我们在编译时做的有什么不同吗关键在于它实现的时机如果是本地模板上传前那么应该和我们编译的补全效果一样如果是在上传模板后也许可以借此减掉补全内容所占的尺寸。结合小程序代码包传递过程和样式补全时机大概有以下 3 种情况阶段一补全阶段一阶段二阶段二或者是阶段三阶段三为了验证猜想来做一个实验吧比较「 项目编译不补全样式开发者工具设置样式补全」 vs「 项目编译补全样式开发者工具不设置样式补全」模板体积统计如下开发者工具提供样式补全编译提供样式补全可见前者比后者少了 58kb这说明开发者工具提供的样式补全不是在阶段一做的不然模板体积应该和我们自己做的编译补全基本一致。那么就可以愉快的去掉编译补全使用小程序开发者工具提供的能力了。不过这样改动会出现一个小问题开发者工具内的样式是未经补全处理的个别样式会有点问题测试就发现 mask-border-source 无效而相应真机因为已添加样式补全没有问题。为了不出现预览误会建议给这种尚未支持的样式手动写上 -webkit- 前缀保证开发和真机表现一致。三、小心 Sass!sass/less 等工具使得 css 的编写变得更加流畅函数和变量的引入也让 css 有了一点工程化的意味。但是你有没有观察过 sass 的编译实现呢// a.scss作为被引用方 .banner { // 样式定义color: red; } $COLOR red // 变量定义函数定义类似// b.scss作为使用方 import a.scss; .banner_wrapper {background: white;color:$COLOR; } 关注 b.sass 的编译后// a.scss的引用消失了内容被整合到文件内.banner { // a.scss内的样式定义会被拷贝进来color: red; } .banner_wrapper {background: white;color:red; //变量定义会被按值替换 } 这里出现的问题是我们是否需要.banner被拷贝进来呢为了避免多引入不需要的样式定义有以下几个方向按功能拆分 a.scss 内的样式定义按需引入。使用 include 语法将 banner 的定义变成一个变量按需引入。而在小程序场景wxss 语法支持 import实现了极弱版的模块化使得我们可以再加一个角度解决上面的问题绕过 sass 编译使用小程序的 import 语法引入需要的样式定义。关于如何绕开 sass 编译可以考虑使用注释片段或者白名单筛选识别四、多端场景的冗余代码移除京喜首页项目使用 Taro 开发需要适配 H5/微信小程序/QQ 小程序等多端场景利用 Taro 提供的环境变量能力可以在方法内部实现多端差异处理比如下面这段init(){if(process.env.TARO_ENV weapp{// 微信小程序逻辑this.initWeapp()}else if(process.env.TARO_ENV h5){// H5页面逻辑this.initH5()} } initWeapp(){...} initH5(){...} 小程序端打包后代码init(){this.initWeapp() } initWeapp(){...} initH5(){...} 但是环境变量方式没办法处理 initH5 这种方法定义导致也被打包进来了。因此我们需要更强大的差异打包京喜首页利用内部的 wxa-cli 工具提供的条件编译能力通过注释段落标记圈注出多端内容实现了代码片段层面的差异打包细节如下init(){if(process.env.TARO_ENV weapp{// 微信小程序逻辑this.initWeapp()}else if(process.env.TARO_ENV h5){// H5页面逻辑this.initH5()} } initWeapp(){...} /* wxa if:typeh5 */ 标记h5端代码开始位置 initH5(){...} /* /wxa */ 标记注释结束位置 打包后代码init(){ // weapp内this.initWeapp() } initWeapp(){...} initH5 消失了代码更瘦了五、整理 log为了调试方便你的项目内有没有打很长的 log类似于这种console.log(xx接口异常) 经过测试首页代码文件内有 5KB 的内容是 log 语句可以试着优化一下及时移除开发调试用 log信息类 log 约定长度更短的格式六、良好的编码策略有没有同样的逻辑需求可以用更短更优雅的写法来实现呢关于代码分析是个很复杂的话题暂时列一个结论相对明确的写法吧格式化数据时数据的存取和中间变量问题function format(list){let result []list.forEach(item {const {a,b,c: f,d,e,} itemresult.push({a,b,f,d,e,})})return result 可以利用 lodash 的 pick 方法改写成import { pick } from lodash/pickfunction format(list){return list.map(item({...pick(item,a,b,d,e),f:item.c})) 七、样式命名编译优化京喜首页项目由于 H5 端混搭老项目为了避免类名冲突采用了形如block-name__element--modifier的 bem 命名规则。在开发中进一步发现一些类似 navbar-content__item 的常见命名偶尔撞车为了避免冲突类名就越写越长而小程序代码包的尺寸影响也在悄悄增大。为了解决命名冲突的问题将类名 hash 化是个好办法css-modules 就是个成熟的插件可以通过配置规则对样式名编译出「文件名内容相关」的独特化 hash。但是研究下它的实现会发现对代码尺寸的影响不容乐观看一个编译后例子import style from ./index.module.map.scss.js //js文件增加一句jsMap的引入view className{style.banner}/view // wxml文件每处类名都比原类名增加了style.的引用.hash { xx } // wxss文件 类名被hash化减少的具体尺寸为:原类名-hashmodule.exports { banner : hash } // 新增了一个map文件实现原名与hash名的映射增加的具体尺寸为:原类名hash 计算整体内容变化js 内新增引入 map 语句增加一句代码wxml 内原为 n 个类名现为 n 个「style.原类名」增量为 n 个style.map 文件 与 wxss 文件合计map 内有 n 个原类名与 hash 映射 wxss 现为 n 个 hash 减去原来的 n 个原类名 合计增量为 2n 个 hash可见引入 css-modules 会导致整体代码尺寸增加。会不会觉得这个新增的 map 文件的作用特别熟悉呢在我们压缩 js 文件时会有一个 sourceMap 文件它保留了原始命名和代码位置可以方便定位和 debug。css-modules 实现的 map 文件在我看来作用和 sourceMap 的命名索引差不多对于代码逻辑来说除了保持原类名的引用信息它好像也没什么用了在尺寸敏感场景就可以考虑去掉 map 文件还是上文的示例如果可以实现成这样就好了 // import style from ./index.module.map.scss.js js文件取消map的引入// wxml文件 view classNamehash/view // 对style.banner进行求值并替换// wxss文件 .hash { xx } // 这里不变module.exports { banner : hash } // 删掉不要 网上遍寻没有相关的处理只能自己造轮子开搞了。由于当前主要目的是对小程序代码瘦身H5 端文件处理和小程序也有一些差异所以暂时只对小程序场景造了插件取名 weapp-css-modules github 地址在这里https://github.com/o2team/weapp-css-modules大概思路是完成小程序的 css-modules 实现在此基础上进行 map 移除的相关简化逻辑进一步的考虑到小程序组件内默认样式隔离的特性对 hash 化的命名再次缩短变成单字母编排。如果是只开发小程序端可以借此实现小程序样式命名相关的代码瘦身而对于 Taro 开发的多端场景还可以同时解决 h5 端的命名冲突问题。还是上面的例子下面是 weapp-css-modules 编译后效果// js文件 let style {} // 不引用map加入对不规范引入style的兼容// wxml文件 view classNamea/view // 对style.banner进行求值并替换加入单字母编排// wxss文件 .a { xx } // 因为小程序组件样式隔离所以可以最短化类名module.exports { banner : hash } // 删掉不要 京喜首页项目通过改造组件采用 css-modules 写法加上 weapp-css-modules 编译代码相对尺寸减少了 10%还是很有效果的感兴趣的同学可以试用一下。总结关于代码瘦身想提一下信息学中熵的概念熵反映信息的无序程度一段信息无序程度越低它的熵值越低可被压缩的空间越大无序程度越高熵值越高可被压缩的空间越小。而数据压缩或者是代码瘦身的过程就是通过优化信息存储方式以逼近它真实的熵值。从这个角度来说「字体和颜色的全局共用」和「样式补全功能的使用」是借用小程序提供的能力信息量没变「小心 Sass」、「多端场景的冗余代码移除」是减少不用的信息「整理 log」和「样式命名编译优化」是凝练有效信息看起来最不好归类的是「良好的编码策略」它是在编码阶段对信息的梳理和整合也算凝练有效信息吧。以上就是京喜首页项目这次代码瘦身的主要方式了除此之外的删除不用文件、整合公共文件这些体力活我就不再啰嗦了。通过以上方式京喜首页代码在原本优化良好的基础上实现了再次减重 30%的目标希望能给小程序开发者们带来有价值的信息和思考。参考资料[1] CSS Modules: https://github.com/css-modules/css-modules[2] Tree-Cli: https://github.com/MrRaindrop/tree-cli[3] 小程序工程化探索: https://mp.weixin.qq.com/s/_NSJTQ-4-8gTnwTVK-tn0A[4] 微信小程序 限制 2M 的瘦身技巧与方法详解: https://blog.csdn.net/wlanye/article/details/73457700精选前端好文伴你不断成长我是若川欢迎关注!可点击