页面时黑色背景，需要底部导航栏也是黑色，目前默认是白色，在Android全面屏的状态下显示突兀。[图片]

icebreaker手把手教你定制小程序码 前言 小程序菊花码，相比与普通的二维码，辨识度高，一看就知道拿微信扫。 默认情况下，我们可以自定义生成码的 [代码]参数[代码], [代码]路径[代码], [代码]大小[代码], [代码]自动或手动配置线条颜色[代码],[代码]底色是否为透明[代码] 这些配置项。 然而，这些配置项往往是无法满足我们的定制化需求的。 举个例子，我们需要在不破坏 [代码]小程序码[代码] 可识别性的情况下，把中间的 [代码]Logo[代码] 替换掉，怎么做呢？ 接下来就由笔者手把手来教你。 梳理思路 我们先要理清楚这个问题的本质。这个其实就是个 图像处理 问题, 而这个工作服务端和客户端都能做。 于是就有 [代码]2[代码] 个方案： 服务端生码并且缝合出结果的 服务端处理方案。具体怎么做，有兴趣的同学，可以查看笔者的这篇文章 Web 函数自定义镜像实战:构建图象处理函数 服务端生码，客户端缝合方案。这就是本篇文章具体提及的。 注：小程序码一般由服务端调用微信api接口生成 云调用——生码最简便方案 总所周知，微信小程序环境的 [代码]wxacode.getUnlimited[代码] 有 [代码]2[代码] 种生成模式，一种为 [代码]HTTPS 调用[代码] , 一种为 [代码]云调用[代码]。 其中 [代码]云调用[代码] 作为一种场景定制化的 [代码]serverless[代码]解决方案，往往能为我们的开发，带来效率上的提升。我们接下来快速部署一个[代码]getWxacodeUnlimit[代码]函数，来为我们提供测试素材。 [代码]getWxacodeUnlimit/index.js[代码]: [代码]import cloud from 'wx-server-sdk' cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }) export async function main (event, context) { const { scene = '', page, width = 430, autoColor, lineColor, isHyaline } = event const result = await cloud.openapi.wxacode.getUnlimited({ scene, page, width, autoColor, lineColor, isHyaline }) return result } // 笔者使用了打包工具, 大家想直接跑，把 esm 转化为 cjs 即可 [代码] [代码]getWxacodeUnlimit/config.json[代码]: [代码]{ "permissions": { "openapi": ["wxacode.getUnlimited"] } } [代码] 通过上述 [代码]2[代码] 段代码块，我们的测试函数就部署完成了。 把返回的 [代码]buffer[代码] 转成本地临时图片 [代码]const suffixMap = { 'image/jpeg': 'jpeg', ... } export function getPath(filename = 'tmp', contentType = 'image/jpeg') { return `${wx.env.USER_DATA_PATH}/${filename}.${suffixMap[contentType] || 'jpeg'}` } export function writeFile(buff, contentType = 'image/jpeg', filename = 'tmp') { return new Promise((resolve, reject) => { const fsm = wx.getFileSystemManager() const filePath = getPath(filename, contentType) fsm.writeFile({ filePath, data: buff, encoding: 'binary', success() { resolve(filePath) }, fail(error) { reject(error) } }) }) } .... // 在需要用到的地方直接 try { loading('生成中') const result = await getQrcode(scene, option) // 云调用封装function return await writeFile(result.buffer, result.contentType, scene) // : string } catch (e) { console.error(e) } finally { loaded() } [代码] 客户端的图像处理 提到客户端图像处理就不得不提到 [代码]canvas[代码] 这个原生组件了，所以我们只需要通过它，把小程序码中间的 [代码]Logo[代码] 部分，进行 测量和裁剪替换 为我们想自定义的图像就可以了。 测量 这里以默认小程序码大小 [代码]430px * 430px[代码] 为例。(本[代码]case[代码]为了简单易懂，都使用的此分辨率的小程序码，如需求分辨率不同，可按比例进行计算裁剪。) [图片] 从图上的标注可知，在 [代码]430px * 430px[代码] 分辨率下，上下左右的边距为 [代码]120px[代码] ,可以算出中间 [代码]Logo圆形[代码] 的直径为 [代码]190px[代码], 半径为 [代码]95px[代码]。 所以接下来就可以轻松愉快的写代码了。 利用canvas 2d实现 1代小程序 api 版本被淘汰了，现在直接使用 type=“2d” 版本，Api文档在 [代码]MDN[代码] 上 前置标签和样式 [代码]<!-- uni-app vue 格式，可自行转化为 wxml 简单的语法转化 `: => {{}}` --> <canvas :class="visible ? '': 'canvas offscreen'" type="2d" id="canvas" :style="{ width:width+'rpx', height:height+'rpx' }" ></canvas> [代码] [代码]// scss .canvas.offscreen{ // 2个 class 选择器，增加优先级 position: absolute; bottom: 0; left: -9999rpx; // 这叫物理离屏渲染，笑~ } [代码] 注: 不能在 [代码]canvas[代码]上 使用 [代码]hidden[代码] or [代码]display:none[代码]，它们会导致渲染空白。 核心 js 实现 初始化canvas实例和上下文 初始化 [代码]canvas[代码] 实例和 [代码]ctx[代码] 上下文: [代码]let canvas let ctx {...codes...} onReady(){ uni .createSelectorQuery() .in(this) // 如果canvas在组件中，则需要加这一行 .select('#canvas') .fields({ node: true, size: true }) .exec((res) => { if (res[0]) { this.canvas = canvas = res[0].node this.ctx = ctx = canvas.getContext('2d') // 下面可根据设备的 pixelRatio 自行按比例调整，此处为了演示方便，就直接赋值了。 canvas.width = 430 canvas.height = 430 } }) } [代码] 第一次渲染-画布背景 第一次渲染，把小程序码，作为图像传入画布。 [代码]drawBackgroud[代码]: [代码]async drawBackgroud (orginQrcodeUrl) { const [err, res] = await uni.getImageInfo({ // 这里可以是远程地址(需要配置downloadUrl) // 也可以是本地地址(直接返回参数自己) // 甚至 cloud:// 前缀的云存储url也可以哟 src: orginQrcodeUrl }) if (err) { throw err } const { path } = res const img = canvas.createImage() img.src = path await new Promise((resolve, reject) => { img.onload = () => { // 下面这一行，把小程序码，整个铺进画布中! ctx.drawImage(img, 0, 0, canvas.width, canvas.height) resolve() } img.onerror = (event) => { reject(event) } }) }, [代码] 第二次渲染-裁剪加填充 第二次渲染，把背景裁剪一个圆，并把图片填充进去。 [代码]drawAvatar[代码]: [代码]async drawAvatar (remoteAvatarUrl) { const [err, res] = await uni.getImageInfo({ // 比如这里我用了云储存里的图像地址 prefix: cloud:// src: remoteAvatarUrl }) if (err) { throw err } const { path } = res const img = canvas.createImage() img.src = path // 测量数据在这里用上了 const offsetX = 120 // x 轴偏移 120px const offsetY = 120 // y 轴偏移 120px const diam = 190 // 圆的直径 (430 - 120* 2) / 2 const radius = diam / 2 // 圆的半径 const borderWidth = 2 // 多加2px来把原先logo的纯色边抹除 const circle = { // 裁剪部分圆的大小属性 x: offsetX + radius, y: offsetY + radius, radius: radius + borderWidth } await new Promise((resolve, reject) => { img.onload = () => { ctx.save() // 开始! 把原先中间的Logo干掉! ctx.arc(circle.x, circle.y, circle.radius, 0, Math.PI 2, false) ctx.clip() // 结束 // 开始! 把我们需要的自定义图像，平铺的插入进去！ ctx.drawImage( img, offsetX - borderWidth, offsetY - borderWidth, circle.radius * 2, circle.radius * 2 ) // 结束 ctx.restore() resolve() } img.onerror = (event) => { reject(event) } }) }, [代码] 通过以上几步 ，我们就可以轻松的完成图像处理部分，把中间的默认[代码]Logo[代码]给替换成自定义的图像。 预览及下载到本地 [代码]// 获取 tempFilePath async getImage () { const [err, res] = await uni.canvasToTempFilePath({ canvas }) if (err) { throw err } return res.tempFilePath } // 预览 async preview (src) { if (src) { uni.previewImage({ urls: [src] }) } }, // 保存到相册里 async save (src) { try { // 先授权，后保存 await authorize('scope.writePhotosAlbum') const [err, res] = await uni.saveImageToPhotosAlbum({ filePath: src }) if (err) { throw err } this.$success('保存成功！') } catch (e) { console.error(e) } } [代码] 就这样，客户端生成自定义小程序码的整套解决方案就完成了 效果展示 [图片] 或者微信搜索 [代码]程序员名片[代码] 后，维护名片，上传头像，再点击下方 [代码]分享二维码[代码] 按钮，即可预览。 [图片] 自定义生成转发图片 这篇文章这个案例还算是非常简单的，笔者之前还写过一个 小程序Canvas 2D自定义生成转发图片, 还有自定义分享海报，这些原理上都是大同小异的，一通百通。 附录 wxacode.getUnlimited接口文档

