最近一直在折腾[代码]mpvue[代码]写的微信小程序的性能优化，分享下实战的过程。 先上个优化前后的图： [图片] 可以看到打包后的代码量从[代码]813KB[代码]减少到[代码]387KB[代码],Audits体验评分从[代码]B[代码]到[代码]A[代码]，效果还是比较明显的。其实这个指标说明不了什么，而且轻易就可以做到，更重要的是优化小程序运行过程中的卡顿感，请耐心往下看。 常规优化 常规的Web端优化方法在小程序中也是适用的，而且不可忽视。 一、压缩图片 这一步最简单，但是容易被忽视。在tiny上在线压缩，然后下载替换即可。 [图片] 我这项目的压缩率高达[代码]72%[代码]，可以说打包后的代码从[代码]813KB[代码]降到[代码]387KB[代码]大部分都是归功于压缩图片了。 二、移除无用的库 我之前在项目中使用了Vant Weapp，在[代码]static[代码]目录下引入了整个库，但实际上我只使用了[代码]button[代码],[代码]field[代码],[代码]dialog[代码]等几个组件，实在是没必要。 所以干脆移除掉了，微信小程序自身提供的[代码]button[代码]，[代码]wx.showModal[代码]等一些组件基本可以满足需求，自己手写一下样式也不用花什么时间。 在这里建议大家，在微信小程序中，尽量避免使用过多的依赖库。 不要贪图方便而引入一些比较大的库，小程序不同于[代码]Web[代码]，限制比较多，能自己写一下就尽量自己写一下吧。 小程序的优化 咱们首先得看一下官方优化建议，大多是围绕这个建议去做。 一、开启Vue.config._mpTrace = true 这个是[代码]mpvue[代码]性能优化的一个黑科技啊，可能大多数同学都不知道这个，我在官方文档都没有搜到到这个配置，我真的是服了。 我能找到这个配置也是Google机缘巧合下看到的，出处：mpvue重要更新，页面更新机制进行全面升级 具体做法是在[代码]/src/main.js[代码]添加[代码]Vue.config._mpTrace = true[代码]，如： [代码]Vue.config._mpTrace = true Vue.config.productionTip = false App.mpType = 'app' [代码] 添加了[代码]Vue.config._mpTrace[代码]属性，这样就可以看到console里会打印每500ms更新的数据量。如图： [图片] 如果数据更新量很大，会明显感觉小程序运行卡顿，反之就流畅。因此我们可以根据这个指标，逐步找出性能瓶颈并解决掉。 二、精简data 1. 过滤api返回的冗余数据 后端的api可能是需要同时为iOS，Android，H5等提供服务的，往往会有些冗余的数据小程序是用不到的。比如api返回的一个[代码]文章列表[代码]数据有很多字段： [代码]this.articleList = [ { articleId: 1, desc: 'xxxxxx', author: 'fengxianqi', time: 'xxx', comments: [ { userId: 2, conent: 'xxx' } ] }, { articleId: 2 // ... }, // ... ] [代码] 假设我们在小程序中只需要用到列表中的部分字段，如果不对数据做处理，将整个[代码]articleList[代码]都[代码]setData[代码]进去，是不明智的。 小程序官方文档： 单次设置的数据不能超过1024kB，请尽量避免一次设置过多的数据。 可以看出，内存是很宝贵的，当[代码]articleList[代码]数据量非常大超过1M时，某些机型就会爆掉（我在iOS中遇到过很多次）。 因此，需要将接口返回的数据剔除掉不需要的，再[代码]setData[代码]，回到我们上面的[代码]articleList[代码]例子，假设我们只需要用[代码]articleId[代码]和[代码]author[代码]这两个字段，可以这样： [代码]import { getArticleList } from '@/api/article' export default { data () { return { articleList: [] } } methods: { getList () { getArticleList().then(res => { let rawList = res.list this.articleList = this.simplifyArticleList(rawList) }) }, simplifyArticleList (list) { return list.map(item => { return { articleId: item.articleId, author: item.author // 需要哪些字段就加上哪些字段 } }) } } } [代码] 这里我们将返回的数据通过[代码]simplifyArticleList[代码]来精简数据，此时过滤后的[代码]articleList[代码]中的数据类似： [代码][ {articleId: 1, author: 'fengxianqi'}, {articleId: 2, author: 'others'} // ... ] [代码] 当然，如果你的需求中是所有数据都要用到（或者大部分数据），就没必要做一层精简了，收益不大。毕竟精简数据的函数中具体的字段，是会增加维护成本的。 PS： 在我个人的实际操作中，做数据过滤虽然增加了维护的成本，但一般收益都很大，因次这个方法比较推荐。 2. data()中只放需要的数据 [代码]import xx from 'xx.js' export default { data () { return { xx, otherXX: '2' } } } [代码] 有些同学可能会习惯将[代码]import[代码]的东西都先放进[代码]data[代码]中，再在[代码]methods[代码]中使用，在小程序中可能是个不好的习惯。 因为通过[代码]Vue.config._mpTrace = true[代码]在更新某个数据时，我对比放进data和不放进data中的两种情况会有差别。 所以我猜测可能是data是会一起更新的，比如只是想更新[代码]otherXX[代码]时，会同时将[代码]xx[代码]也一起合起来[代码]setData[代码]了。 3. 静态图片放进static 这个问题和上面的问题其实是一样的，有时候我们会通过[代码]import[代码]的方式引入，比如这样： [代码]<template> <img :src="UserIcon"> </template> <script> import UserIcon from '@/assets/images/user_icon.png' export default { data () { return { UserIcon } } } </script> [代码] 这样会导致打包后的代码，图片是[代码]base64[代码]形式（很长的一段字符串）存放在[代码]data[代码]中，不利于精简data。同时当该组件多个地方使用时，每个组件实例都会携带这一段很长的[代码]base64[代码]代码，进一步导致数据的冗余。 因此，建议将静态图片放到[代码]static[代码]目录下，这样引用： [代码]<template> <img src="/static/images/user_icon.png"> </template> [代码] 代码也更简洁清爽。 看一下做了上面操作的前后对比图，使用体验上也流畅了很多。 [图片] 三、swiper优化 小程序自身提供的[代码]swiper[代码]组件性能上不是很好，使用时要注意。参考着两个思路： 【优化】解决swiper渲染很多图片时的卡顿 想请教一下小程序swiper组件的问题 在我使用时，由于需求原因，动态删掉swiper-item的思路不可行（手滑时会造成抖动）。因此只能作罢。但仍然可以优化一下： 将未显示的[代码]swiper-item[代码]中的图片用[代码]v-if[代码]隐藏到，当判断到current时才显示，防止大量图片的渲染导致的性能问题。 四、vuex使用注意事项 我之前写过的一篇mpvue开发音频类小程序踩坑和建议里面有讲如何在小程序中使用[代码]vuex[代码]。但遇到了个比较严重的性能问题。 1. 问题描述 我开发的是一个音频类的小程序，所以需要将播放列表[代码]playList[代码],当前索引[代码]currentIndex[代码]和当前时长[代码]currentTime[代码]放进[代码]state.js[代码]中： [代码]const state = { currentIndex: 0, // playList当前索引 currentTime: 0, // 当前播放的进度 playList: [], // {title: '', url: '', singer: ''} } [代码] 每次用户点击播放音频时，都会先加载音频的播放列表[代码]playList[代码],然后播放时更新当前时长[代码]currentTime[代码]，发现有时候播音频时整个小程序非常卡顿。 注意到，音频需每秒就得更新一次[代码]currentTime[代码],即每秒就做一次[代码]setData[代码]操作，稍微有些卡顿是可以理解的。但我发现是播放列表数据比较多时会特别卡，比如playList的长度是100条以上时。 2. 问题原因 我开启[代码]Vue.config._mpTrace = true[代码]后发现一个规律： 当[代码]palyList[代码]数据量小时，[代码]console[代码]显示造成的数据量更新数值比较小；当[代码]playList[代码]比较大时，[代码]console[代码]显示造成的数据量更新数值比较大。 PS： 我曾尝试将playList数据量增加到200条，每500ms的数据量更新达到800KB左右。 到这里基本可以确定一个事实就是：更新[代码]state[代码]中的任何一个字段，将导致整个[代码]state[代码]全量一起[代码]setData[代码]。在我这里的例子，虽然我每次只是更新[代码]currentTime[代码]这个字段的值，但依然导致将state中的其他字段如[代码]playList[代码],[代码]currentIndex[代码]都一起做了一次[代码]setData[代码]操作。 3. 解决问题 有两个思路： 精简state中保存的数据，即限制[代码]playList[代码]的数据不能太多，可将一些数据暂存在[代码]storage[代码]中 [代码]vuex[代码]采用[代码]Module[代码]的写法能改善这个问题，虽然使用时命名空间造成一定的麻烦。vuex传送门 一般情况下，推荐使用后者。我在项目中尝试使用了前者，同样能达到很好的效果，请继续看下面的分享。 五、善用storage 1.为什么说要善用storage 由于小程序的内存非常宝贵，占用内存过大会非常卡顿，因此最好尽可能少的将数据放到内存中，即[代码]vuex[代码]存的数据要尽可能少。而小程序的[代码]storage[代码]支持单个 key允许存储的最大数据长度为 [代码]1MB[代码]，所有数据存储上限为 [代码]10MB[代码]。 所以可以将一些相对取用不频繁的数据放进[代码]storage[代码]中，需要时再将这些数据放进内存，从而缓解内存的紧张，有点类似Windows中[代码]虚拟内存[代码]的概念。 2.storage换内存的实例 这个例子讲的会有点啰嗦，真正能用到的朋友可以详细看下。 上面讲到[代码]playList[代码]数据量太多，播放一条音频时其实只需要最多保证3条数据在内存中即可，即[代码]上一首[代码]，[代码]播放中的[代码]，[代码]下一首[代码],我们可以将多余的播放列表存放在[代码]storage[代码]中。 PS: 为了保证更平滑地连续切换下一首，我们可以稍微保存多几条，比如我这里选择保存5条数据在vuex中，播放时始终保证当前播放的音频前后都有两条数据。 [代码]// 首次播放背景音频的方法 async function playAudio (audioId) { // 拿到播放列表，此时的playList最多只有5条数据。getPlayList方法看下面 const playList = await getPlayList(audioId) // 当前音频在vuex中的currentIndex const currentIndex = playList.findIndex(item => item.audioId === audioId) // 播放背景音频 this.audio = wx.getBackgroundAudioManager() this.audio.title = playList[currentIndex].title this.audio.src = playList[currentIndex].url // 通过mapActions将播放列表和currentIndex更新到vuex中 this.updateCurrentIndex(index) this.updatePlayList(playList) // updateCurrentIndex和updatePlayList是vuex写好的方法 } // 播放音频时获取播放列表的方法，将所有数据存在storage，然后返回当前音频的前后2条数据，保证最多5条数据 import { loadPlayList } from '@/api/audio' async function getPlayList (courseId, currentAudioId) { // 从api中请求得到播放列表 // loadPlayList是api的方法, courseId是获取列表的参数,表示当前课程下的播放列表 let rawList = await loadPlayList(courseId) // simplifyPlayList过滤掉一些字段 const list = this.simplifyPlayList(rawList) // 将列表存到storage中 wx.setStorage({ key: 'playList', data: list }) return subPlayList(list, currentAudioId) } [代码] 重点是[代码]subPlayList[代码]方法，这个方法保证了拿到的播放列表是最多5条数据。 [代码]function subPlayList(playList, currentAudioId) { let tempArr = [...playList] const count = 5 // 保持vuex中最多5条数据 const middle = parseInt(count / 2) // 中点的索引 const len = tempArr.length // 如果整个原始的播放列表本来就少于5条数据，说明不需要裁剪，直接返回 if (len <= count) { return tempArr } // 找到当前要播放的音频的所在位置 const index = tempArr.findIndex(item => item.audioId === currentAudioId) // 截取当前音频的前后两条数据 tempArr = tempArr.splice(Math.max(0, Math.min(len - count, index - middle)), count) return tempArr } [代码] [代码]tempArr.splice(Math.max(0, index - middle), count)[代码]可能有些同学比较难理解，需要仔细琢磨一下。假设[代码]playList[代码]有10条数据： 当前音频是列表中的第1条（索引是0）,截取前5个：[代码]playList.splice(0, 5)[代码]，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]0[代码],没有[代码]上一首[代码]，有4个[代码]下一首[代码] 当前音频是列表中的第2条（索引是1）,截取前5个：[代码]playList.splice(0, 5)[代码]，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]1[代码]，有1个[代码]上一首[代码]，3个[代码]下一首[代码] 当前音频是列表中的第3条（索引是2）,截取前5个：[代码]playList.splice(0, 5)[代码]，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]2[代码]，有2个[代码]上一首[代码]，2个[代码]下一首[代码] 当前音频是列表中的第4条（索引是3）,截取第1到6个：[代码]playList.splice(1, 5)[代码] ，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]2[代码]，有2个[代码]上一首[代码]，2个[代码]下一首[代码] 当前音频是列表中的第5条（索引是4），截取第2到7个：[代码]playList.splice(2, 5)[代码]，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]2[代码]，有2个[代码]上一首[代码]，2个[代码]下一首[代码] … 当前音频是列表中的第9条（索引是[代码]8[代码]），截取后5个：[代码]playList.splice(4, 5)[代码]，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]3[代码]，有3个[代码]上一首[代码]，1个[代码]下一首[代码] 当前音频是列表中的最后1条（索引是[代码]9[代码]），截取后的5个：[代码]playList.splice(4, 5)[代码]，此时[代码]currentAudio[代码]在这5个数据的索引是[代码]4[代码]，有4个[代码]上一首[代码]，没有[代码]下一首[代码] 有点啰嗦，感兴趣的同学仔细琢磨下，无论当前音频在哪，都始终保证了拿到当前音频前后的最多5条数据。 接下来就是维护播放上一首或下一首时保证当前vuex中的[代码]playList[代码]始终是包含当前音频的前后2条。 播放下一首 [代码]function playNextAudio() { const nextIndex = this.currentIndex + 1 if (nextIndex < this.playList.length) { // 没有超出数组长度，说明在vuex的列表中，可以直接播放 this.audio = wx.getBackgroundAudioManager() this.audio.src = this.playList[nextIndex].url this.audio.title = this.playList[nextIndex].title this.updateCurrentIndex(nextIndex) // 当判断到已经到vuex的playList的边界了，重新从storage中拿数据补充到playList if (nextIndex === this.playList.length - 1 || nextIndex === 0) { // 拿到只有当前音频前后最多5条数据的列表 const newList = getPlayList(this.playList[nextIndex].courseId, this.playList[nextIndex].audioId) // 当前音频在这5条数据中的索引 const index = newList.findIndex(item => item.audioId === this.playList[nextIndex].audioId) // 更新到vuex this.updateCurrentIndex(index) this.updatePlayList(newList) } } } [代码] 这里的[代码]getPlayList[代码]方法是上面讲过的，本来是从api中直接获取的，为了避免每次都从api直接获取，所以需要改一下，先读storage，若无则从api获取： [代码]import { loadPlayList } from '@/api/audio' async function getPlayList (courseId, currentAudioId) { // 先从缓存列表中拿 const playList = wx.getStorageSync('playList') if (playList && playList.length > 0 && courseId === playList[0].courseId) { // 命中缓存，则从直接返回 return subPlayList(playList, currentAudioId) } else { // 没有命中缓存，则从api中获取 const list = await loadPlayList(courseId) wx.setStorage({ key: 'playList', data: list }) return subPlayList(list, currentAudioId) } } [代码] 播放上一首也是同理，就不赘述了。 PS: 将vuex中的数据精简后，我所做的小程序在播放音频时刷其他页面已经非常流畅啦，效果非常好。 六、动画优化 这个问题在mpvue开发音频类小程序踩坑和建议已经讲过了，感兴趣的可以移步看一眼，这里只写下概述: 如果要使用动画，尽量用css动画代替wx.createAnimation 使用css动画时建议开启硬件加速 最后 大致总结一下上面所讲的几个要点： 开发时打开[代码]Vue.config._mpTrace = true[代码]。 谨慎引入第三方库，权衡收益。 添加数据到data中时要克制，能精简尽量精简。 图片记得要压缩，图片在显示时才渲染。 vuex保持数据精简，必要时可先存storage。 性能优化是一个永不止步的话题，我也还在摸索，不足之处还请大家指点和分享。 欢迎关注，会持续分享前端实战中遇到的一些问题和解决办法。

前言   现在很多Web项目都是前后端分离的形式，现在浏览器的功能也是越来越强大，基本上大部分主流的浏览器都有调试模式，也有很多抓包工具，可以很轻松的看到前端请求的URL和发送的数据信息。如果不增加安全验证的话，这种形式的前后端交互时候是很不安全的。   相信很多开发小程序的开发者也不一定都是大神，能够精通前后端，作为小程序的初学者不少人也是根据官方的文档去学习开发的。我自己最开始接触小程序也是从wafer2开始的，那时候腾讯云提供的SDK包含PHP和Node.js，因为对于一直做前端的人来说，Node.js的学习成本比较低，只要会JS基本能看懂，也是从那时候才开始接触Node.js，所以本文主要是基于wafer2的服务端基于Koa2的后端来说（其实这个不重要，Node.js基本都差不多）。 什么是JWT？   根据维基百科的定义，JSON WEB Token，是一种基于JSON的、用于在网络上声明某种主张的令牌（token）。JWT通常由三部分组成: 头信息（header）, 消息体（payload）和签名（signature）。 为什么使用JWT？   首先，这不是一个必选方案。有时候我们的API是其它服务端和小程序公用的，那么就涉及到安全验证的问题了。   微信官方不鼓励小程序一打开就要求必须登陆的方式去获取用户信息，因此我们也不能去校验这个用户是否有权限访问这个接口，但是有的接口又不能让任何人随便去看或者被随意采集。 基于token（令牌）的用户认证 用户输入其登录信息 服务器验证信息是否正确，并返回已签名的token token储在客户端，例如存在local storage或cookie中 之后的HTTP请求都将token添加到请求头里 服务器解码JWT，并且如果令牌有效，则接受请求 一旦用户注销，令牌将在客户端被销毁，不需要与服务器进行交互一个关键是，令牌是无状态的。后端服务器不需要保存令牌或当前session的记录。   关于JWT的详细介绍网上有很多，这里也就不说了，下面介绍在Koa2框架里的添加方法。 安装依赖 [代码]npm install jsonwebtoken npm install koa-jwt [代码] app.js 引用 [代码]const jwtKoa = require('koa-jwt'); [代码] 设置不需要JWT验证的目录或者文件 [代码]const secret = '设置密钥'; app.use(jwtKoa({secret}).unless({ path: ['/','\/favicon.ico',/^\demo/] })) [代码] 数组中的路径不需要通过jwt验证。 授权   小程序 wx.request 发送网络请求的 referer header 不可设置。   其格式固定为 https://servicewechat.com/{appid}/{version}/page-frame.html，其中 {appid} 为小程序的 appid，{version} 为小程序的版本号，版本号为 0 表示为开发版、体验版以及审核版本，版本号为 devtools 表示为开发者工具，其余为正式版本。   那么我们就可以根据 ctx.header 里的 referer 进行初步的限制，比如指定的 appid 才能生成令牌。 我们在生成令牌的时候可以把简单的信息加入进去，如： [代码]const userToken = { referer: refererArray[2], appid: refererArray[3], version: refererArray[4], data: '此处可传入用户的信息' } [代码] 生成令牌： [代码]const jwt = require('jsonwebtoken'); const secret = '设置密钥'; jwt.sign(userToken, secret, {expiresIn: '2h'}); [代码] expiresIn：为令牌的有效期 这样简单的JWT令牌就生成好了，再通过接口返回给小程序端。 小程序前端如何使用JWT? 很简单，在header里加入下面属性即可。 [代码]authorization: 'Bearer 获取到的令牌' [代码] JWT优点 可扩展性好   应用程序分布式部署的情况下，session需要做多机数据共享，通常可以存在数据库或者redis里面。而JWT不需要。 无状态   JWT不在服务端存储任何状态。RESTful API的原则之一是无状态，发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。另外JWT的载荷中可以存储一些常用信息，用于交换信息，有效地使用JWT，可以降低服务器查询数据库的次数。 JWT缺点 安全性   由于jwt的payload是使用base64编码的，并没有加密，因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。 性能   JWT太长。由于是无状态使用JWT，所有的数据都被放到JWT里，如果还要进行一些数据交换，那载荷会更大，经过编码之后导致jwt非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。并且用户在系统中的每一次http请求都会把jwt携带在Header里面，http请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用JWT的http请求比使用session的开销大得多。 一次性   无状态是JWT的特点，但也导致了这个问题，JWT是一次性的。想修改里面的内容，就必须签发一个新的JWT。 （1）无法废弃   通过上面JWT的验证机制可以看出来，一旦签发一个 JWT，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个JWT，但是由于旧的JWT还没过期，拿着这个旧的JWT依旧可以登录，那登录后服务端从JWT中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的JWT，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。 （2）续签   如果你使用jwt做会话管理，传统的cookie续签方案一般都是框架自带的，session有效期30分钟，30分钟内如果有访问，有效期被刷新至30分钟。一样的道理，要改变JWT的有效时间，就要签发新的JWT。最简单的一种方式是每次请求刷新JWT，即每个http请求都返回一个新的JWT。这个方法不仅暴力不优雅，而且每次请求都要做JWT的加密解密，会带来性能问题。另一种方法是在redis中单独为每个JWT设置过期时间，每次访问时刷新JWT的过期时间。

大家好，上次给大家分享了swiper仿tab的小技巧： https://developers.weixin.qq.com/community/develop/article/doc/000040a5dc4518005d2842fdf51c13 [代码]今天给大家分享两个有用的函数，《函数防抖和函数节流》 函数防抖和函数节流是都优化高频率执行js代码的一种手段，因为是js实现的，所以在小程序里也是适用的。 [代码] 首先先来理解一下两者的概念和区别： [代码] 函数防抖（debounce）是指事件在一定时间内事件只执行一次，如果在这段时间又触发了事件，则重新开始计时，打个很简单的比喻，比如在打王者荣耀时，一定要连续干掉五个人才能触发hetai kill '五连绝世'效果，如果中途被打断就得重新开始连续干五个人了。 函数节流（throttle）是指限制某段时间内事件只能执行一次，比如说我要求自己一天只能打一局王者荣耀。 这里也有个可视化工具可以让大家看一下三者的区别，分别是正常情况下，用了函数防抖和函数节流的情况下：http://demo.nimius.net/debounce_throttle/ [代码] 适用场景 函数防抖 搜索框搜索联想。只需用户最后一次输入完，再发送请求 手机号、邮箱验证输入检测 窗口resize。只需窗口调整完成后，计算窗口大小。防止重复渲染 高频点击提交，表单重复提交 函数节流 滚动加载，加载更多或滚到底部监听 搜索联想功能 实现原理 [代码] 函数防抖 [代码] [代码]const _.debounce = (func, wait) => { let timer; return () => { clearTimeout(timer); timer = setTimeout(func, wait); }; }; [代码] [代码] 函数节流 [代码] [代码]const throttle = (func, wait) => { let last = 0; return () => { const current_time = +new Date(); if (current_time - last > wait) { func.apply(this, arguments); last = +new Date(); } }; }; [代码] [代码] 上面两个方法都是比较常见的，算是简化版的函数 [代码] lodash中的 Debounce 、Throttle [代码] lodash中已经帮我们封装好了这两个函数了，我们可以把它引入到小程序项目了，不用全部引入，只需要引入debounce.js和throttle.js就行了，链接：https://github.com/lodash/lodash 使用方法可以看这个代码片段，具体的用法可以看上面github的文档，有很详细的介绍：https://developers.weixin.qq.com/s/vjutZpmL7A51[代码]

前言 大家好，上次给大家讲了函数防抖和函数节流 https://developers.weixin.qq.com/community/develop/article/doc/000a645d8b8ba0d8722863ef45bc13 今天给大家分享一下利用canvas生成朋友圈分享海报 由于小程序的限制，我们不能很方便地在微信内直接分享小程序到朋友圈，所以普遍的做法是生成一张带有小程序分享码的分享海报，再将海报保存到手机相册，有两种方法可以生成分享海报，第一种是让后台生成然后返回图片链接，这一种方法比较简单，只需要传后台所需要的参数就行了，今天给大家介绍的是第二种方法，用canvas生成分享海报。 效果 [图片] 主要步骤 把海报样式用标签先写好，方便画图时可以比对 用canvas进行画图，canvas要注意定好宽高 canvas利用wx.canvasToTempFilePath这个api将canvas转化为图片 将转化好的图片链接放入image标签里 再利用wx.saveImageToPhotosAlbum保存图片 坑点 用canvas进行画图的时候要注意画出来的图的大小一定要是你用标签写好那个样式的两倍大小，比如你的海报大小是400600的大小，那你用canvas画的时候大小就要是8001200，宽高可以写在样式里，如果你画出来的图跟你海报图是一样的大小的话生成的图片是会很模糊的，所以才需要放大两倍。 画图的时候要注意尺寸的转化，如果你是用rpx做单位的话，就要对单位进行转化，因为canvas提供的方法都是经px为单位的，所以这一点要注意一下，px转rpx的公式是w/750z2，w是手机屏幕宽度screenWidth，可以通过wx.getSystemInfo获取，z是你需要画图的单位，2就是乘以两倍大小。 图片来源问题，因为canvas不支持网络图片画图，所以你的图片要么是固定的，如果不是固定的，那就要用wx.downloadFile下载后得到一个临时路径才行 小程序码问题，小程序需要后台请求接口后返回一个二进制的图片，因为二进制图片canvas也是不支持的，所以也是要用wx.downloadFile下载后得到一个临时路径，或者可以叫后台直接返回一个小程序码的路径给你 这里保存的时候是有个授权提醒的，如果拒绝的话再次点击就没有反应了，所以这里我做了一个判断是否有授权的，如果没有就弹窗提醒，确认的话会打开设置页面，确认授权后再次返回就行了，这里有个坑注意下，就是之前拒绝后再进入设置页面确认授权返回页面时保存图片会不成功，官方还没解决，我是加了个setTimeOut处理的，详情可以看这里 https://developers.weixin.qq.com/community/develop/doc/000c46600780f0fa68d7eac345a400 代码实现 [图片] 这里图片我先用的是网上的链接，实际项目中是后台返回的数据，这个可以自行处理，这里只是为了演示方便，生成临时路径的方法我这里是分别定义了一个方法，其实可以合成一个方法的，只是生成小程序码时如果要传入参数要注意一下。 绘图方法是drawImg，这里截一部分，详细的可以看代码片段 [图片] 不足 由于在实际项目中返回的图片宽高是不固定的，但是canvas画出来的又需要固定宽高，所以分享图会有图片变形的问题，使用drawImage里的参数也不能解决，如果各位有比较好的方案可以一起讨论一下。 代码片段 https://developers.weixin.qq.com/s/3pcsjDmS7M5Y

[图片] 非自定义导航栏高度怎么计算？ 自定义导航栏高度由谁决定？ 小程序自定义导航栏开发注意点与参考文档 一、默认导航栏高度怎么计算？（非custom情况下获取） wx.getSystemInfo 和 wx.getSystemInfoSync 获取机器信息 screenHeight - windowHeight   计算标题栏高度 [代码]{[代码][代码]       [代码][代码]'iPhone'[代码][代码]: 64,[代码][代码]       [代码][代码]'iPhone X'[代码][代码]: 88,[代码][代码]       [代码][代码]'android'[代码][代码]: 68[代码][代码] [代码][代码]}[代码]不完全统计（ip6 , ip5 , ip6p , ipx , 小米mix2  , 小米5等综合了开发工具提供的数据和真机数据）所得 二、自定义导航栏高度由谁决定？（自定义情况下，屏幕高度和窗口高度没有差别，所以要通过步骤1先获取数据，预定义到代码中） 开发时发现，自定义导航栏的实现需要 包含状态栏+胶囊 ：没有自定义导航栏的时候页面是全屏幕滚动会出现在状态栏的下一层 根据上一标题中步骤1的函数，可以获得状态栏高度 statusBarHeight demo，点击打开小程序开发工具 三、小程序自定义导航栏开发注意点与参考文档 微信官方设计指导中关于胶囊按钮的描述 由此得知胶囊宽度87pt=116px，设置之后，的确能产生较好的兼容性效果 社区Q&A：自定义标题栏高度计算、在 navigationStyle: 'custom',苹果X和8兼容问题 注意某些方法、参数的兼容性，时刻关注官方更新信息 开一个项目采集设备的screenHeight,windowHeight,pixelRatio等信息到一个数据库中，或者微信可以提供这样一个数据库便于计算，亦或者微信优化自定义标题栏（譬如通知栏可以改变颜色但不要算在自定义范围内，给出胶囊宽高到通知栏距离到右侧屏幕边框距离等相关参数）