小根据官方规则，用户如果修改了头像，那么一段时间之后，用户原始的头像链接会失效。而因为我们一般用户资料储存的时候只储存了链接，就会造成失效，因此需要把用户头像转换成base64直接存数据库中，这样就不怕失效了。 云开发代码 /** * 插入用户数据 */ function addUserData(openid, userInfo) { if (!userInfo) { console.log('无用户信息，更新失败') } // 将头像图片转换为base64 http.get(userInfo.avatarUrl.replace("https", "http"), function (res) { let chunks = []; //用于保存不断加载的缓冲数据 let size = 0;　　 //保存缓冲数据的总长度 res.on('data', function (chunk) { chunks.push(chunk); //把接受到的数据逐段保存在缓冲区（Buffer size += chunk.length;//累加缓冲数据的长度 }); res.on('end', function () { var data = Buffer.concat(chunks, size);//Buffer.concat将chunks数组中的缓冲数据拼接起来 if (Buffer.isBuffer(data)) { //如果为Buffer转换为base64并赋值给avatarImg var base64Img = 'data:image/png;base64,' + data.toString('base64'); userInfo.avatarImg = base64Img } db.collection('user').doc(openid).set({ data: userInfo }).then(e => { console.log('用户数据更新成功', e) }) }); }); } 小程序端直接渲染 <!-- 直接渲染到页面 page.wxml --> <view style="background-image:url({{detail.avatarImg||detail.avatarUrl}});"></view> 小程序端将图片保存到本地 //如果需要将头像转成图片保存，如cavans绘图场景 page.js const [, format, bodyData] = /data:image\/(\w+);base64,(.*)/.exec(src) || []; if (format) { const filePath = `${wx.env.USER_DATA_PATH}/tmp_base64src.${format}`; // console.log(filePath) // const buffer = wx.base64ToArrayBuffer(bodyData); FileSystemManager.writeFile({ filePath, data: bodyData, encoding: 'base64', success() { console.log(filePath) }, fail() { console.log (new Error('ERROR_BASE64SRC_WRITE')); }, }); } 小程序端 已授权用户进入时自动更新 //进入小程序时，自动更新授权用户的信息到云端 app.js onLaunch: function () { this.getUserAuth(); } getUserAuth: function () { wx.getSetting({ success: res => { res.authSetting['scope.userInfo'] && wx.getUserInfo({ success: res => { wx.cloud.callFunction({ name: 'user', data: { userData: res.userInfo, } }) } }) } }) }, 

<view class='view1'>    <view class='fl'><view wx:for='{{10}}' class='view1_1'>{{index+1}}</view></view>    <view class='fr'>        <view class='view1_2'></view>    </view> </view> .view1{width: 100%;height: 1090rpx;background: #000;box-sizing: border-box;overflow: hidden} .fl{float: left} .fr{float: right} .view1_1{width: 500rpx;height: 100rpx;background: #fff;} .view1_2{width: 200rpx;height: 1000rpx;background: yellow} [图片] 左侧白色部分是一共10个view 每个高度为100rpx;右侧黄色部分一个view高度为1000rpx;但是在iphone5的视觉效果高度不一致；什么原因 如何解决？

前言 作为开发者，相信很多人都是个人开发小程序，想着等以后做大了或者有公司后再迁移。 迁移 小程序的迁移过程并不复杂，根据后台提示进行操作，提交相关资料就可以了。 迁移中的注意事项 如果迁移的企业和原主体是同一个管理员的话可以选择不变更小程序管理员，申请函中填同一个人的手机号或者只填一个就可以，但是小程序后台填资料的时候一番操作后会告诉你目标主体和原主体不能使用同一个手机号码，必须使用不同的号码（大部分人都有多个手机号，所以这个也不是什么大问题），迁移过程中审核人员会分别拨打2个号码进行确认，而且是上一个号码拨打完立马就拨打下一个，所以如果是同一个人的话最好手机都在身边。 迁移成功后 收到迁移成功后可能以为就万事大吉了，但是你登录后台的时候会发现小程序的主体信息变更了，但是微信认证状态是[代码]未认证[代码]，这时候我不知道其他人是什么想法，反正我看到第一时间可能是很多头羊驼在奔腾，如果需要认证的话还需要走一遍认证流程。 在迁移后未认证状态的小程序大部分功能使用，比如[代码]业务域名[代码]可以直接配置，目前不知道对实际审核会有什么影响。 迁移后可复用公众号资质认证 经过上面的误解，最后发现通过公众号后台的小程序管理里点开迁移过来的小程序详情可以[代码]复用公众号资质认证[代码]进行免费认证，切记不要在小程序后台里走认证流程，那个还是需要支付300。 [图片] 本文仅代表个人观点，希望大家不要花冤枉钱。

开发和测试完成之后，就需要将小程序发布给用户来使用了。 提交审核为了保证小程序的质量，以及符合相关的规范，小程序的发布是需要经过审核的 在开发者工具中上传了小程序代码之后，登录 小程序管理后台 - 开发管理 - 开发版本 找到提交上传的版本。 在开发版本的列表中，点击 提交审核 按照页面提示，填写相关的信息，即可以将小程序提交审核。 需要注意的是，请开发者严格测试了版本之后，再提交审核， 过多的审核不通过，可能会影响后续的时间。 发布审核通过之后，管理员的微信中会收到小程序通过审核的通知，此时登录 小程序管理后台 - 开发管理 - 审核版本。中可以看到通过审核的版本。 请点击发布，既可发布小程序。 运营数据有两种方式可以方便的看到小程序的 运营数据 方法一： 登录 小程序管理后台 - 数据分析 点击相应的 tab 可以看到相关的数据。 方法二： 使用小程序数据助手，在微信中方便的查看运营数据 [图片]

有时候我们使用一个小程序会遇到以下情形： 我们打开一个小程序，就看见提示“分享到5个群，可以获得一张20元的优惠券”，吸引我们去无脑分享到不同的群里； 打开某个小游戏，提示我“一定要分享到xx个群，才能继续玩游戏”； …… 而我们在群里打开这类小程序，仍然是提示我分享的信息，这类功能无疑打断了我们对小程序/小游戏正常的功能使用。 我们收到了很多用户对这类小程序/小游戏的抱怨。这类分享并非是用户主动自发的，而是受到了某类利益的诱惑，或是被迫分享。这样的内容充斥在群里、小程序里，对用户造成了骚扰，是对分享功能的滥用。 在原来的分享接口中，用户发起分享动作之后，可以通过 success 、fail、complete等回调来判断用户是否完成了最后的分享动作。通过这个能力，开发者是可以将产品交互在分享这个能力上做得比较自然和顺畅。但却被上述情形的小程序滥用。在我们权衡了分享功能带来的利弊后，我们打算回收这个能力。调整为：我们将不再支持分享回调参数 success 、fail 、complete 。即开发者无法判断用户最终是否完成了分享动作，也无法获取到分享成功后的回调参数shareTicket 。 接下来将与大家介绍此次分享功能调整后，小程序的调整建议。 对应小程序调整建议 此次调整可能影响到两种分享功能的用法。 第一种：通过判断用户最终是否有分享来做分支逻辑的小程序。 例如，通过判断 success 回调触发，来判断用户是否分享出去了，进而给奖励，如果用户没有分享出去则不给奖励。这类功能是我们平台不倡导的，后续将没有办法实现。 如果是需要在分享完成后变更当前页面的状态，可以适当调整交互方案。例如过去赠送代金券后显示“等待领取”等应用场景，可以改成在分享后继续保留“赠送”按钮，但提示用户一个代金券只能被一人领取，重复赠送无效。 第二种：获取用户分享之后的 shareTicket ，换取群唯一标识 openGId ，进而显示对应群的相关信息的小程序。 例如，部分小程序实现了群内的排行信息，通过分享小程序到某个群里，可以查看该群内成员的排行榜。 此次调整后，用户分享完成后无法立刻显示该群的排行榜信息，但仍可在用户从群消息点击进入小程序时显示该群的排行榜信息。 因此建议适当修改产品流程，在用户分享小程序之时，提示用户可进入群内查看群排行等信息。避免调整策略生效之后带来的交互不完整影响。 调整覆盖范围提示 近期新提交的版本中将会受到此策略的影响。 除此之外，调整策略在即将发布的基础库版本 2.3.0 生效，该基础库版本对应本月即将发布的微信客户端版本（暂定版本号 6.7.2）。即：近期提交审核的小程序版本，在基础库版本 2.3.0 以下的环境中仍不受此策略影响，仅在基础库版本 2.3.0 以上的环境受影响。 开发者需要注意，近期提交审核的版本都需要考虑兼容上述调整带来的影响，请各位开发者及时调整分享能力。

示例代码地址  https://github.com/s568774056/swipe.git 对于整页都是swiper的情况下。例如下面这张图： [图片] 则可以使用如下css [代码] [代码] [代码]swiper,swiper-item{[代码] [代码]   [代码][代码]height[代码][代码]: [代码][代码]100[代码][代码]vh [代码][代码]!important[代码][代码];[代码][代码]}[代码] [代码] [代码] [代码]或者 [代码] [代码] [代码] [代码][代码] [代码][代码] swiper,swiper-item{  height: calc(100vh - 75rpx) !important; } [代码][代码] [代码] [代码] 对于swiper占据部分高度的情况下。 [图片] 使用如下代码 原理为在[代码]swiper-item[代码][代码][代码]的最上面和最下面插入空view，并利用wx api获取两个之间的高度差，然后设置给[代码]swiper[代码]。   细节方面需要自己调整下。为什么小程序不把这个组件做好呢？还得自己计算- -！ <swiper class='hide' bindanimationfinish="swiperChange" style="height:{{swiper_height}};" current="{{isIndex}}">  <swiper-item wx:for="{{roomList}}" wx:for-item='room' wx:for-index="index">    <view id="start{{index}}" class='start-view'></view>    <block wx:for="{{imgUrls}}" wx:for-item='path' wx:for-index="img-index">      <image mode="aspectFill" src="{{path}}" />    </block>    <view id="end{{index}}" class='start-view'></view>  </swiper-item> </swiper> [代码][代码][代码][代码] swiper {  margin-top: 45rpx; } Page({  data: {    roomList: ['Room1', 'Room2', 'Room3'],    imgUrls: [      'https://images.unsplash.com/photo-1551334787-21e6bd3ab135?w=640',      'https://images.unsplash.com/photo-1551214012-84f95e060dee?w=640',      'https://images.unsplash.com/photo-1551446591-142875a901a1?w=640'    ],    swiper_height: 0,    isIndex:0  },  onLoad: function () {    this.autoHeight();  },  changeNavBar: function (e) {    this.setData({      isIndex: e.detail    });  },  swiperChange: function (e) {    this.setData({      isIndex: e.detail.current    });    this.autoHeight();  },  autoHeight() {    let {      isIndex    } = this.data;      wx.createSelectorQuery()        .select('#end' + isIndex).boundingClientRect()        .select('#start' + isIndex).boundingClientRect().exec(rect => {          let _space = rect[0].top - rect[1].top;          _space =  _space + 'px';          this.setData({            swiper_height: _space          });        })  } }) 参考文章https://developers.weixin.qq.com/community/develop/doc/00008aaf4a473056d1c69a8b253c04

一般情况下，一个云函数完成单一的逻辑功能，就是一个类的方法一样，如图: [图片] 但是受限免费用户最多只能使用20个云函数，想要在单一云函数中实现多个复杂的功能就需要通过参数来区别，可读性差，不利于管理。通过路由，尝试将请求归类，一个云函数处理某一类的请求，比如有专门负责处理用户的，或者专门处理支付的云函数。如图: [图片] 为了方便大家试用，腾讯云 Tencent Cloud Base 团队开发了 tcb-router，云函数路由管理库方便大家使用。 基于 koa 风格的小程序·云开发云函数轻量级类路由库，主要用于优化服务端函数处理逻辑 使用 npm install --save tcb-router 云函数端 // 云函数的 index.js const TcbRouter = require(’./router’); exports.main = (event, context) => { const app = new TcbRouter({ event }); [代码]// app.use 表示该中间件会适用于所有的路由 app.use(async (ctx, next) => { ctx.data = {}; await next(); // 执行下一中间件 }); // 路由为数组表示，该中间件适用于 user 和 timer 两个路由 app.router(['user', 'timer'], async (ctx, next) => { ctx.data.company = 'Tencent'; await next(); // 执行下一中间件 }); // 路由为字符串，该中间件只适用于 user 路由 app.router('user', async (ctx, next) => { ctx.data.name = 'heyli'; await next(); // 执行下一中间件 }, async (ctx, next) => { ctx.data.sex = 'male'; await next(); // 执行下一中间件 }, async (ctx) => { ctx.data.city = 'Foshan'; // ctx.body 返回数据到小程序端 ctx.body = { code: 0, data: ctx.data}; }); // 路由为字符串，该中间件只适用于 timer 路由 app.router('timer', async (ctx, next) => { ctx.data.name = 'flytam'; await next(); // 执行下一中间件 }, async (ctx, next) => { ctx.data.sex = await new Promise(resolve => { // 等待500ms，再执行下一中间件 setTimeout(() => { resolve('male'); }, 500); }); await next(); // 执行下一中间件 }, async (ctx)=> { ctx.data.city = 'Taishan'; // ctx.body 返回数据到小程序端 ctx.body = { code: 0, data: ctx.data }; }); return app.serve(); [代码] } tips: 小程序云函数的 node 环境默认支持 async/await 语法，推荐涉及到的异步操作时像 demo 中那样使用 小程序端 // 调用名为 router 的云函数，路由名为 user wx.cloud.callFunction({ // 要调用的云函数名称 name: “router”, // 传递给云函数的参数 data: { $url: “user”, // 要调用的路由的路径，传入准确路径或者通配符* other: “xxx” } }); 完整的实例，请参考我的另一篇博客: 分享使用tcb-router路由开发的云函数短信平台SDK

2018年12月，腾讯相册累计用户量突破[代码]1亿[代码]，月活1200万，阿拉丁指数排行 [代码]Top 30[代码]，已经成为小程序生态的重量级玩家。 三个多月来，腾讯相册围绕【在微信分享相册照片】这一核心场景，快速优化和新增一系列社交化功能，配合适当的运营，实现累计用户量突破[代码]1亿[代码]，大大超过预期。 [图片] (腾讯相册用户量破亿) 可是，谁曾想到，这样一个亿级体量的小程序，竟然是一个开发做出来的？他又是有哪般“绝技”，可以一个人撑起一个用户过亿的小程序？ 后台人力紧缺，怎么办？ 当我第一次见到腾讯相册小程序的开发David（化名）时，他显得忧心忡忡。 “年底的目标是要过千万的用户，但现在只有几位前端和后台开发。不仅如此，我们的后台开发还不是百分百能够投入到这个项目，大部分时间要抽身支援其它项目，人力非常紧缺。此外，原有后台系统有不少历史包袱，在原有架构上做新的社交化功能开发是不现实的。怎么办？ “要不试试’小程序·云开发’吧，只需要前端就可以把小程序搞起，正好解决我们缺后台的难题。” 于是，David作为腾讯相册前端开发团队的骨干，担当起用小程序·云开发实现腾讯相册小程序社交化功能的重任。 “第一次接触到’小程序·云开发‘时，觉得这个东西（小程序·云开发）理念挺新颖的———小程序无服务开发模式。在一般的小程序开发中，有三大功能小程序开无法绕开后台的帮助，它门分别是数据读取、文件管理以及敏感逻辑的处理（如权限）。因此，传统的开发模式，在小程序端都必须发送请求到后台进行鉴权，并且处理相关的文件或者数据。即使使用 Node 来搭建后端服务，也需要耗费不少的搭基础架构、后期运维的工作量。” [图片] “而小程序·云开发则释放了小程序开发者的手脚，赋予了开发者安全、稳定读取数据、上传文件和控制权限的能力，其它的负载、容灾、监控等，我们小程序开发者只需要关注业务逻辑，专注写好业务逻辑即可，其他的事情完全可以不用操心了！本来我还一筹莫展，了解完’小程序·云开发‘的产品原理以后，我瞬间心里有谱了。” 二维码扫不出来了 [图片] 道路总是不平坦的 ，在腾讯相册小程序通往用户破亿的道路上，困难重重。 由于腾讯相册的二维码需要带上的信息量过大，因此它的二维码显得密密麻麻。这种密集的二维码在某些Android机型下，容易出现无法识别小程序的问题。 这严重制约了腾讯相册小程序分享获客的能力。 [图片] (需要存储name, ownerid, page等大量信息) 这个事情的解决并不难，只需后台开发把数据先存储到数据库中，然后把数据id放到分享链接上，这样，链接便可以转化成32个字符的短链接，让二维码看起来没有那么密集了。 但由于后台人力不足，于是前端开发David利用小程序· 云开发的数据库存储能力，通过调用db.collection(‘qr’).add接口，快速实现数据在数据库中的存储。 [图片] (云开发数据库，格式类似MongoDB) [图片] (云开发数据库索引，可加快数据读取) [图片] 此外，腾讯相册还借住小程序·云开发的云函数能力，生成辨识度更高的小程序码（小程序码文档），用以在朋友圈里传播分享。 [图片] (生成小程序码的云函数逻辑) [图片] (优化后的分享图片和小程序码) 2天上线评论点赞功能 [图片] (评论与点赞功能) 腾讯相册在微信端的核心应用场景是“在微信做分享相册照片”，为了增强腾讯相册用户在微信里的互动，提升用户粘性和留存，腾讯相册决定新增评论与点赞功能，并且把聊天评论就直接在微信聊天窗口里面实现。 在这里，腾讯相册的David面临了两个选择，一是按原开发模式（前台开发-后台开发-前后台联调）做这个功能，面临的问题便是开发周期长、缺后台、迭代速度慢；另一个就是借助云开发的能力，亲自上阵。 为了加快产品迭代速度，David决定采取云开发的开发方式。评论、点赞通过云开发的数据库插入和查询接口，如db.collection(‘comment’).add，很快就实现了。 但遇到棘手的问题是，对于一些敏感的操作比如删除和编辑评论、点赞这些敏感操作，还需要到用户的鉴权操作，而这些鉴权信息，都在原有的后台。此时，云函数的路由功能便发挥出作用了。 [图片] (评论点赞逻辑) 用户进行评论点赞的时候，会在小程序端发起请求调用云函数并带上 [代码]openid[代码]，云函数用 [代码]openid[代码] 查询原有的后台服务看看该用户是否有权限进行操作，如果用户具有权限，则把评论和点赞的数据都写入云开发的数据库中。 就这样，借住小程序·云开发的能力，腾讯相册仅用2天时间，完成了在传统开发模式下需要1周多工作量的开发工作。 ​ 原有开发模式 云开发全栈开发 工作量 后台1周(微信登录态校验+业务逻辑server开发)+ 前后台联调1天 1 - 2天，无需联调 什么是小程序·云开发？ 小程序·云开发是基于腾讯云研发的全新 云开发 Tencent Cloud Base（简称 TCB） 服务，腾讯云与微信力推的这套云开发服务的诞生，恰逢其时地帮助腾讯相册走出开发效率的瓶颈。 [图片] (基于腾讯云的云开发) 小程序云目前提供三大基础能力支持： 云函数：充当了后台的角色，开发者可以在上面用 Node （后续还会支持 PHP, Python 等）写后台逻辑，跟微信私有协议天然鉴权，可以云函数里直接获取 [代码]appid[代码], [代码]openid[代码], [代码]unionid[代码] 等重要鉴权信息，大大简化了小程序后台的开发工作量。 数据库：一个既可在小程序前端操作，也能在云函数中读写的文档型数据库，提供控制台可视化管理 文件存储：在小程序前端和云函数里都可以直接上传/下载云端文件，提供控制台可视化管理 如果你是全新开发的小程序，架构非常轻量简单，如下图。 [图片] 如果你是已有的小程序，部份需要跟原有后台交互的功能，完全可把云函数作为路由，节省获取openid 等用户信息的逻辑，如下图： [图片] 相关资料 小程序·云开发解决方案 小程序·云开发文档

各位开发者：大家下午好。在一些小程序/小游戏的业务逻辑中，有时需要依赖用户所在的地理位置来提供服务，当前开发者可以通过调用 调用 wx.getLocation / wx.authorize 等接口获取用户的地理位置信息或授权。 根据 iOS 系统对用户隐私保护的要求，同时我们也为了让用户可以更好的判断是否要将地理位置信息提供给开发者，故调整为当小程序/小游戏获取用户地理位置信息时，开发者需要填写获取用户地理位置的用途说明。填写的说明将在地理位置授权弹窗中展示，如下图所示： [图片] 具体开发方法如下： 在 app.json 里面增加 permission 属性配置（小游戏需在game.json中配置）： [代码][代码]"permission": {      "scope.userLocation": {      "desc": "你的位置信息将用于小程序位置接口的效果展示"    }  } [代码][代码]详见 小程序开发文档/小游戏开发文档 可在开发者工具（1.02.1812260及以上版本）中进行调试。 2019年1月14日起新提交发布的版本将会受到此调整的影响。需要各位开发者注意，2019年1月14日起新提交发布的版本若未填写地理位置用途说明，则将无法正常调用地理位置相关接口，请及时填写地理位置用途说明。该调整策略在微信客户端 7.0.0 版本生效。另外，考虑到兼容性等问题，在微信客户端 7.0.0 版本以下的环境中不受此策略影响。 微信团队    2018.12.26

小程序开发另类小技巧 --用户授权篇 getUserInfo较为特殊，不包含在本文范围内，主要针对需要授权的功能性api，例如：wx.startRecord，wx.saveImageToPhotosAlbum， wx.getLocation 原文地址：https://www.yuque.com/jinxuanzheng/gvhmm5/arexcn 仓库地址：https://github.com/jinxuanzheng01/weapp-auth-demo 背景 小程序内如果要调用部分接口需要用户进行授权，例如获取地理位置信息，收获地址，录音等等，但是小程序对于这些需要授权的接口并不是特别友好，最明显的有两点： 如果用户已拒绝授权，则不会出现弹窗，而是直接进入接口 fail 回调， 没有统一的错误信息提示，例如错误码 一般情况而言，每次授权时都应该激活弹窗进行提示，是否进行授权，例如： [图片] 而小程序内只有第一次进行授权时才会主动激活弹窗（微信提供的），其他情况下都会直接走fail回调，微信文档也在句末添加了一句请开发者兼容用户拒绝授权的场景, 这种未做兼容的情况下如果用户想要使用录音功能，第一次点击拒绝授权，那么之后无论如何也无法再次开启录音权限**，很明显不符合我们的预期。 所以我们需要一个可以进行二次授权的解决方案 常见处理方法 官方demo 下面这段代码是微信官方提供的授权代码, 可以看到也并没有兼容拒绝过授权的场景查询是否授权（即无法再次调起授权） [代码]// 可以通过 wx.getSetting 先查询一下用户是否授权了 "scope.record" 这个 scope wx.getSetting({ success(res) { if (!res.authSetting['scope.record']) { wx.authorize({ scope: 'scope.record', success () { // 用户已经同意小程序使用录音功能，后续调用 wx.startRecord 接口不会弹窗询问 wx.startRecord() } }) } } }) [代码] 一般处理方式 那么正常情况下我们该怎么做呢？以地理位置信息授权为例： [代码]wx.getLocation({ success(res) { console.log('success', res); }, fail(err) { // 检查是否是因为未授权引起的错误 wx.getSetting({ success (res) { // 当未授权时直接调用modal窗进行提示 !res.authSetting['scope.userLocation'] && wx.showModal({ content: '您暂未开启权限，是否开启', confirmColor: '#72bd4a', success: res => { // 用户确认授权后，进入设置列表 if (res.confirm) { wx.openSetting({ success(res){ // 查看设置结果 console.log(!!res.authSetting['scope.userLocation'] ? '设置成功' : '设置失败'); }, }); } } }); } }); } }); [代码] 上面代码，有些同学可能会对在fail回调里直接使用wx.getSetting有些疑问，这里主要是因为 微信返回的错误信息没有一个统一code errMsg又在不同平台有不同的表现 从埋点数据得出结论，调用这些api接口出错率基本集中在未授权的状态下 这里为了方便就直接调用权限检查了 ，也可以稍微封装一下，方便扩展和复用，变成： [代码] bindGetLocation(e) { let that = this; wx.getLocation({ success(res) { console.log('success', res); }, fail(err) { that.__authorization('scope.userLocation'); } }); }, bindGetAddress(e) { let that = this; wx.chooseAddress({ success(res) { console.log('success', res); }, fail(err) { that.__authorization('scope.address'); } }); }, __authorization(scope) { /** 为了节省行数，不细写了，可以参考上面的fail回调，大致替换了下变量res.authSetting[scope] **/ } [代码] 看上去好像没有什么问题，fail里只引入了一行代码， 这里如果只针对较少页面的话我认为已经够用了，毕竟**‘如非必要，勿增实体’，但是对于小打卡这个小程序来说可能涉及到的页面，需要调用的场景偏多**，我并不希望每次都人工去调用这些方法，毕竟人总会犯错 梳理目标 上文已经提到了背景和常见的处理方法，那么梳理一下我们的目标，我们到底是为了解决什么问题？列了下大致为下面三点： 兼容用户拒绝授权的场景，即提供二次授权 解决多场景，多页面调用没有统一规范的问题 在底层解决，业务层不需要关心二次授权的问题 扩展wx[funcName]方法 为了节省认知成本和减少出错概率，我希望他是这个api默认携带的功能，也就是说因未授权出现错误时自动调起是否开启授权的弹窗 为了实现这个功能，我们可能需要对wx的原生api进行一层包装了（关于页面的包装可以看：如何基于微信原生构建应用级小程序底层架构） 为wx.getLocation添加自己的方法 这里需要注意的一点是直接使用常见的装饰模式是会出现报错，因为wx这个对象在设置属性时没有设置set方法，这里需要单独处理一下 [代码]// 直接装饰，会报错 Cannot set property getLocation of #<Object> which has only a getter let $getLocation = wx.getLocation; wx.getLocation = function (obj) { $getLocation(obj); }; // 需要做一些小处理 wx = {...wx}; // 对wx对象重新赋值 let $getLocation = wx.getLocation; wx.getLocation = function (obj) { console.log('调用了wx.getLocation'); $getLocation(obj); }; // 再次调用时会在控制台打印出 '调用了wx.getLocation' 字样 wx.getLocation() [代码] 劫持fail方法 第一步我们已经控制了wx.getLocation这个api，接下来就是对于fail方法的劫持，因为我们需要在fail里加入我们自己的授权逻辑 [代码]// 方法劫持 wx.getLocation = function (obj) { let originFail = obj.fail; obj.fail = async function (errMsg) { // 0 => 已授权 1 => 拒绝授权 2 => 授权成功 let authState = await authorization('scope.userLocation'); // 已授权报错说明并不是权限问题引起，所以继续抛出错误 // 拒绝授权，走已有逻辑，继续排除错误 authState !== 2 && originFail(errMsg); }; $getLocation(obj); }; // 定义检查授权方法 function authorization(scope) { return new Promise((resolve, reject) => { wx.getSetting({ success (res) { !res.authSetting[scope] ? wx.showModal({ content: '您暂未开启权限，是否开启', confirmColor: '#72bd4a', success: res => { if (res.confirm) { wx.openSetting({ success(res){ !!res.authSetting[scope] ? resolve(2) : resolve(1) }, }); }else { resolve(1); } } }) : resolve(0); } }) }); } // 业务代码中的调用 bindGetLocation(e) { let that = this; wx.getLocation({ type: 'wgs84', success(res) { console.log('success', res); }, fail(err) { console.warn('fail', err); } }); } [代码] 可以看到现在已实现的功能已经达到了我们最开始的预期，即因授权报错作为了wx.getLocation默认携带的功能，我们在业务代码里再也不需要处理任何再次授权的逻辑 也意味着wx.getLocation这个api不论在任何页面，组件，出现频次如何，**我们都不需要关心它的授权逻辑（**效果本来想贴gif图的，后面发现有图点大，具体效果去git仓库跑一下demo吧） 让我们再优化一波 上面所述大致是整个原理的一个思路，但是应用到实际项目中还需要考虑到整体的扩展性和维护成本，那么就让我们再来优化一波 代码包结构： 本质上只要在app.js这个启动文件内，引用./x-wxx/index文件对原有的wx对象进行覆盖即可 [图片] **简单的代码逻辑： ** [代码]// 大致流程： //app.js wx = require('./x-wxx/index'); // 入口处引入文件 // x-wxx/index const apiExtend = require('./lib/api-extend')； module.exports = (function (wxx) { // 对原有方法进行扩展 wxx = {...wxx}; for (let key in wxx) { !!apiExtend[key] && (()=> { // 缓存原有函数 let originFunc = wxx[key]; // 装饰扩展的函数 wxx[key] = (...args) => apiExtend[key](...args, originFunc); })(); } return wxx; })(wx); // lib/api-extend const Func = require('./Func'); (function (exports) { // 需要扩展的api（类似于config） // 获取权限 exports.authorize = function (opts, done) { // 当调用为"确认授权方法时"直接执行，避免死循环 if (opts.$callee === 'isCheckAuthApiSetting') { console.log('optsopts', opts); done(opts); return; } Func.isCheckAuthApiSetting(opts.scope, () => done(opts)); }; // 选择地址 exports.chooseAddress = function (opts, done) { Func.isCheckAuthApiSetting('scope.address', () => done(opts)); }; // 获取位置信息 exports.getLocation = function (opts, done) { Func.isCheckAuthApiSetting('scope.userLocation', () => done(opts)); }; // 保存到相册 exports.saveImageToPhotosAlbum = function (opts, done) { Func.isCheckAuthApiSetting('scope.writePhotosAlbum', () => done(opts)); } // ...more })(module.exports); [代码] 更多的玩法 可以看到我们无论后续扩展任何的微信api，都只需要在lib/api-extend.js 配置即可，这里不仅仅局限于授权，也可以做一些日志，传参的调整，例如： [代码] // 读取本地缓存(同步) exports.getStorageSync = (key, done) => { let storage = null; try { storage = done(key); } catch (e) { wx.$logger.error('getStorageSync', {msg: e.type}); } return storage; }; [代码] 这样是不是很方便呢，至于Func.isCheckAuthApiSetting这个方法具体实现，为了节省文章行数请自行去git仓库里查看吧 关于音频授权 录音授权略为特殊，以wx.getRecorderManager为例，它并不能直接调起录音授权，所以并不能直接用上述的这种方法，不过我们可以曲线救国，达到类似的效果，还记得我们对于wx.authorize的包装么，本质上我们是可以直接使用它来进行授权的，比如将它用在我们已经封装好的录音管理器的start方法进行校验 [代码]wx.authorize({ scope: 'scope.record' }); [代码] 实际上，为方便统一管理，Func.isCheckAuthApiSetting方法其实都是使用wx.authorize来实现授权的 [代码]exports.isCheckAuthApiSetting = async function(type, cb) { // 简单的类型校验 if(!type && typeof type !== 'string') return; // 声明 let err, result; // 获取本地配置项 [err, result] = await to(getSetting()); // 这里可以做一层缓存，检查缓存的状态，如果已授权可以不必再次走下面的流程，直接return出去即可 if (err) { return cb('fail'); } // 当授权成功时，直接执行 if (result.authSetting[type]) { return cb('success'); } // 调用获取权限 [err, result] = await to(authorize({scope: type, $callee: 'isCheckAuthApiSetting'})); if (!err) { return cb('success'); } } [代码] 关于用户授权 用户授权极为特殊，因为微信将wx.getUserInfo升级了一版，没有办法直接唤起了，详见《公告》，所以需要单独处理，关于这里会拆出单独的一篇文章来写一些有趣的玩法 总结 最后稍微总结下，通过上述的方案，我们解决了最开始目标的同时，也为wx这个对象上的方法提供了统一的装饰接口（lib/api-extend文件），便于后续其他行为的操作比如埋点，日志，参数校验 还是那么一句话吧，小程序不管和web开发有多少不同，本质上都是在js环境上进行开发的，希望小程序的社区环境更加活跃，带来更多有趣的东西