[图片] 抛砖引玉(2): Cloudbase Framework 助力改善微信云开发的体验 本文基于 CloudBase CLI 1.7.0 & CloudBase Framework 1.8.1 如有建议和意见，欢迎提出 (2021.06.21) 前言 书接上回 抛砖引玉：一种改善微信云开发 , 开发者体验的思路 那篇文章，主要解决的是，公共逻辑代码的复用问题，和公共npm包的问题 而手段则是通过 [代码]rollup[代码] 这类的打包工具，去预先处理云函数的代码，语法，以及依赖包 用前端的说法，就是把 [代码]src[代码] 打包到 [代码]dist[代码] 里, 最后我们实际上部署的就是 [代码]dist[代码] 里面的函数目录文件 然而之前的思路, 在我们整个 改善微信小程序开发者体验 这个大方向上，也只是做了一小部分。 因为它并没有把云函数的一些的基础的管理功能，给去 [代码]UI[代码] 化 当我们编写了大量云函数时，还是要去 [代码]微信IDE[代码] 上，一个一个点击上传并部署，然后再去云开发控制台，一个一个切换流量灰度，显然重复性工作多且繁琐。 于是我们就需要另外一种利器，来帮助我们更好的管理部署我们的函数项目。 那就是 [代码]Cloudbase Framework[代码] 了 Cloudbase Framework 和 Serverless Framework 在说 [代码]Cloudbase Framework[代码] 前也顺便聊聊 [代码]Serverless Framework[代码] 本人恰好对两者都有一些浅薄的认识 从个人的观点来看: [代码]Serverless Framework[代码] 在腾讯云体系中，主要用来管理多个云产品的，比如 [代码]SCF云函数[代码], [代码]COS对象存储[代码],[代码]API网关[代码],[代码]CDN[代码],[代码]DB[代码] 等等，换句话说，只要是 腾讯云开放出来的 [代码]capi[代码] 能进行管理的， [代码]Serverless Framework[代码] 也都可以进行管理。 [代码]Cloudbase Framework[代码] 主要用来管理 [代码]Cloudbase[代码] 自身的功能，不过由于自己就是多个云服务的集合了 ([代码]auth[代码], [代码]db[代码] ,[代码]scf[代码],[代码]cos[代码],[代码]static host[代码],[代码]SAE[代码] 等等), 所以也能够做很多的事情了。 一句话总结，[代码]Serverless Framework[代码] 部署的应用，在腾讯云控制台中，往往要不停的在多个云产品中，切来切去来完成一些运维操作， 而 [代码]Cloudbase Framework[代码] 进它本身的云开发产品就可以了 (笑~) 配置 两个 [代码]Framework[代码] 的配置也是大同小异 一个是 [代码]cloudbaserc.json[代码] ， 一个是 [代码]serverless.yml[代码] ，不过都可以使用变量占位符 [代码]{{}}[代码] 来做动态配置, 不过 [代码]json[代码]格式本身不支持注释。 组件 另外 [代码]serverless components[代码] 就不多说了，之前也写了不少的文章了 [代码]cloudbase Framework[代码] 本身也有 [代码]plugin[代码] 的机制，可以用来部署很多现有的框架 笔者在这里，尝试部署了一个 [代码]koa[代码] 项目，发现里面 [代码]tcbindex.js[代码] 还是借用的 [代码]serverless-http[代码] 这个包，来完成 [代码]http请求[代码] 转化成 [代码]event[代码] 的操作的 [代码]// tcbindex.js module.exports.main = async (event, context) => { context.callbackWaitsForEmptyEventLoop = false; const entry = (() => { const result = require('./app.js'); return result; })(); const serverless = require('serverless-http'); let app = entry; // support for async load app if (entry && entry.tcbGetApp && typeof entry.tcbGetApp === 'function') { app = await entry.tcbGetApp(event, context); } return serverless(app, { binary: [ 'application/javascript', 'application/octet-stream', 'application/xml', 'font/eot', 'font/opentype', 'font/otf', 'image/*', 'video/*', 'audio/*', 'text/comma-separated-values', 'text/css', 'text/javascript', 'text/plain', 'text/text', 'text/xml', ], })(event, context); }; [代码] 更多细节这里就先简述了, 有兴趣的朋友，可以看一下我的另外一篇文章 初探 SCF 的 Web function 和 Custom image 基于Output 基于上篇文章的输出 , [代码]Cloudbase Framework[代码] 就可以帮助我们对打包出来的云函数进行管理运维操作了 笔者主要使用的是它的云函数插件 [代码]@cloudbase/framework-plugin-function[代码] 来帮助我方便的管理微信云函数 为什么不用其他的插件？ 因为在许多的场景上，是需要去获得微信的上下文的 而这个上下文机制，是通过 [代码]wx-server-sdk[代码] + [代码]wx.cloud.callFunction[代码] 来实现的 [代码]wx-server-sdk[代码] 本质也是 [代码]cloudbase[代码] 的封装 其中获取上下文的代码如下所示 [代码]// webpack + ts 打包后的 wx-server-sdk 部分代码 function getWXContext() { const apiName = 'getWXContext'; const wxContext = {}; if (!process.env.WX_CONTEXT_KEYS) return wxContext; try { const contextKeys = process.env.WX_CONTEXT_KEYS.split(','); for (const key of contextKeys) { if (!key) continue; if (isContextKeyInBlacklist(key)) continue; let val = process.env[key]; if (val === undefined) continue; if (isNumber(val)) { val = parseInt(val); } if (key.startsWith(WX_PREFIX) && key.length > 3) { wxContext[key.slice(3)] = val; } else { wxContext[key] = val; } } wxContext.ENV = process.env.TCB_ENV || process.env.SCF_NAMESPACE; if (process.env.TCB_SOURCE) { wxContext.SOURCE = process.env.TCB_SOURCE; } return wxContext; } catch (e) { const error = error_1.returnAsFinalCloudSDKError(e, apiName); throw error; } } exports.default = getWXContext; [代码] 可以看到，上下文是通过环境变量去注入的,我们本地也可以通过模拟 [代码]WX_[代码] 这些环境变量，来达到我们 [代码]mock[代码] 的目的。 另一个控制台 除了微信IDE里的那个控制台，腾讯云的Cloudbase云开发中也能对微信环境下的资源进行管理，而且功能上更加的强大。 首先我们使用小程序的账户去登陆腾讯云，（开通云开发的时候，会给你开一个腾讯云账号） 进入云产品 -> [代码]Cloudbase 云开发[代码]，可以看到我们在小程序中创建的环境，和web不同，小程序的环境，会被打上的特殊标记 [图片] 进入一个小程序环境，可以看到里面的用户管理功能在小程序环境无效， 数据库,云函数 和IDE云开发里的对应功能是一样的 在这里操作造成的效果，同样和微信IDE云开发控制台是一样的 而且在腾讯云的控制台还提供了更多的功能,比如 [代码]layer[代码] [代码]http访问服务[代码] 等等 现有项目里嵌入 Cloudbase Framework 这个很简单，我们只需要在里面加一个配置文件 [代码]cloudbaserc.json[代码] 就可以 接着把之前的函数给注册进配置文件中去 [代码]// 例如 { "version": "2.0", "envId": "{{env.ENV_ID}}", "framework": { "name": "business-card-miniprogram", "plugins": { "function": { "use": "@cloudbase/framework-plugin-function", "inputs": { "functionRootPath": "./dist", "functionDefaultConfig": { "timeout": 5, "envVariables": {}, "runtime": "Nodejs10.15", "memorySize": 128 }, "functions": [ { "name": "article-service" } ] } } } } } [代码] 详细的配置也都在 这里 如果想要更强的操作性，可以参考我的这篇文章动态生成这个 json 文件, 思路见serverless framework 模块化部署 配置的模板变量 & 模式切换 也很方便 [代码]# 切换变量 .env .env.dev .env.prod .env.[xxx] # 部署 tcb framework deploy --mode dev tcb framework deploy --mode prod tcb framework deploy --mode xxx [代码] [代码]serverless framework[代码] 则是 [代码]serverless deploy --target ./path/to/config.yml[代码] 部署完成之后，在我们的微信IDE下，右键对应环境的云函数目录，点击同步云函数，我们刚刚部署的函数就出现了。 这样就省去了一部分我们操作UI的时间，然而目前切换流量灰度，似乎无法通过这里的配置项进行切换，还是有些需要进行手动操作的部分的。 目前存在的不足 目前还是存在一些缺点的: 本地调试比较麻烦 过度依赖云端自动安装 [代码]node_modules[代码] 的能力,导致上传部署比较缓慢 缺点1: 的话，目前可以直接在微信IDE里，手动安装 [代码]npm[代码] 包来解决，就是麻烦点 缺点2: 名义上可以使用[代码]层layer[代码]解决，然而在一些情况下，使用 [代码]层layer[代码] 也可能存在一定的问题，原因主要在于开发平台。 像我这样的大部分微信小程序开发者，都是使用 [代码]windows[代码] 作为开发平台的， 这时候去 [代码]npm i/yarn[代码] 安装的包，抛开 [代码]js[代码] 本身，也有可能带有很多二进制文件，它们往往是和平台绑定的，比如 [代码]windows[代码] 就安装 [代码]windows[代码] 的版本，而云函数容器里面实际上都是 [代码]CentOS[代码] , 一个 [代码]win[代码] 下的二进制，怎么在 [代码]linux[代码] 下跑呢？ 这时候，使用 云端自动安装 [代码]node_modules[代码] 反而没问题，而 [代码]layer[代码] 就会遇到本地和云端 平台环境不一致,导致云上运行失败的 [代码]issue[代码] 了。

