终极效果 效果要求：使得最终页面效果在开发者模拟器、安卓、iOS都可正常显示字体效果。 [图片] 问题背景 如何在微信小程序上利用wx.loadFontFace方法加载自己要上传的字体的文件一直是困扰很多开发者的问题，很多人反映使用该方法在开发者工具模拟器上是可以显示的，有的开发者说在模拟器和iOS系统上可以正常显示自定义字体，但是安卓机上无法正常显示。 很多人为了能够实现加载自定义字体想了很多办法，比如 方法1： 字体文件转base64代码（如网站https://www.transfonter.org） ，然后存储在wxss文件中。这也是我曾使用的方法之一，确实很好用，安卓/苹果机上都可以正常实现效果。 缺点：但是面对字体文件包一般都很大的中文字体来说，转换成base64代码是极容易出现仅用来引用字体的wxss代码就超过2M的情况。 根据小程序的开发规矩，即使采用分包形式开发一个小程序，单个分包的代码量也是不能超过2M的，此时就是该方法的鸡肋。 方法2： 也有开发者利用iconfont上的在线引用方法，把自己会用到的字输进入然后点击生成字体，引用一个url即可实现。这种方法也是可行的。 缺点：但是对于部分字多或者可能出现用户输入文字的情况，这种方法就不太方便。 解决方案 今天，和大家讲的就是wx.loadFontFace方法，也是很多人一直在尝试，执着于想要利用这种方法实现。 在小程序开发者文档中，这一段文字是你不陌生的。 wx.loadFontFace(Object object) 基础库 2.1.0 开始支持，低版本需做兼容处理。 本接口从基础库版本 2.15.0 起支持在小程序插件中使用 动态加载网络字体，文件地址需为下载类型。‘2.10.0’起支持全局生效，需在 app.js 中调用。 注意： 字体文件返回的 contet-type 参考 font，格式不正确时会解析失败。 字体链接必须是https（ios不支持http) 字体链接必须是同源下的，或开启了cors支持，小程序的域名是servicewechat.com canvas等原生组件不支持使用接口添加的字体 工具里提示 Faild to load font可以忽略 ’2.10.0’ 以前仅在调用页面生效。 ——来源于《微信小程序开发者文档》 分析： 注意点1是大家一般无需担心的，我们下载到的字体文字很多是ttf文件，都是符合相关要求的。 注意点2也是一般不会犯错的，大家都会避开这个。 注意点3是非常重要的，也是很多开发者不明白的，下面，我会着重讲如何解决这个问题，解决了这个问题，无论调试还是真机都能正常显示。 在开发者文档中，有这样一段代码： [代码]wx.loadFontFace({ family: 'Bitstream Vera Serif Bold', source: 'url("https://sungd.github.io/Pacifico.ttf")', success: console.log }) [代码] 可以看出使用的是https链接，或许你曾经拿这段代码测试过。 或者你也曾经把字体文件上传到一些存储空间然后得到上传后文件的地址，或者说你曾经在开发者社区看到别人上传的字体文件的https链接然后来调用。 在开发者工具模拟器上正常显示，一到真机就显示不了。 当然为了想要使用我自己喜欢的字体，得到该字体的文件链接，我也突然脑洞大开，尝试把字体文件上传到云开发的云存储上，然后得到一个FileID链接和一个下载链接。 随后在页面或者全局的JS中加载该字体文件： 代码： [代码]loadFontFace() { wx.loadFontFace({ family: 'XXX', source: 'url("xxxxxx.ttf")', success(res){ console.log('res', res) }, fail(err){ console.log('err', err) } }) }, [代码] 遗憾的是，也是能在模拟器中显示出自定义字体效果，在安卓的真机上无法正常显示，iOS未知（我没有iOS系统故无法测试）。 到底是怎么回事，问题出在哪呢？于是一遍遍琢磨开发文档中的注意事项“字体链接必须是同源下的，或开启了cors支持，小程序的域名是servicewechat.com”。 后来琢磨后面一句话，我也是不明白啥是cors，于是就搜索了，记得其中一篇文章就讲到腾讯云的cors之类的。 操作步骤 1 进入腾讯云的官网（https://cloud.tencent.com），然后登录账号，选择公众号小程序登录，扫码并选择需要实现自定义字体的小程序进行登录 2 在顶部菜单栏找到“对象存储” [图片] 3 存储桶列表中新建一个存储桶 [图片] 4 给存储桶设置配置，跨域访问中设置好“cors规则”，把https://servicewechat.com域名填写到来源Origin的方框内。 [图片] 现在再来读读“字体链接必须是同源下的，或开启了cors支持，小程序的域名是servicewechat.com”是不是有了新的体会。 5 把需要使用的字体文件上传到该存储桶，然后点击文件右边的“详情”，你就会看到“对象地址”，这个地址就可以粘贴到JS文件的wx.loadFontFace使用。 [图片] 6 不要忘了设置刚刚上传的字体文件“访问权限”为“公有读私有写”，这样每个用户都可以读取这个字体文件了。 源码分享 JS文件 [代码]loadFontFace() { wx.loadFontFace({ family: 'XXX（你给字体拟的名称，最好英文如kaiti）', source: 'url("对象地址")', success(res){ console.log('res', res) }, fail(err){ console.log('err', err) } }) }, [代码] WXSS文件 [代码]page{ font-family: 'XXX'（你给字体拟的名称，最好英文如kaiti）; } [代码] 或者 [代码].xxx（class名）{ font-family:'xxx（你给字体拟的名称，最好英文如kaiti）' } [代码]

