[图片] 上面的是效果图，弹框内的图片能够显示在弹框外 [图片] 然后如果图片一旦超出弹出框的话就会这样 [图片] 这是弹框代码 哪位大佬能给一个大概的方法或者思路，非常感谢

小程序开发另类小技巧 --用户授权篇 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环境上进行开发的，希望小程序的社区环境更加活跃，带来更多有趣的东西

拥有丰富的 Web 前端开发经验的工程师小赵今天刚刚来到新的部门，开始从事他之前没有接触过的微信小程序开发。在上手的第一天，他就向同办公室的小程序老手老李请教了自己的问题。 小赵：翻了一圈文档，小程序好像并不提供 DOM 接口？我还以为可以像之前一样用我喜欢的前端框架来做开发呢。老李，你说小程序为什么不给我们提供 DOM 接口呀。 老李：要提供 DOM 接口也没那么容易。你知道小程序的双线程模型吗？（小赵漏出了疑惑的表情）小程序是基于 Web 技术的，这你应该知道，但小程序和普通的移动端网页也不一样。你做了很多前端项目了，应该知道在浏览器里，UI 渲染和 JavaScript 逻辑都是在一个线程中执行的？ 小赵：这我知道，在同一个线程中，UI 渲染和 JavaScript 逻辑交替执行，JavaScript 也可以通过 DOM 接口来对渲染进行控制。 老李：小程序使用的是一种两个线程并行执行的模式，叫做双线程模型。像我画的这样，两个线程合力完成小程序的渲染：一个线程专门负责渲染工作，我们一般称之为渲染层；而另外有一个线程执行我们的逻辑代码，我们一般叫做逻辑层。这两个线程同时运行，并通过微信客户端来交换数据。在小程序运行的时候，逻辑层执行我们编写的逻辑，将数据通过 setData 发送到渲染层；而渲染层解析我们的 WXML 和 WXSS，并结合数据渲染出页面。一方面，每个页面对应一个 WebView 渲染层，对于用户来说更加有页面的感觉，体验更好，而且也可以避免单个 WebView 的负担太重；另一方面，将小程序代码运行在独立的线程中的模式有更好的安全表现，允许有像 open-data 这样的组件可以在确保用户隐私的前提下让我们展示用户数据。 [图片] 小赵：怪不得所有和页面有关的改动都只能通过 setData 来完成。但是用两个线程来渲染我们平时用单线程来渲染的 Web 页面，会不会有些「浪费」？而且每一个页面有一个对应的渲染层，那页面变多的时候，岂不是会有很大的开销？ 老李： 并不浪费，因为界面的渲染和后台的逻辑处理可以在同一时间运行了，这使得小程序整体的响应速度更快了。而在小程序的运行过程中，逻辑层需要常驻，但渲染层是可以回收的。实际上，当页面栈的层数比较高的时候，栈底页面的渲染层是会被慢慢回收的。 小赵： 原来如此。这么说的话，实际的 DOM 树是存在于渲染层的，逻辑层并不存在，所以逻辑层才没有任何的 DOM 接口，我明白了。但是……既然可以实现像 setData 这样的接口，为什么不能直接把 DOM 接口也代理到逻辑层呢？我觉得小程序可以做一个封装，让我们在逻辑层调用 DOM 接口，在渲染层调用接口后再把结果返回给我们呀。 老李：从理论上来说确实是可以的。但是线程之间的通信是需要时间的呀。将调用发送到渲染层，再将 DOM 调用结果发送回来，这中间由于线程通信发生的时间损耗可能会比这个接口本身需要的时间要多得多。如果以此为基础使用基于 DOM 接口的前端框架，大量的 DOM 调用可能会非常缓慢，让这个设计失去意义。 在实际测试中，如果每次 DOM 调用都进行一次线程通信，耗时大约是同等节点规模直接在渲染层调用的百倍以上；如果忽略通信需要的时间，一个实现良好的基于 DOM 代理的框架可以近似地看成一个动态模板的框架，而动态模板和静态模板相比要慢至少 50% 小赵：原来如此，线程通信的时间确实是我没有考虑到的问题。那现在的小程序框架中难道不存在这个问题吗？ 老李： 在现在的小程序框架中，这个问题也是存在的，这也是现在的框架基于静态模板渲染的原因。静态模板可以在运行前就做好打包，直接注入到渲染层，省去线程传输的时间。在运行时，逻辑层只和渲染层进行最少的、必要的数据交换：也就是渲染用的数据，或者说 data 。另一方面，静态模板让两个线程都在启动时就拥有模板相关的所有数据，所以框架也充分利用了这一点，进行了很多优化。 小赵： 怪不得我在文档里发现很多和 setData 有关的性能提示，都提醒尽量减少设置不必要的数据，现在总算是知道为什么了。但是具体到实际开发里的时候，还是总觉得很难每次只设置需要的数据啊，像对象里或者数组里的数据怎么办呢？ 老李： 如果只改变了对象里或者数组里的一部分数据，可以通过类似 array[2].message , a.b.c.d 这样的 数据路径 来进行「精准设置」。另外，现在自定义组件也支持 纯数据字段 了，只要在自定义组件的选项中设置好名为 pureDataPattern 的正则表达式， data 中匹配这个正则的字段将成为纯数据字段，例如，你可以用 /^_/ 来指定所有 开头的数据字段为纯数据字段。所有纯数据字段仅仅被记录在逻辑层的 this.data 中，而不会被发送到渲染层，也不参与任何界面渲染过程，节省了传输的时间，这样有助于提升页面更新性能。 小赵：小程序还有这样的功能，受教了。不过说来说去，我还是想在小程序里用我顺手的框架来开发，毕竟这样事半功倍嘛。我在网上搜索了一下，发现现在有很多支持用 Web 框架做小程序开发的框架，但好像都是将模板编译成 WXML，最终由小程序来做渲染，但这样的方法好像兼容性也不是很好。我在想，我们能不能在逻辑层仿造一套 DOM 接口，然后在运行时将 DOM 调用适配成小程序调用？ 老李： 你的这个脑洞有一些意思。在逻辑层仿造一套 DOM 接口，直接维护一棵 DOM 树，这当然没问题。但是没有代理 DOM 接口，逻辑层的 DOM 树没法反映到渲染层，因为渲染层具体会出现什么样的组件，是运行时才能知道的，这不就没法生成静态模板了？ 小赵：静态模板确实是没法生成了，但我看到小程序的框架支持自定义组件，我是不是可以做一个通用的自定义组件，让它根据传入的参数不同，变成不同的小程序内置组件。而且自定义组件还支持在自己的模板中引用自己，那么我只需要一个这个通用组件，然后从逻辑层用代码去控制当前组件应该渲染成什么内置组件，再根据它是否有子节点去递归引用自己进行渲染就可以了。你看这样可行吗？ [图片] 老李： 这样的做法确实可行，而且微信官方已经按照这个思路推出小程序和 Web 端同构的解决方案 Kbone 了。Kbone 的原理就像你刚才说的那样，它提供一个 Webpack 插件，将项目编译成小程序项目；同时提供两个 npm 包，分别提供 DOM 接口模拟和你说的那个通用的自定义组件作为运行时依赖。要不你赶紧试试？ 小赵：还有这么好的事，那我终于可以用我喜欢的框架开发小程序了！这么好的框架，为什么不直接内置到小程序的基础库里呀？ 老李： 因为这样的功能完全可以用现在已有的基础库功能实现出来呀。Kbone 现在是 npm 包的形式，使得它的功能、问题修复可以随着自己的版本来发布，不需要依赖于基础库的更新和覆盖率，不是挺好的吗？ 小赵： 好是好，但我担心的是代码包大小限制的问题。除了我们已经写好的业务逻辑之外，现在还得加上 Kbone，会不会装不下呀？ 老李： 原来你是担心这个呀，放心，Kbone 现在已经可以在 扩展库 里一键搞定啦。扩展库是帮我们解决依赖的全新功能，只要在配置项中指定 Kbone 扩展库，就相当于引入了 Kbone 相关的最新版本的 npm 包，这样就不占用小程序的代码包体积了，快试试吧！ 小赵：哇，那可太爽了，马上就搞起！ 最后 如果你对 Kbone 感兴趣或者有相关问题需要咨询， 欢迎加入 Kbone 技术交流 QQ 群：926335938