抛砖引玉：一种改善微信云开发 , 开发者体验的思路 本篇文章写于 2021-02-27 鄙人才疏学浅，如有谬误，欢迎指正 更多代码的细节在 Github源码链接 中 前言 小程序云开发，作为一种 [代码]BaaS[代码] 场景，在过去的一段时间内发展非常的迅猛。 其中里面最受瞩目的功能，自然是云函数了，它作为一种 [代码]Serverless[代码] 落地的场景，很好的开启了小程序开发者连接服务端编程的大门。 当然，作为一个未来具有很大发展前景的项目，对于目前的非 [代码]js[代码] 开发者, 显得不那么友好，虽然可以依托 [代码]云托管[代码] 功能，使用传统静态语言构建服务，但是毕竟开发小程序用的还是 [代码]js[代码] 嘛。 云托管作为一种多语言的解决方案，从文档上看，应该就是预置了并发实例的多线程 docker 容器吧 , 毕竟那些静态语言的启动时间可是远远超出 nodejs 的。 本篇文章主要面向 云开发 中的 Nodejs 云函数 功能 云函数原生开发体验的不足 开通云开发，设置个 [代码]cloudfunctionRoot[代码] , 微信开发者工具就自动识别文件夹和里面的目录了。 新建一个云函数可以看到，创建了一个文件夹, 里面有三个文件: config.json index.js package.json 显然这就是一个最小化的 nodejs 项目。 然而当我们上传并部署的时候，会显然发现几个问题： 上传并部署虽然可以云端安装 [代码]node_modules[代码] , 但是当我们要引用一个这个项目外部的公共文件时，那个文件在部署时并不会被上传上去。这就会直接导致报错。(上传并部署只上传文件夹里的东西) [代码]package.json[代码] 中的 [代码]dependencies[代码] , 由于每个云函数都是独立的 [代码]Serverless[代码] 容器 , 导致了一个 [代码]common[代码] 的包(比如 [代码]wx-server-sdk[代码], [代码]dayjs[代码],[代码]uuid[代码] 等等)，要在不同的函数里被安装多次。 不得不说，这2个问题，对于整个的开发体验来说，不是很好，不过我们可以自己构建一个 [代码]compile-time[代码] 来改善自己的开发体验。 从一个前端的角度出发 我们前端经常使用 [代码]webpack[代码] 和 [代码]rollup[代码] 这类的工具。 本文打包用的是 [代码]rollup[代码] , 之前使用它打包过很多的 node 项目 , 当然其它的工具都可以，[代码]Vanilla JS[代码] 当然也可以，见仁见智。 我们在 [代码]cloudfunctions[代码] 目录里 创建 [代码]src[代码] 作为源码目录, [代码]dist[代码] 作为打包后的目录。 [代码]// cd cloudfunctions/ npm init -y [代码] 然后在里面的 [代码]devDependencies[代码] 安装好 [代码]rollup[代码] 相关的工具链，预置好命令。 为了解决第一个不足点： 我把 [代码]src[代码] 下的目录，分为了 2 类， 一类是云函数目录 另外一类是公共代码目录 云函数类似原生的写法，而公共函数可以被云函数引用， 这里列举一个改造后的云函数示例： [代码]import cloud from '~/common/cloud' import { getNowFullDate } from '~/common/util/day.esm' import { getNanoid } from '~/common/util/nanoid' export async function main (event, context) { const wxContext = cloud.getWXContext() return { event, openid: wxContext.OPENID, appid: wxContext.APPID, unionid: wxContext.UNIONID, env: wxContext.ENV, fullDate: getNowFullDate(), nanoid: getNanoid() } } [代码] tip: 用 [代码]alias[代码] 后 , 加个 [代码]jsconfig.json[代码]，给 [代码]vscode[代码] 加智能提示。 这些云函数既可以使用 [代码]cjs[代码] , 也可以使用 [代码]esm[代码] , 并最终通过 [代码]babel[代码] 编译成 Nodejs 10.15 (当前云函数runtime) 可直接运行的代码。 打包后，可见 [代码]dist[代码] 对应云函数中，自动打入了依赖的公共代码。 为了解决第二个不足点： 我把 [代码]package.json[代码] 分为了 2 类: [代码]cloudfunctions[代码] 根目录下的 [代码]package.json[代码] [代码]src[代码] 对应函数目录下的 [代码]package.json[代码] 第一类作为所有云函数都依赖的 npm 包(比如 [代码]wx-server-sdk[代码],[代码]core-js[代码] 这种) 另外一类是那个云函数特定依赖的包。 而最终 [代码]dist[代码] 目录下打包好的所有函数里面都有一个 [代码]package.json[代码] 它的 [代码]dependencies[代码] 由 1. 和 2. merge 而成，即： [代码]Object.assign({},rootPkgJson.dependencies,targetPkgJson.dependencies) [代码] 这种写法同时保证了，内部依赖的优先级级别高于外部。 同时也有一个好处,不需要再在每个云函数里面都定义一个 [代码]package.json[代码] 如果够懒，甚至所有的运行时依赖，都可以放在外部。 另外一些细节 不要忘记 copy [代码]config.json[代码] 到对应 [代码]dist[代码] 对应函数中 同时这种方案由于最终生成的代码，和自个写的有些差距，本地调试啥的，是依赖[代码]source map[代码] 的 收尾: 接下来只要小程序编译时，通过 [代码]copy[代码] 的 方案，把它放入小程序的ide中，这样就可以便捷的，切换环境，部署,和调试了。 我也尝试了 [代码]symlink[代码] 的方案,把微信 ide 中的 [代码]cloudfunctions[代码] 指向 [代码]dist[代码],可是发现 ide 会自动做剪切处理。 附录： 方案源码 喜欢的话可以点个 [代码]star[代码] , 点个 [代码]follow[代码] 哟。