onReady: function () { if(wx.canIUse('loadFontFace')) { console.log("支持自定义字体"); wx.loadFontFace({ family: 'Ping Fang', source: 'url("http://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf")', success: function (res) { console.log("字体加载成功") //  loaded }, fail: function (res) { console.log("字体加载失败") //  erro }, complete: function (res) { console.log("加载完成"); } }); } else { console.log('不支持自定义字体') } }, console内容： 支持自定义字体 VM1237:1 Fri Jun 29 2018 10:19:11 GMT+0800 (中国标准时间) 渲染层网络层错误 VM1237:2 Failed to load font https://developer.mozilla.org/@api/deki/files/2934/=VeraSeBd.ttf net::ERR_TIMED_OUT 

最近有一个需求，需求方一定要求加载自有的字体，一共5个包，加起来要60M，而且因为有后台上传的文章，还不能用字体精简工具压缩字体。 在调用官方的wx.loadfontface的时候，开始看着一切正常，但真机调试的时候，发现每个页面都在重新下载字体。 先不说每个页面抖动的问题，就是流量也扛不住他这么造啊。 社区里面看到有很多人在反馈这个bug，从20年到23年都有 https://developers.weixin.qq.com/community/develop/doc/0006e6ad5b49b02e3bc98398d51000?highLine=loadfontface%2520%25E7%25BC%2593%25E5%25AD%2598 https://developers.weixin.qq.com/community/develop/doc/00084c852f40280d6b2f6461550000?highLine=loadfontface%2520%25E9%2587%258D%25E5%25A4%258D 本来给客户反馈说微信bug，他们也勉强接受，但是上线10天，跑了1000多rmb的流量钱，实在是顶不住，压力又给到开发这边。。。 后面在掘金看到一篇文章（https://juejin.cn/post/7103928278225780743?searchId=2023081018280858E8AD21B4FDD711555A） 本地路径不行，那把本地文件转成base64曲线救国确实是一条思路。 原文是behavior做的，而且是用云开发，但我们的业务场景是需要全局生效，每个页面都写一个behavior也太累了。 于是改造成以下模式。 先创建一个loadFont.js，代码如下 注释写的比较详细了，简述思路： 先用wx.getFileSystemManager().access()看本地有没有，有就直接load，没有就先下载 wx.downloadFile把字体下到本地，再从本地wx.getFileSystemManager().readFile()取出文件并转Base64 最后source: `url("data:font/woff2;charset=utf-8;base64,${res.data}")`,搞定！ // 建议循环调用方法，而不是这个方法内循环下载 // 下载字体文件，注意要把字体域名加到后台downloadFile白名单中 function _downloadFont(fontUrl, filePath, fontFamily) {   wx.downloadFile({     url: fontUrl,     success: res => {       wx.getFileSystemManager().saveFile({ // 下载成功后保存到本地         tempFilePath: res.tempFilePath,         filePath,         success: res => {           // 加载字体           _loadFontFace(fontFamily, res.savedFilePath)         }       })     }   }) } // 加载文件字体转 base64，load function _loadFontFace(fontFamily, filePath) {   // 读文件   wx.getFileSystemManager().readFile({     filePath, // 本地文件地址     encoding: 'base64',     success: res => {       wx.loadFontFace({         global: true, // 是否全局生效         scopes: ['webview', 'native'], //native可能有点问题，超哥生个海报试一下         family: fontFamily, // 字体名称         source: `url("data:font/woff2;charset=utf-8;base64,${res.data}")`,         success(res) {           console.log(fontFamily + '加载成功：' + res.status)         },         fail: function (res) {           console.log(fontFamily + '加载失败' + res)         },       })     }   }) } // fontUrl: 字体地址 // filename: 存储文件路径 // fontFamily: css 中字体的 family function loadCloudFontFace(fontUrl, filename, fontFamily) {   const filePath = `${wx.env.USER_DATA_PATH}/${filename}`   wx.getFileSystemManager().access({     path: filePath,     success: () => {       _loadFontFace(fontFamily, filePath)       console.log('从本地加载了字体');     },     fail: () => {       _downloadFont(fontUrl, filePath, fontFamily)       console.log('从外部加载了字体', fontUrl);     }   }) } module.exports = {   loadCloudFontFace } 由于业务本身的需求，是全局所有字体都用，所以，直接在app.js中（实际上我们是抽了一个文件单独维护的，这里就简化吧） const loadFont = require('./loadFont.js'); loadFont.loadCloudFontFace('https://xxx.com/wxapp/fonts/STHeiti.woff2', 'STHeiti.woff2', 'STHeiti') 并且，在app.wxss，让font-family全局给一个默认字体（事实上还有英文字体，这里简化了） page {   font-family: 'STHeiti'; } 当然也支持每个页面独立配置不同字体，方法大同小异。 真机测试，终于只加载一次网络字体了。 其他注意的事项： 由于第一次仍然要加载字体，会产生抖动，我们的做法是，尽量不在首页用文字，大量用图片替代，同时在后台加载字体，供其他页面使用。对于个别页面需要加载字体时，可以出个loading框（虽然体验依然不好，但我尽力了）直接load网络字体，会存在跨域的问题，有的时候，这个问题确实很难解决（字体一般都用cdn、对象存储一类的，如果有权限操作配置很简单，但很多情况下开发人员确实不好增加跨域配置）。采用这个方案，由于是本地，就不存在跨域问题了，一举多得。 最后还是要吐槽下，这个需求，并不小众。最早从20年就有bug反馈，官方也有回复，但到23年了这个bug还存在，也着实无奈。

默认高度225px，虽然可以通过css自定义高度，但又一些视频他的高度是比如，300,，400,500 我要的效果是宽度100% 然后高度自适应怎么解决？就是说我根据视频的高度来定义高度。但我找半天没知道获取视频高度的方法啊

在使用XR-Frame时，可能经常会使用到 clear-color="0.4 0.6 0.7 1" 这样的颜色设置，如下： <xr-camera position="0 1 4" clear-color="0.4 0.6 0.7 1" background="skybox" target="target" camera-orbit-control="" /> 这个颜色代码具体是什么意思呢？ 首先，前三个参数代表颜色代码，第四个参数代表透明度（0-1）。 其次，对于前三个参数来说，这不是RGB的颜色方法，因为RGB的颜色方法是表示红、绿和蓝三原色的相对亮度值。例如，(255,0,0) 表示的是红色，它的RGB颜色方法的值是（1，0，0），表示红色是由100%红色，0%绿色和0％蓝色组成。 而(0.1, 0.1, 0.1) 是RGB颜色模型中使用的RGB颜色空间值的归一化版本（从0到1）。它并没有实际的颜色含义，但它可以被用来表示非常暗的灰色。 运算方法： rgb颜色值 除以 255即可！ 如：RGB(227,176,242) 227/255 = 0.89 176/255 = 0.69 242/255 = 0.94 （保留两位小数） 归一化处理后即 为（0.89 0.69 0.94） 保持不透明（0.89,0.69,0.94,1）

春节假期，终于有时间研究了小程序 XR-FRAME的情况。尽管现在XR-FRAME 还是Beta 版本，但可以说这是小程序进入元宇宙的一个关键节点（希望尽快转正式）。上手入门教程和说明都十分平易近人，基本就是手把手的带入门，这个的确要赞一下。不过呢，可能这文档都比较早，之后都没怎么更新了，我就说说一下我这边入门的关键点吧。 1、真机调试，入门教程文档里忘记提到一个关键点就是需要在APP.JSON建立一个分包。 代码如下： "subpackages": [{   "root": "packageA",    "pages": ["pages/cat"]  }], 没这分包真机调试怎么都不能起来会报错，但预览可以调用；之前没发现这个费了我不少时间进行测试和找原因。 2、看社区不少同学问调用前置摄像头，其实就加个在xr-scene加给参数camera:Front。 代码如下： 这样就能顺利通过xr-camera进行调用了。 3、xr-frame与小程序view的通信，其实我的理解就是通过原来的view再加载xr-frame的组件应用，所以他们间可以通过父子组件进行通信，这个我没有太深入研究，就用了this.triggerEvent()完事，万幸也成功了。。 最后，一个的确没法搞掂的事情就是，video-texture加载的MP4视频死活都没声音和只能播放一段，我个人觉得因为video-texture是一个简单的视频图像渲染，没有将声音带过来，所以就没有声音了。这个目前我也没深研了，不过这个是AR的一个关键点，望尽快处理吧。最后的最后，以上是本人实战研究的一下小经验，也给后来者一点提醒吧，不用走太多弯路。

小程序性能优化课程基于实际开发场景，由资深开发者分享小程序性能优化的各项能力及应用实践，提升小程序性能表现，满足用户体验。

我用webpack4开发小程序 哈，本人是REACT系开发者，工作中需要不停的折腾webpack，为了顺带学习VUE的开发思想和思路，顺理成章的请缨为公司小程序打个框架基础。前期也去了解了下各个小程序开发框架，大体上是通过转义的思路来解决小程序和VUE/REACT的模板、逻辑关系，不做展开讨论了。只是从本人角度分享通过webpack来构建小程序的开发架构。 通过观察小程序的原有架构，不难发现其已经是一套比较完善的mvvm架构了(类VUE)，融合了VUE及REACT的一些特点(以VUE为主)，但却有一些不足，缺失了前端开发人员常用的npm包的引入，动态样式的编译等等提升开发效率的工作环境、模式。因此我想如果通过webpack4来为原有架构做一个有益的补充，这样原生架构不就很完美了吗？ 思路 对等编译输出小程序项目的所有文件(严格按照小程序需要的文件及目录结构输出)。js/wxs通过babel编译输出，wxml/json直接输出，wxss通过stylus编译输出(我们使用stylus开发样式)，顺带使用webpack抽离公共模块文件[代码]common.js[代码]，并将runtime运行时抽离作为一个独立文件。这样既精简了代码，又享用到了webpack为我们带来的好处。嗯，看上去很简单嘛，实际上却是踩了不少的坑！脚上的茧老厚了~~~ webpack module配置 [代码]module: { rules: [ { test: /\.(wxml|axml)/, // 为支付宝小程序留了个伏笔，哈哈 use: [ relativeFileLoader(isWechat ? 'wxml' : 'axml'), // 这里使用file-loader简单封装了一下 'extract-loader', 'html-loader' ] }, { test: /\.(jp(e?)g|png|gif)$/, use: relativeFileLoader() }, { test: /\.wxss$/, include: SRC, use: relativeFileLoader(), }, { test: /\.wxs$/, include: SRC, exclude: /node_modules/, use: [ relativeFileLoader(), { loader: 'babel-loader', options: { babelrc: false, presets: [ 'es2015', 'stage-0' ] }, } ] }, { test: /\.js$/, use: { loader: 'happypack/loader', options: { id: 'babel' } }, exclude: /node_modules/, }, { test: /\.styl$/, include: SRC, use: [ relativeFileLoader(isWechat ? 'wxss' : 'acss'), 'stylus-loader' ] } ] }, [代码] 熟悉webpack的同学通过上面的moudle配置应该能够看出资源文件编译的思路，当然直接这样配置肯定做不到正确编译，还有一些坑需要踩 全文件entry 为了对等输出，我们需要把所有文件整理为entry给webpack处理，这样的好处是js能够使用npm包，所有文件都能够支持热更新机制(webpack的热更新响应非常快，gulp的热更新很难精细控制，当项目足够大的时候，响应很慢) [代码]function entries(dir) { var jsFiles = {} let _partten = /[\/|\\][_](\w)+/; let re_common = /(.*)\/common\// const accessExts = ['.wxml', '.wxss', '.styl', '.wxs', '.json', '.png', '.jpg', '.jpeg', '.gif'] if (fse.existsSync(dir)) { globby.sync([`${dir}/**/*`, `!${dir}/js/**/cloudfunctions`, '!node_modules', `!${dir}/dist`]).forEach(function (item) { if (!re_common.test(item)) { if (!_partten.test(item)) { const fileObj = path.parse(item) const xcxSrc = path.join(dir, 'js') if (~item.indexOf(xcxSrc)) { const fileStat = fs.statSync(item) const relativeFile = item.replace(xcxSrc, '') let relativeKey = relativeFile.replace(fileObj.ext, '').substring(1) if (fileObj.ext == '.js') { jsFiles[relativeKey] = item } else { if (accessExts.indexOf(fileObj.ext) > -1) { jsFiles['nobuild__' + relativeFile] = item } } } } } }) } return jsFiles } [代码] 上述是entry的生成代码，涵盖了小程序目录结构下的所有需要的文件，并加上了一些特定的标识，以便于后续文件编译输出 非JS文件的输出 在entry方法中我们将wxml，wxss等文件作为entry统统灌给webpack去处理，正常我们使用webpack时是不会把非js文件作为entry输给webpack的。你猜webpack会报错吗，----- 哈哈，报错就讲不下去了，webpack会傻傻的把每个entry文件都当做js来对待，并且正常输出，[代码]*.wxml.js[代码]，等等，这是什么鬼，我并不需要这样的东东。加个插件来处理一下 [代码]compiler.hooks.compilation.tap('wpConcatFile', (compilation, params) => { compilation.hooks.beforeChunkAssets.tap('wpConcatFile', () => { compilation.chunks = compilation.chunks.filter(function (item) { return item.name.indexOf('nobuild__') == -1 }) }) ... ... } [代码] [代码]nobuild__[代码]是在生成entry代码是给非js文件加上的prefix前缀，在插件中我们排除掉非js，将正常的js文件重新chunk，js文件就能够正常的输出了，那么那些非js文件呢？webpack并不会编译生成它们，中途它们就会被module中的[代码]xx-loader[代码]处理完,然后被[代码]file-loader[代码]给甩出去了。 全局变量替换 将全局变量替换为微信小程序的[代码]wx[代码]，我们通过插件解决 [代码]const globalVar = 'wx' ... ... ... let contentObj = compilation.assets[file] let code = contentObj.source() code = code.replace(windowRegExp, that.globalVar); contentObj = new RawSource(code) compilation.assets[file] = new ConcatSource( contentSource, '\n', '\/**auto import common&runtime js**\/', '\n', contentObj, ); [代码] 通过上述代码不难看出，我们读取了每个文件的源码，并将全局变量[代码]window/global[代码]替换为[代码]wx[代码]，再进行源码重组。 运行时文件引入 我们需要引入[代码]runtime.js[代码]和[代码]common.js[代码]文件，[代码]runtime[代码]运行环境是webpack为每个编译文件插入的用于解析[代码]define, require, module[代码]等等这些的文件引入方法，为了精简文件，我们将之抽离为[代码]runtime.js[代码]，[代码]common.js[代码]为我们抽离出来的公共模块文件。在web/h5下引入这些资源是不是so easy，但你还记得我们是在小程序环境下嘛，并不能通过[代码]<script>[代码]标签来引入资源文件啊啊啊，你会不会猛拍脑门，一下就慌了(哈哈)。老办法，我们通过插件解决 [代码]const lens = [] let posixPath = '' const matchIt = chunk.name.match(/\//g) if (matchIt) { matchIt.forEach(it => lens.push(this.prePath)) // posixPath = './'+lens.join('') posixPath = lens.join('') } else { posixPath = './' } let posixPathFile = posixPath + 'runtime.js' let contentSource = this.contentSource.replace('~~~~', posixPathFile) if (chunk.name.indexOf('runtime') > -1) { posixPathFile = posixPath + 'common.js' if (hasCommon) { contentSource = this.contentSource.replace('~~~~', posixPathFile) } else { contentSource = '' } } [代码] 上述代码片段中，[代码]posixPath[代码]是我们通过一个小的算法来推算资源引入的路径深度变量，输出并重写源文件chunk，这样我们就解决了资源引入的问题 webpack-dev-server 引入webpack-dev-server能够使得webpack的编译能够简单的输出到硬盘上，webpack默认是内存文件系统，并不输出(当然有其他方法，比如再写个插件或更换文件系统啥的)，除了文件输出，webpack-dev-server还能够为我们提供mock数据服务，呵呵~，这里不展开了，大家有兴趣百度一下，还能够为我们访问后台接口作proxy，这里也不展开了。 通过上述操作，我们就能得到小程序结构的对等输出，剩下我们只需要将输出文件导入到小程序编辑器中，接下来就是开发工作了。嗯，这样就可以开始给小程序搬砖了，开心吗？ 如果你想参考一下我们的编译代码，可以看这里 https://github.com/webkixi/aotoo-hub/blob/master/build/webpack.xcx.config.js 如果你想了解下我们的架构，可以看这里 https://github.com/webkixi/aotoo-hub 如果你想使用我们的架构，怕不怕？怕的话，你看着办吧，哈哈! 不怕看这里 https://www.npmjs.com/package/aotoo-cli 如果你还想看看我们的小程序，看这里 https://developers.weixin.qq.com/community/develop/article/doc/0006aafd158f40f4e588c546d5d013 [图片]

大家都知道产品体验的重要性，而其中最重要的就是加载速度，一个产品如果打开都很慢，可能也就没有后面更多的事情了。这篇文章是我最近项目中的一些加载优化总结，欢迎大家一起讨论交流。 内容包括： 性能指标及数据采集 性能分析方法 性能优化方法 性能优化具体实践 第一部分：性能指标及数据采集 要优化性能首先需要有一套用来评估性能的指标，这套指标应该是是可度量、可线上精确采集分析的。现在来一起看看如何选择性能指标吧。 1. 性能指标 加载的过程是一个用户的感知变化的过程。所以我们的页面性能指标也是要以用户感知为中心的。下面是google定义了几个以用户感知为中心的性能指标。 1.1 以用户感知为中心的性能指标 首先确定页面视觉的变化传递给用户的感知变化关键点： 感知点 说明 发生了吗？ 浏览是否成功。 有用了吗？ 是否有足够的内容呈现给用户。 可用了吗？ 用户是否可以和页面交互了。 好用吗？ 用户和应用交互是否流畅自然。 我这里讲的是加载优化，所以第四点暂时不讨论。下面是感知点相关的性能指标。 First paint(FP) and first contentful paint(FCP) FP: Webview跳转到应用的首次渲染时间。 FCP：Webview首次渲染内容的时间:文本，图像（包括背景图像），非白色画布或SVG。这是用户第一次消费内容的时间。 Chrome支持用Paint Timing API获取这两个值： [代码] performance.getEntriesByType("paint") [代码] First meaningful paint(FMP) 首次绘制有效内容的时间，用来表明这个应用是否绘制了有效内容。比如天气应用可以看到天气了，商品列表可以看到商品了。 Time to Interactive(TTI) 应用可交互时间，这时应用渲染完成且可以响应用户输入的时间。这种情况下JS已经加载完成且主线程处于空闲状态。 Speed index 速度指标：代表填充页面内容的速度。要想降低速度指标分数，您需要让加载速度从视觉上显得更快，也就是渐进式展示。 上面指标对应的感知点如下： 感知点 说明 发生了吗？ FP/FCP 有用了吗？ FMP 可用了吗？ TTI Speed index是个整体效果指标所以没有对应上面的任何一个，但也同时对应任何一个。 对于实际项目中我们选取指标要便于采集，下面是针对我的实际项目（APP内的单页面应用）选取的性能指标。 1.2 实际项目选取的性能指标 Webview加载时间 反应Webview性能。这样就可以更真实的知道我们应用的加载情况。 页面下载时间 反应浏览成功时间。 应用启动时间 反应应用启动完成时间，这个时候页面初始化完成，是JS首次执行完成的时间，应用所需异步请求都已经发出去了。 首次有效绘制内容时间 已经有足够的内容呈现给用户，是首屏所需重要接口返回且DOM渲染完成的时间，这个时间由程序员自行判断。 应用加载完成时间 应用完整的呈现给了用户，这个时候页面中所有资源都已经下载好，包括图片等资源。 这里我们的性能指标确定了，下面看看这些数据怎么采集吧。 2. 数据采集 performance.timing为我们提供页面加载每个过程的精确时间，如下图： [图片] 是不是很完美，这足够了？还不够，我们还需要加上原生APP为我们提供的点击我们应用的时间和我们自己确定的FMP才够完美。 下面是每个指标的获取方法： 公用代码部分 [代码]let performance = window.performance || window.msPerformance || window.webkitPerformance; if (performance && performance.timing) { let t = performance.timing; let navigationStart = t.navigationStart; //跳转开始时间 let enterTime = ""; //app提供的用户点击应用的时间，需要和app沟通传递方式 //... 性能指标部分 } [代码] Webview加载时间 [代码] let webviewLoaded = navigationStart - enterTime; [代码] 注意：enterTime应该是客户端ms时间戳，不是服务器时间。 页面下载时间 [代码] let pageDownLoadedTime = t.responseEnd - navigationStart; [代码] 应用启动时间 [代码]let appStartTime = t.domContentLoadedEventStart - navigationStart; [代码] 首次有效绘制内容时间 这里我们需要在有效绘制后调用 [代码]window._fmpTime = +(new Date())[代码]获取当前时间戳。 [代码]let fmpTime = window._fmpTime - navigationStart; [代码] 应用加载完成时间 [代码]let domCompleteTime = t.domComplete - navigationStart; [代码] 最后在document load以后使用上面代码就可以收集到性能数据了，然后就可以上报给后台了。 [代码]if (document.readyState == 'complete') { _report(); } else { window.addEventListener("load", _report, false); } [代码] 这样就封装了一个简单性能数据采集上报组件，这是非常通用的可以用在类似项目中使用只要按照标准提供enterTime和window._fmpTime就可以。 3. 数据分析 有了上面的原始数据，我们需要一些统计方法来观察性能效果和变化趋势，所以我们选取下面一些统计指标。 平均值 注意在平均值计算的时候要设置一个取值范围比如：0～10s以防脏数据污染。 平均值的趋势用折线图展示： [图片] 分布占比 可以清晰的看到用户访问时间的分布,这样你就可以知道有多少用户是秒开的了。 分布占比可以使用折线图、堆积图、饼状图展示： [图片] [图片] [图片] 第二部分：性能分析方法 上面有了性能指标和性能数据，现在我们来学习一下性能分析的一些方法，这样我们才能知道性能到底哪里不行、为什么不行。 1. 影响性能的外部因素 分析性能最重要的一点要确定外部因素。经常会有这种情况，有人反应页面打开速度很慢，而你打开速度很快，其实可能并不是页面性能不好，只是外部因素不同而已。 所以做好性能优化不能只考虑外部因素好的情况，也要让用户能在恶劣条件（如弱网络情况）下也有满足预期的表现。下面看看影响性能的外部因素主要有哪些。 1.1 网络 网络可以说是最影响页面性能最重要的外部因素了，网络的主要指标有： 带宽：表示通信线路传送数据的能力，即在单位时间内通过网络中某一点的最高数据率，单位有bps(b/s)、Kbps(kb/s)、Mbps(mb/s)等。常说的百兆带宽100M就是100Mbps,理论下载最大速度12.5MB/s。 时延：Delay，指数据从网络的一端传送到另一端所需的时间，反应的网络畅通程度。 往返时间RTT：Round-Trip Time，是指从发送端发送数据到接收端接受到确认的总时间。我们经常用的ping命令就是用这个指标表明我们和目标主机的网络顺畅程度。比如我们要对比几个翻墙代理哪里个好，我们就可以ping一下，看看这几个代理哪个RTT低来作出选择。 [图片] 这三个主要指标中后面两个类似，在Chrome中模拟网络主要用设置带宽和网络延迟（往返时间RTT出现最小延迟）来模拟网络。我们电脑一般用的是WI-FI（百兆），那么我们模拟网络，主要模拟常见3G（1兆）、4G（10兆）网络就好，这样我们就覆盖了三个级别的网络情况了。 可以在Chrome的NetWork面板直接选取Chrome模拟好的网络,这个项目network-emulation-conditions中有默认模拟网络的速度。 [图片] 如果默认不满足，你也可以自己配置网络参数，在设置面板的Throttling。 [图片] 上面设置的3G接近100KB/s,4G 0.5MB/s。你可以根据自己的需要来调整这个值，这两个值的差异应该能很好两种不同的网络情况了。设置模拟网络只要能覆盖不同的带宽情况就好，也不用那么真实因为真实情况很复杂。网络部分就介绍完了，接着看其他因素。 1.2 用户机器性能 经常会有这种情况，一个应用在别人手机上打开速度那么快、那么流畅，为啥到我这里就不行了呢？原因很简单人家手机好，自然有更好的配置、更多的资源让程序运行的更快。 Chrome现在非常强大你可以通过performance面板来模拟cpu性能。也可以让你看到应用在低性能机器上的表现。 [图片] 1.3 用户访问次：首次访问、2次访问、发版本访问 用户访问次数也是分析性能的重要外部因素，当用户第一次访问要请求所有资源，后面在访问因为有些资源缓存了访问速度也会不同。当我们开发者又发版本，会更新部分资源，这样访问速度又会跟着变。因为缓存的效果存在，所以这三种情况要分开分析。同时也要注意我们是否要支持用户离线访问。 通过在Chrome中的Network面板中选中Disable cache就可以强制不缓存了，来模拟首次访问。 [图片] 1.4 因素对选取 上面的外部因素虽然只有3种但相乘也有不少情况，为了简化我们性能分析，要选取代表性的因素去分析我们的性能。下面是指导因素对： 网络：WIFI 3G 4G 用户访问状态：首次 2次 这样有6种情况不算特别多，也能很好反应我们应用在不同情况下的性能。 2. devtools具体分析性能 通过devtools可以观察在不同外部因素下代码具体加载执行情况，这个工具是我们性能分析中最重要的工具，加载优化这里我们主要关注两个面板：Network、Performance。 先看Network面板的列表页： [图片] 这是网络请求的列表，右击表头可以增删属性列，根据自己需要作出调整。 下面我介绍网络列表中的几个重点属性： Protocol:网络协议，h2说明你的请求是http2协议的了。 Initiator:可以查到这个资源是哪里引用的。 Status:网络状态码。 Waterfall:资源加载瀑布流。 下面在看看Network面板中单个请求的详情页： [图片] 这里可以看到具体的请求情况，Timing面板是用来观察这次网络的请求时间占用的具体情况，对我们性能分析非常重要。具体每个时间段介绍可以点击Explanation。 虽然Network面板可以让我看到了网络请求的整体和单个请求的具体情况，但Network面板整体请求情况看着并不友好，而且也只有加载情况没有浏览器线程的执行情况。下面看看强大的Performance面板的吧。 [图片] 这里可以清晰看到浏览器如何加载资源如何解析html、解析css、执行js和渲染绘制的。 Performance简直太强大了，所以请你务必要掌握它的使用，这里篇幅有限，只能介绍了个大概，建议到google网站仔细学习一下。 3. Lighthouse整体分析性能 使用Lighthouse可以对应用做整体性能分析评分，并且会给我们专业的指导建议。我们可以安装Lighthouse插件或者安装Lighthouse npm包来使用它。 检测结果中可以看到很多性能指标的分值和建议。你也可以去测试下你的应用表现。 4. 线上用户统计分析性能 虽然使用devtools和Lighthouse可以知道页面的性能情况，但我们还要观察用户的真实访问情况，这才能真实反映我们应用的性能。线上数据采集分析，第一步部分已经介绍过了，这里就不在多说了。优化完看看自己对线上数据到底造成了什么影响。 上面介绍了性能分析的方法，可以很好帮你去分析性能，有了性能分析的基础，下面我们在来看看怎么做性能优化吧。 第三部分：性能优化方法 1. 微观：优化单次网络请求时间 在性能分析知道Network面板可以看到单次网络请求的详情 [图片] 从图可以看出请求包括：DNS时间、TCP时间、SSL时间（https）、TTFB时间（服务器处理时间）、ContentLoaded内容下载时间，所以有下面公式： [代码]requestTime = DNS + TCP + SSL+ TTFB +ContentLoaded [代码] 所以只要我们降低这里面任意一个值就可以降低单次网络请求的时间了。 2. 宏观：优化整体加载过程 加载过程的优化就是不断让第一部分的性能指标感知点提前的过程。通过关键路径优化、渐进式展示、内容效率优化手段，来优化资源调度。 2.1 加载过程 在介绍页面加载过程，先看看渲染绘制过程： [图片] Javascript:操作DOM和CSSOM。 样式计算：根据选择器应用规则并计算每个元素的最终样式。 布局：浏览器计算它要占据的空间大小及其在屏幕的位置。 绘制：绘制是填充像素的过程。 合成。由于页面的各部分可能被绘制到多层，合成是将他们按正确顺序绘制到屏幕上，正确渲染页面。 渲染其实是很复杂的过程这里只简单了解一下，想深入了解可以看看这篇文章。 了解了渲染绘制过程，在学习加载过程的时候就可以把它当作黑盒了，黑盒只包括渲染过程从样式计算开始，因为上面的Javascript主要是用来输入DOM、CSSOM。 浏览器加载过程： Webview加载 下载HTML 解析HTML：根据资源优先级加载资源并构建DOM树 遇到加载同步JS资源暂停DOM构建，等待CSSOM树构建 CSS返回构建CSSOM树 用已经构建的DOM、CSSOM树进行渲染绘制 JS返回执行继续构建DOM树，进行渲染绘制 当HTML中的JS执行完成，DOM树第一次完整构建完成触发：domContentLoaded 当所有异步接口返回后渲染制完成，并且外部加载完成触发：onload 注意点： CSSOM未构建好页面不会进行任何渲染 脚本在文档的何处插入，就在何处执行 脚本会阻塞DOM构建 脚本执行要等待CSSOM构建完成后执行 下面看看如何在加载过程提前感知点。 2.2 优化关键路径 把关键路径定义为：从页面请求到应用启动完成这个过程，也就是到JS执行完domContentLoaded触发的过程。 主要指标有： 关键资源: 影响应用启动完成的资源。 关键资源的数量：这个过程中加载的资源数据。 关键路径长度：关键资源请求的串行长度。 关键字节的数量：关键资源大小总和。 [图片] 上图关键资源有：html、css、3个js。关键资源数量：5个。关键字节的数量：5个资源的总大小。关键路径长度：2，html+剩余其他资源。 关键优化路径优化，就是要降低关键路径长度、关键字节的数量，在http1时代还要降低关键资源的数量，现在http2资源数不用关心。 2.3 优化内容效率 主要是关注的应用加载完成这个时间点，由首页加载完成所需的资源量决定。我们要尽量减少加载资源的大小，避免不必要加载的资源，比如做一些图片压缩懒加载尽快让应用加载完成。 主要指标有： 应用加载完成字节数：应用加载完成，所需的资源大小。 这个指标可以从Chrome上观察到，不过要剔除prefetch的资源。这个指标一般不太稳定，因为页面展示的内容不太相同，所以最好在相同内容相同情况下对比。 2.4 渐进式展示 从上面的加载过程中，可以知道渲染是多次的。那样我们可以先让用户看到一个Loading提示、先展示首屏内容。Loading主要优化的是FP/FCP这两个指标，先展示首屏主要是优化FMP。 3. 缓存：优化多次访问 缓存重点强调的是二次访问、发版访问、离线访问情况下的优化。 通过缓存有效减少二次访问、发版访问所要加载资源，甚至可以让应用支持离线访问，而且是对弱网络环境是最有效的手段，一定要善于使用缓存这是你性能优化的利器。 4. 优化手段 优化手段我归纳为5类：small（更小）、pre（更早）、delay（更晚）、concurrent（并发）、cache（缓存）。性能优化就是将这5种手段应用于上面的优化点：网络请求优化、关键路径优化、内容效率优化、多次访问优化。 5. 构建自己可动态改变的优化方法表和检查表 Checklist包括两部分，一个优化方法表，另外一个优化方法检查表。优化方法表是让我们对我们的性能优化方法有个评估和认识，优化方法检查表的好处是，可以清晰的知道你的项目用了哪些优化方法，还有哪些可以尝试做进一步优化，同时作为一个新项目的指导。 优化名：优化方法的名字。 优化介绍：对优化方法做简单的介绍。 优化点：网络请求优化、关键路径优化、内容效率优化、多次访问优化。 优化手段：small、pre、delay、concurrent、cache。 本地效果：选取合适的因素对，进行效果分析，确定预期作用大小。 线上效果：线上效果对比，确定这个优化方案的有效性及实际作用大小。 这样我们就能大概了解了这个效果的好处。我们新引入了一种优化方法都要按这张表的方法进行操作。 优化方法表： 名称 内容 优化名 JS压缩 优化介绍 压缩JS 优化点 关键路径优化 优化手段 small 本地效果 具体本地效果对比 线上效果 线上数据效果 上面是以JS压缩为例的优化方法表。 优化方法检查表： 分类 优化点 是否使用 不适用 问题说明 small JS压缩 √ pre preload/prefetch √ 不需要 通过这张表就能看出我们使用了哪些方法，还有哪些没使用，哪些方法不适用我们。可以很方便的应用于任何一个新项目。 第四部分：性能优化具体实践 现在就看看我在项目中的具体实践吧，项目中使用的技术栈是：Webpack3+Babel7+Vue2，下面我按照优化手段介绍： 1. small（更小） scope-hoisting scope-hoisting(作用域提升)：Webpack分析出模块之间的依赖关系，把可以合并到一起模块合并到一起，但不造成冗余，因此只有被一个地方引用的代码可以合并到一起。这样做函数声明会变少，可以让代码更小、执行更快。 这个功能从Webpack3开始引入,依赖于ES2015模块的静态分析，所以要把Babel的preset要设置成[代码]"modules": false[代码]： [代码] ... [ "@babel/preset-env", { "modules": false ... [代码] Webpack3要引入ModuleConcatenationPlugin插件，Webpack4 product模式已经预置该插件： [代码]... new webpack.optimize.ModuleConcatenationPlugin(), ... [代码] [图片] 如上图，不压缩的JS中可以文件中看到CONCATENATED MODULE这就说明生效了。 tree-shaking 摇树：通常用于描述移除JavaScript上下文中的未引用代码，在webpack2中开始内置。依赖于ES2105模块的静态分析，所以我们使用babel同样要设置成 [代码]"modules": false[代码]。 [图片] 如上图，不压缩的JS中可以文件中看到unused harmony这就说明摇树成功了。 code-splitting(按需加载) 代码分片，将代码分离到不同的js中，进行并行加载和按需加载。 代码分片主要有两种： 按需加载：动态导入 vendor提取：业务代码和公共库分离 这里只介绍按需加载部分，动态导入Webpack提供了两个类似的技术。1. Webpack特定的动态导入require.ensure。2.ECMAScript提案[代码]import()[代码]。这里我只介绍我使用的[代码]import()[代码]这种方法。因为是推荐方法。 代码如下： Babel配置支持动态导入语法： [代码]... "@babel/plugin-syntax-dynamic-import", ... [代码] 代码中使用： [代码]... if(isDevtools()){ import(/* webpackChunkName: "devtools" */'./comm/devtools').then((devtools)=>{ let initDevtools = devtools.default; initDevtools(); }); } ... [代码] polyfill按需加载 我们代码是ES2015以上版本的要真正能在浏览器上能使用要通过babel进行编译转化，还要使用polyfill来支持新的对象方法,如：Promise、Array.from等。对于不同环境来说需要polyfill的对象方法是不一样的，所以到了Babel7支持了按需加载polyfill。 下面是我项目中的配置，看完以后我会介绍一下几个关键点： [代码]module.exports = function (api) { api.cache(true); const sourceType = "unambiguous"; const presets = [ [ "@babel/preset-env", { "modules": false, "useBuiltIns": "usage", // "debug": true, "targets": { "browsers": ["Android >= 4.0", "ios >= 8"] } } ] ]; const plugins= [ "@babel/plugin-syntax-dynamic-import", "@babel/plugin-transform-strict-mode", "@babel/plugin-proposal-object-rest-spread", [ "@babel/plugin-transform-runtime", { "corejs": false, "helpers": true, "regenerator": false, "useESModules": false } ] ]; return { sourceType, presets, plugins } } [代码] @babel/preset-env preset是预置的语法转化插件的集合。原来有很多preset如：@babel/preset-es2015。直到出现了@babel/preset-env，它可以根据目标环境来动态的选择语法转化插件和polyfill，统一了preset众多的局面。 [代码]targets[代码]：是我们用来设置环境的，我的应用支持移动端所以设置了上面那样,这样就可以只加载这个环境需要的插件了。如果不设置[代码]targets[代码]通过@babel/preset-env引入的插件是 @babel/preset-es2015、@babel/preset-es2016和@babel/preset-es2017插件的集合。 [代码]"useBuiltIns": "usage"[代码]:将useBuiltIns设置为usage就会根据执行环境和代码按需加载polyfill。 @babel/plugin-transform-runtime 和polyfill不同，@babel/plugin-transform-runtime可以在不污染全局变量的情况下，使用新的对象和方法，并且可以移除内联的Babel语法转化时候的辅助函数。 我们这里只用它来移除辅助函数，不需要它来帮我处理其他对象方法，因为我们在开发应用不是做组件不怕全局污染。 sourceType:“unambiguous” 一个文件混用了ES2015模块导入导出和CJS模块导入导出。需要设置[代码]sourceType:"unambiguous"[代码],需要让babel自己猜测类型。如果你的代码都很合规不用加这个的。 压缩：js、css js、css压缩应该最基本的了。我在项目中使用的是[代码]UglifyJsPlugin[代码]和[代码]optimize-css-assets-webpack-plugin[代码]，这里不做过多介绍。 压缩图片 通过对图片压缩来进行内容效率优化，可以极大的提前应用加载完成时间，我在项目中做了下面两件事。 广告图片，限制大小50K以内。原来基本会上传超过100K的广告图。 项目中图片使用的[代码]img-loader[代码]对图片进行压缩。 HTTP2支持，去掉css中base64图片 先看看HTTP1.1中的问题： 同一域名浏览器做了TCP连接数的限制，如：Chrome中只能有6个。 一个TCP连接只能同时处理一个请求响应。 在看看HTTP2的优势： 二进制分帧：HTTP2的性能增强的核心在于新的二进制分帧层。帧是最小传输单位，帧组成消息，数据以消息形式发送。 多路复用：所有请求在一个连接上完成，可以支持多数据流混合传输，在接收端拼接。 头部压缩：使用HPACK对头部压缩，网络中可以传递更少的数据。 服务端推送：服务端可以主动向客户端推送资源。 有了HTTP2我们在也不用担心资源数量，不用在考虑减少请求了。像：base64图片打到css、合并js、域名分片、精灵图都不要去做了。 这里我把原来base64压缩图片从css中去除了。 2. pre（更早） preload prefetch preload：将资源加载和执行分离，你可以根据你的需要指定要强制加载的资源，比如后面css要用到一个字体文件就可以在preload中指定加载，这样提高了页面展示效果。建议把首页展示必须的资源指定到preload中。 prefetch：用来告诉浏览器我将来会用到什么资源，这样浏览器会在空闲的时候加载。比如我在列表页将详情页js设置成prefetch，这样在进入详情页的时候速度就会快很多，因为我提前加载好了。 这里我用的是来使用[代码]preload-webpack-plugin[代码]preload和prefetch的。 代码： [代码]... const PreloadWebpackPlugin = require('preload-webpack-plugin'); ... new PreloadWebpackPlugin({ rel: 'prefetch', include: ['devtools','detail','VideoPlayer'] }), ... [代码] dns-prefetch preconnect dns-prefetch：在页面中请求该域名下资源前提前进行dns解析。preconnect：比dns-prefetch更近一步连TCP和SSL都为我们处理好了。 使用注意点：1. 考虑到兼容性问题，我们对一个域名两个都设置 2. 对于应用中不一定会使用的域名我们设置dns-prefetch就好以防占用资源。 代码如下： [代码]... <link rel="preconnect" href="//game.gtimg.cn"> ... <link rel="dns-prefetch" href="//game.gtimg.cn"> ... [代码] 3. delay（更晚） lazyload 对图片进行懒加载，我使用的是[代码]vue-lazyload[代码]。 代码如下： [代码]... import VueLazyload from 'vue-lazyload' ... Vue.use(VueLazyload, { preLoad: 1.3, error: '...', loading: '...', attempt: 1 }); ... <div class='v-fullpage' v-lazy:background-image="item.roomPic" :key="item.roomPic"></div> ... [代码] 这里的:key特别注意，如果你的列表数据是动态变化的一定要设置，否则图片是最开始一次的。 code-splitting(按需加载) code-splitting(按需加载)前面已经介绍过这里只是强调下它的delay作用，不使用的部分先不加载。 4. concurrent（并发） HTTP2 HTTP2前面已经应用在了css体积减少，这里主要强调它的多路复用。需要大家看看自己的项目是否升级到HTTP2，是否所有资源都是HTTP2的，如果不是的，需要推进升级。 code-splitting(vendor提取) vendor提取是把业务代码和公共库分离并发加载，这样有两个好处： 下次发版本这部分不用在加载（缓存的作用）。 JS并发加载：让先到并在前面的部分先编译执行，让加载和执行并发。 Webpack配置： [代码] ... entry:{ "bundle":["./src/index.js"], "vendor":["vue","vue-router","vuex","url","fastclick","axios","qs","vue-lazyload"] }, ... new webpack.optimize.CommonsChunkPlugin({ name: "vendor", minChunks: Infinity }), new webpack.optimize.CommonsChunkPlugin({ name: 'manifest' }), ... [代码] 5. cache（缓存） HTTP缓存 HTTP缓存对我们来说是非常有用的。 下面介绍下HTTP缓存的重点： Last-Modified/ETag：用来让服务器判断文件是否过期。 Cache-Control：用来控制缓存行为。 max-age: 当请求头设置max-age=deta-time，如果上次请求和这次请求时间小于deta-time服务端直接返回304。当响应头设置max-age=deta-time，客户端在小于deta-time使用客户端缓存。 强制缓存：这主要把不经常变化的文件设置强制缓存，这样就不需要在发起HTTP请求了。通过设置响应头Cache-Control的max-age设置。 如果像缓存很久设置一个很大的值，如果不想缓存设置成：Cache-Control：no-cahce。 协商缓存：如果没有走强制缓存就要走协商缓存，服务器根据Last-Modified/ETag来判断文件是否变动，如果没变动就直接返回304。 这里我们做的就是让运维调整资源的强制缓存时间，前端在结合文件hash命名就可以进行资源更新了。 ServiceWorker ServiceWorker是Web应用和浏览器之间的代理服务器，可以用来拦截网络来进行资源缓存、离线体验，还可以进行推送通知和后台同步。功能非常强大，我们这里使用的是资源缓存功能，看看和HTTP缓存比有什么优势： 功能多：支持离线访问、资源缓存、推送通知、后台同步。 控制力更强：缓存操作+络拦截功能都由开发者控制，可以做出很多你想做的事情比如动态缓存。 仅HTTPS下可用，更安全。 看看我在项目中的使用： js使用HTTP缓存和ServiceWorker双重缓存在cacheid变化后依然可以缓存。 不得对service-worker.js缓存，因为我们要用这个更新应用。在Chrome中看到请求的cache-control被默认设置了no-cache。 我们项目中使是Google的Workbox,Webpack中插件是 workbox-webpack-plugin。 [代码]... const WorkboxPlugin = require('workbox-webpack-plugin'); ... new WorkboxPlugin.GenerateSW({ cacheId: 'sw-wzzs-v1', // 缓存id skipWaiting: true, clientsClaim: true, swDest: './html/service-worker.js', include: [/\.js(.*)$/,/\.css$/], importsDirectory:'./swmainfest', importWorkboxFrom: 'local', ignoreUrlParametersMatching: [/./] }), ... [代码] localStorage localStorage项目中主要做接口数据缓存。通常localStorage是没有缓存时间的我们将其封装成了有时间的缓存，并且在应用启动的时候对过期的缓存清理。 code-splitting(vendor提取) 这里在提vendor提取主要是说明它发版本时候的缓存价值，前面介绍过了。 6. 整体优化效果评价 经过上面的优化，看看效果提升吧。 主要增长点来源： 关键路径资源：698.6K降低到538.6K降低22.9% 内容效率提升：广告图由原来的基本100K以上降低到现在50K以下，页面内图片全部走强制缓存。 缓存加快多次访问速度：js+css强制缓存加ServiceWorker。 线上数据效果： 页面下载时间： 平均值下降：25.74%左右 应用启动完成时间： 平均值下降：33.45%左右 秒开占比提高：23.42%左右 应用加载完成时间： 平均值下降：48.02%左右 第六部分：总结 以上就是我在加载优化方面的一些总结，希望对您有所帮助，个人理解有限，欢迎一起讨论交流。

1. 代码质量检测 微信开发者工具->控制台->代码质量 检测以下问题： 图片、资源过大 未使用代码—— 要么删除，要么ignore，开发需要，但配置不打包。 有个与gitignore类似的配置，注意，修改完配置需要重启微信 开发者工具才能看到变化。 https://developers.weixin.qq.com/miniprogram/dev/devtools/projectconfig.html#packOptions 等等 2. 体验评分 微信开发者工具->控制台->调试器->Audits 点击之后操作小程序，打开各个页面，进行各种交互，尽量覆盖全面。 然后查看报告：性能、体验、最佳实践等，根据具体问题改进小程序。 3. 从微信官方文档、运行时性能处，获取到一些可能的切入点 https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips.html 重点，首屏渲染优化： https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/start_optimizeC.html 骨架屏，可以考虑： https://developers.weixin.qq.com/miniprogram/dev/devtools/skeleton.html 4. 其他获取性能数据方式 https://developers.weixin.qq.com/miniprogram/dev/framework/performance/perf_data.html 网络数据测速：https://developers.weixin.qq.com/miniprogram/dev/framework/performanceReport/

我想统计小程序的启动耗时，在首页的onload和onready方法做了打点监听，但是计算出来的时间与debug调试时小程序内部的计算的启动耗时有差。请问大佬们，有没有其他方式可以准确计算这个耗时，主要是看到了控制台这个[system] Launch Time:，想知道这个日志的逻辑？[图片]

小程序 主包不能大于2M 每个分包 不能大于2M 。 总体不能大于20M，之前是8M。 [图片] packages 里的moduleA、moduleB是分包，除packages 都属于主包文件。 但是我在分包内与moduleA同级 放了一张1.8M的图片，在打包时，这个图片是打到主包内的，如果主包大小已经有1.5M了，那么主包将超出上限

“打开率”有解释：从用户点击到首屏渲染完成的留存率 “打开次数”没有解释，想确定下打开次数是指”用户点击“的次数，还是“”首屏渲染完成“的次数呢 “打开率”：在“开发管理-监控告警-性能监控”中的指标“打开次数”：在“统计-交易分析”中的指标