微信小程序瀑布流组件 实现效果图 [图片] 源代码链接：https://git.weixin.qq.com/xieyefeng888/waterfall 用法 下载组件源码到项目目录下 微信开发者工具导入项目即可查看效果 主要使用到的API有 this.getRelationNodes() ，案例结合文档更容易理解 [图片] [图片] [图片] [图片] 注意：必须在两个组件定义中都加入relations定义，否则不会生效。 知识扩展 this.selectComponent()可以获取到子组件的里面的数据和方法,还可以获取到properties里面的值 [图片] [图片] [图片] [图片] [图片] [图片]

今天的文章很有意思，讲一讲整块文本溢出省略打点的一些有意思的细节。 文本超长打点 我们都知道，到今天（2020/03/06），CSS 提供了两种方式便于我们进行文本超长的打点省略。 感兴趣的小伙伴点击链接，了解详情~ http://github.crmeb.net/u/yi 对于单行文本，使用单行省略： { width: 200px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } [图片] 而对于多行文本的超长省略，使用 [代码]-webkit-line-clamp[代码] 相关属性，兼容性也已经非常好了： { width: 200px; overflow : hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; } [图片] CodePen Demo -- inline-block 实现整块的溢出打点 问题一：超长文本整块省略 基于上述的超长打点省略方案之下，会有一些变化的需求。譬如，我们有如下结构： Sb Coco FEUIUX Designer前端工程师 [图片] 对于上述超出的情况，我们希望对于超出文本长度的整一块 -- 前端工程师，整体被省略。 如果我们直接使用上述的方案，使用如下的 CSS，结果会是这样，并非我们期待的整块省略： .person-card__desc { width: 200px; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; } [图片] 将 [代码]display: inline[代码] 改为 [代码]display: inline-block[代码] 实现整块省略 这里，如果我们需要实现一整块的省略，只需要将包裹整块标签元素的 [代码]span[代码] 的 [代码]display[代码] 由 [代码]inline[代码] 改为 [代码]inline-block[代码] 即可。 .person-card__desc span { display: inline-block; } [图片] 这样，就可以实现，基于整块的内容的溢出省略了。完整的 Demo，你可以戳这里： CodePen Demo - 整块超长溢出打点省略 问题二：iOS 不支持整块超长溢出打点省略 然而，上述方案并非完美的。经过实测，上述方案在 iOS 和 Safari 下，没能生效，表现为这样： [图片] 查看规范 - CSS Basic User Interface Module Level 3 - text-overflow，究其原因，在于 [代码]text-overflow[代码] 只能对内联元素进行打点省略。（Chrome 对此可能做了一些优化，所以上述非 iOS 和 Safari 的场景是正常的） 所以猜测是因为经过了 [代码]display: inline-block[代码] 的转化后，已经不再是严格意义上的内联元素了。 解决方案，使用多行省略替代单行省略 当然，这里经过试验后，发现还是有解的，我们在开头还提到了一种多行省略的方案，我们将多行省略的代码替换单行省略，只是行数 [代码]-webkit-line-clamp: 2[代码] 改成一行即可 [代码]-webkit-line-clamp: 1[代码]。 .person-card__desc { width: 200px; white-space: normal; overflow : hidden; text-overflow: ellipsis; display: -webkit-box; -webkit-line-clamp: 1; -webkit-box-orient: vertical; } .person-card__desc span { display: inline-block; } 这样，在 iOS/Safari 下也能完美实现整块的超长打点省略： [图片] CodePen Demo -- iOS 下的整块超长溢出打点省略方案 值得注意的是，在使用 [代码] -webkit-line-clamp[代码] 的方案的时候，一定要配合 [代码]white-space: normal[代码] 允许换行，而不是不换行。这一点，非常重要。 这样，我们就实现了全兼容的整块的超长打点省略了。 当然，[代码] -webkit-line-clamp[代码] 本身也是存在一定的兼容性问题的，实际使用的时候还需要具体去取舍。 最后 好了，本文到此结束，一个简单的 CSS 小技巧，希望对你有帮助 :) 感兴趣的小伙伴点击链接，了解详情~ http://github.crmeb.net/u/yi 作者：chokcoco

昨天分享了基于云开发实现 KV 缓存的方法，但在实际的开发过程中，这样的功能其实很难满足所有的需求。在这个时候，就需要对原有的方案进行优化，来解决一些其他的问题。 具体来说，之前的代码有以下几个问题: 没有进行错误处理 没有对数据进行过期时间的处理 如果没有数据的话，如何触发数据更新 这些都没有在昨天的文章中提及，今天就补全这些部分。 对数据进行错误处理 在使用云开发的时候，是有出错的可能的，因此，我们需要对可能出错的部分进行处理，以确保函数本身是可以正常返回的。 我们需要在原有的函数中进行修改，修改后的结果如下 设置缓存 [代码]async function setCache(key, value) { try { let result = await db.collection("cache").add({ data: { _id: key, value: value } }) return { code:0 } } catch (error) { return { code:1, msg: error } } } [代码] 读取缓存 [代码]async function getCache(key) { try { let { data } = await db.collection("cache").doc(key).get(); return { code: 0, value: data.value }; } catch (error) { return { code: 1, msg: error } } } [代码] 通过这一轮的修改，我们在原有的函数基础之上添加了错误处理，无论如何，缓存函数本身不会报错，不会阻塞外部逻辑的执行。在外部逻辑侧只需要根据返回的 code 来进行判断是获取缓存，还是直接进行逻辑计算，完成所有的工作。 对数据进行过期时间的处理 在前一个版本中，我们加入了错误处理，但还是没有解决一个问题，那就是数据的过期逻辑。但缓存在实际使用过程中，是存在过期的可能，既然存在过期，我们就需要在缓存中，实现相应的过期逻辑的处理。 想要实现，成本倒也不高，你只需要在数据中加一个过期时间字段[代码]expiredAt[代码]就可以完成相应的处理。 [图片] 设置缓存 对设定缓存的函数加入一个新的可选参数，来设定缓存过期时间。未设定缓存过期时间的情况下，你可以缓存 3600 秒(一小时)。 [代码]async function setCache(key, value,expire_time = 3600) { try { let expired_time = (new Date()) + expire_time * 1000 let result = await db.collection("cache").add({ data: { _id: key, value: value, expiredAt: expired_time } }) return { code:0 } } catch (error) { return { code:1, msg: error } } } [代码] 读取缓存 类似的，在缓存中加入相应的配置，可以完成缓存过期的处理 [代码]async function getCache(key) { try { let { data } = await db.collection("cache").doc(key).get(); let current = (new Date()).valueOf(); if (data.expiredAt < current) { return { code:1, msg: "Cache expired" } } return { code: 0, value: data.value }; } catch (error) { return { code: 1, msg: error } } } [代码] 如何触发数据的更新 在上一个版本中，我们完成了数据的过期，但目前数据的过期后处理是由业务逻辑来完成的，我们有没有办法在缓存过期的时候，进行相应的触发，从而主动更新缓存，这样可以确保缓存接口始终可以拿到数据? 也可以。我们可以再新增一个参数来完成。这一部分主要影响的是获取 Cache 的部分，所以，设置缓存和上一个版本相同。 设置缓存 [代码]async function setCache(key, value,expire_time = 3600) { try { let expired_time = (new Date()) + expire_time * 1000 let result = await db.collection("cache").add({ data: { _id: key, value: value, expiredAt: expired_time } }) return { code:0 } } catch (error) { return { code:1, msg: error } } } [代码] 获取缓存 获取缓存时，我们需要能够实现相应的数据更新的能力，因此，我们需要新增一个参数，来完成数据更新的部分。新的参数中我们需要传入一个函数，这个函数将会执行数据更新逻辑，将数据 [代码]async function getCache(key,uploadFunction) { try { let { data } = await db.collection("cache").doc(key).get(); let current = (new Date()).valueOf(); if (data.expiredAt < current) { if(uploadFunction){ const data = uploadFunction(); setCache(key,data) return { code:0, value: data } } return { code:1, msg: "Cache expired" } } return { code: 0, value: data.value }; } catch (error) { return { code: 1, msg: error } } } [代码] 总结 在今天的文章中，我们通过一些简单的处理，完成了缓存函数的三步优化，分别加入了缓存处理、过期时间和自动更新，让缓存可以变得更好用。 那么问题来了，你觉得这个缓存系统还有什么可以优化的点么?

代码已优化请查看另外一篇文章 https://developers.weixin.qq.com/community/develop/article/doc/00026c521ece40c2d2db97f7156013 小程序瀑布流组件 前言：为了实现这个组件也花费了些时间，以前也做过瀑布流的功能，不过是利用 js 去 计算图片的高度，然后通过 css 的绝对定位去改变位置。不过这种要提前加载完一个列 表的图片，然后通过排列的算法生成排序的数组。总之就是太复杂了，后来在网上也看到 纯 css 实现，比如 flex 两列布局，columns 等，不做过多的阐述，下面分享下自己项 目中实现的瀑布流过程。 Css Grid 布局 Css3 变量属性 Js 动态修改 css 变量属性 Wxs 小程序脚本语言 Wxml 节点 Api Component 自定义组件 效果图 代码片段 [图片] Css Grid 网格布局实现多列多行布局 [代码]<view class="c-waterfall"> <view wx:for="{{ 10 }}" wx:key="item" class="view-container" > {{ item }} </view> </view> [代码] [代码].c-waterfall { display: grid; grid-template-columns: repeat(2, 1fr); grid-auto-flow: row dense; grid-auto-rows: 10px; grid-gap: 10px; } .view-container { width: 100%; grid-row: auto / span 20; } [代码] Css3 变量，可以通过[代码]js动态[代码]改变 [代码].c-waterfall { --grid-span: 10; --grid-column: 2; --grid-gap: 10px; --grid-rows: 10px; width: 100%; display: grid; grid-template-columns: repeat(var(--grid-column), 1fr); grid-auto-flow: row dense; grid-auto-rows: var(--grid-rows); grid-gap: var(--grid-gap); } .view-container { width: 100%; grid-row: auto / span var(--grid-span); } [代码] 动态修改 css 变量，实现遍历的节点都有独立的样式 [代码]<view class="c-waterfall" style="{{ style }}"> <view wx:for="{{ 10 }}" wx:key="item" class="view-container style="grid-row: auto / span var(--grid-row-{{ index }})" > {{ item }} </view> </view> [代码] [代码]Page({ data: { span: 20, style: '' }, onReady() { this.setData({ style: '--grid-row-0: 10;--grid-row-1: 10;' // 0-9... }) } }) [代码] 显然通过这种方式去修改emmm，有点不尽人意，当view渲染的时候，通过[代码]index[代码]下标给每个view都设置独立的[代码]grid-row[代码]样式，然后在修改view父级的style，将[代码]--grid-row-xxx[代码]变量写进去实现子类继承，虽然比直接去修改每个view的样式要优雅些，但是一旦views的节点多了，100个、1000个、没上限呢，那这个父级的style真的惨不忍睹。。比如100个view，那么style将会是下面这样，所以需要换个思路还是得单独去设置view的样式。 [代码]const views = [...99].map((v, k) => `--grid-row-${k}: 10;`) console.log(views) // ["--grid-row-0: 10;", "--grid-row-1: 10;", ... "--grid-row-2: 10;", "--grid-row-3: 10;", "--grid-row-98: 10;", "--grid-row-99: 10;"] [代码] 通过Wxs脚本语言来修改view的样式，相比较通过[代码]setData[代码]去修改view的样式，wxs的性能绝对比js强。 WXS 不依赖于运行时的基础库版本，可以在所有版本的小程序中运行。 WXS 与 JavaScript 是不同的语言，有自己的语法，并不和 JavaScript 一致。 WXS 的运行环境和其他 JavaScript 代码是隔离的，WXS 中不能调用其他 JavaScript 文件中定义的函数，也不能调用小程序提供的API。 WXS 函数不能作为组件的事件回调。 由于运行环境的差异，在 iOS 设备上小程序内的 WXS 会比 JavaScript 代码快 2 ~ 20 倍。在 android 设备上二者运行效率无差异。 一般在对wxs的使用场景上大多数用来做[代码]computed[代码]计算，因为在[代码]wxml[代码]模板语法里只能进行简单的三元运算，所以一些复杂的运算、逻辑判断等都会放到wxs里面去处理，然后返回给wxml。 [代码]// index.wxs var format = function(string) { return string + 'px' } module.exports = { format: format } [代码] [代码]<!-- index.wxml --> <wxs src="./index.wxs" module="wxs"></wxs> <view>{{ wxs.format('100') }}</view> <view>{{ wxs.format(span) }}</view> <button bind:tap="modifySpan">修改span的值</button> [代码] [代码]// index.js page({ data: { span }, modifySpan() { this.setData({ span: '200' }) } }) [代码] 通过WXS响应事件来修改视图层[代码]Webview[代码]，跳过逻辑层[代码]App Service[代码]，减少性能开销，比如一些频繁响应的事件监听，滚动条位置，手指滑动位置等，通过wxs来做视图层的修改，大大提升了流畅度。 通过wxs响应原生组件的事件，[代码]image[代码]组件的[代码]bind:load[代码]事件 [代码]<!-- index.html --> <wxs src="./index.wxs" module="wxs"></wxs> <image class="image" src="https://hbimg.huabanimg.com/ccf4a904deaebc25990a47471c61ea1c765694f82633b-71iPZs_/fw/480/format/webp" bind:load="{{ wxs.loadImg }}" /> [代码] [代码]// index.wxs var loadImg = function(event, ownerInstance) { // image组件load加载完返回图片的信息 var image = event.detail // 获取image的实例 var imageDom = ownerInstance.selectComponent('.image') // 设置image的样式 imageDom.setStyle({ height: image.height + 'px', background: 'red' // ... }) // 给image添加class imageDom.addClass('.loaded') // 更多的功能请参考文档 // https://developers.weixin.qq.com/miniprogram/dev/framework/view/interactive-animation.html } module.exports = { loadImg: loadImg } [代码] wxs监听data的值 [代码]<!-- index.html --> <wxs src="./index.wxs" module="wxs"></wxs> <view class="container"> <view change:text="{{ wxs.changeText }}" text="{{ text }}" class="text" data-options="{{ options }}" > {{ text }} </view> <view class="child-node"> this is childNode </view> <!-- 某个自定义组件 --> <test-component class="other-node" /> </view> [代码] [代码]// index.wxs var changeText = function(newValue, oldValue, ownerInstance, instance) { // 获取修改后的text var text = newValue // 获取data-options var options = instance.getDataset() // 获取当前页面的任意节点实例 var childNode = instance.selectComponent('.container .child-node') // 修改childNode样式 childNode.setStyle({ color: 'gree' }) // 获取页面的自定义组件 var otherNode = instance.selectComponent('.container .other-node') // 获取自定义组件内的节点实例 // 通过css选择器 > var otherChildNode = instance.selectComponent('.container .other-node >>> .other-child-node') // 获取自定义组件内部节点的样式 var style = otherChildNode.getComputedStyle(['width', 'height']) // 更多功能看文档 } module.exports = { changeText: changeText } [代码] 通过[代码]createSelectorQuery[代码]获取节点的信息，用来后续计算[代码]grid-row[代码]的参数 [代码]Page({ onReady() { wx.createSelectorQuery(this) .select('.view-container') .fields({size: true}) .exec((res) => { console.log(res) // [{width: 375, height: 390}] }) } }) [代码] 创建waterfall自定义组件 waterfall组件的职责，做成组件有什么好处，不做成组件又有什么好处，以及通过抽象节点来实现多组件复用。 prop的基本设置参数 [代码]Component({ properties: { views: Array, // 需要渲染的瀑布流视图列表 options: { // 瀑布流的参数定义 type: Object, default: { span: 20, // 节点高度比 column: 2, // 显示几列 gap: [10, 10], // xy轴边距，单位px rows: 2, // 网格的高度，单位px }, } } }) [代码] 组件内部默认的样式 [代码].c-waterfall { --grid-span: 10; --grid-column: 2; --grid-gap: 10px; --grid-rows: 10px; width: 100%; display: grid; grid-template-columns: repeat(var(--grid-column), 1fr); grid-auto-flow: row dense; grid-auto-rows: var(--grid-rows); grid-gap: var(--grid-gap); } .view-container { width: 100%; grid-row: auto / span var(--grid-span); } [代码] 组件的骨架 [代码]<wxs src="./index.wxs" module="wx" ></wxs> <!-- 样式承载节点 --> <view class="c-waterfall" change:loadStatus="{{ wx.load }}" loadStatus="{{ childNode }}" data-options="{{ options }}" style="{{ wx.setStyle(options) }}" > <!-- 抽象节点 --> <selectable class="view-container" id="view-{{ index }}" wx:for="{{ views }}" wx:key="item" value="{{ item }}" index="{{ index }}" bind:load="load" > </selectable> </view> [代码] 抽象节点 [代码]{ "component": true, "usingComponents": {}, "componentGenerics": { "selectable": true } } [代码] 抽象节点应该遵循什么 [代码]Component({ properties: { value: Object, // 组件自身需要的数据 index: Number, // 下标值 }, methods: { load(event) { // load节点响应事件 this.triggerEvent('load', { ...this.data, // value必填参数 {width,height} value: { ...event.detail }, }) }, }, }) [代码] 组件wxs响应事件 [代码].c-waterfall[代码]样式承载节点，主要是设置options传入的参数 [代码] var _getGap = function (gaps) { return gaps .map(function (v) { return v + 'px' }) .join(' ') } var setStyle = function (options) { if (!options) return var style = [ '--grid-span: ' + options.span || 10, '--grid-column: ' + options.column || 2, '--grid-gap: ' + _getGap(options.gap || [10, 10]), '--grid-rows: ' + (options.rows || 10) + 'px', ] return style.join(';') } [代码] 获取瀑布流样式承载节点实例 [代码] var _getWaterfall = function (dom) { var waterfallDom = dom.selectComponent('.c-waterfall') return { dom: waterfallDom, options: waterfallDom.getDataset().options, } } [代码] 获取事件触发的节点实例 [代码] var _getView = function (index, dom) { var viewDom = dom.selectComponent('.c-waterfall >>> #view-' + index) return { dom: viewDom, style: viewDom.getComputedStyle(['width', 'height']), } } [代码] 获取虚拟节点自定义组件load节点实例，初始化渲染时，节点是未知的，比如image组件，图片的宽高是未知的，需要等到image加载完成才会知道宽高，该节点用于存放异步视图展示，然后通过事件回调计算出节点高度。 [代码] var _getLoadView = function (index, dom) { return { dom: dom.selectComponent( '.c-waterfall >>> #view-' + index + '>>>.waterfall-load-node' ), } } [代码] 获取虚拟节点自定义组件other节点实例，初始化渲染就存在节点，比如一些文字就放在该节点，具体由组件的创造者去自定义。 [代码] var _getOtherView = function (index, dom) { var other = dom.selectComponent( '.c-waterfall >>> #view-' + index + '>>> .waterfall-load-other' ) return { dom: other, style: other.getComputedStyle(['height', 'width']), } } [代码] 已知瀑布流样式承载节点的宽度，等load节点异步视图回调时，获取到load节点的实际高度，比如一张400*800的图片，如果要显示在一个宽度180px的视图里，注意：[代码]image[代码]组件会有默认高度240px，或者用户自己设置了高度。如果要实现瀑布流，还是需要通过计算图片的宽高比例得到图片在视图中宽高，然后再通过计算grid布局的span值实现填充。 [代码] var fix = function (string) { if (typeof string === 'number') return string return Number(string.replace('px', '')) } var computedContainerHeight = function (node, view) { var vW = fix(view.width) var nW = fix(node.width) var nH = fix(node.height) var scale = nW / vW return { width: vW, height: nH / scale, } } [代码] 通过公式计算span的值，这个公式也是花了我不少时间去研究的，对grid布局使用也不多，很多潜在用法并不知道，所以通过大量的随机数据对比查找规律所在。[代码]gap为数组[x, y][代码]，我们要取y计算，已知gap、rows求视图中节点高度[代码](gap[y] + rows) * span - gap[y] = height[代码]，有了求height的公式，那么求span就简单了，[代码](height + gap[y]) / (gap[y] + rows) = span[代码]，最终视图里的高度会跟计算出来的结果几个像素的误差，因为[代码]grid-row[代码]设置span不能为小数，只能为整数，而我们瀑布流的高度是未知的，通过计算有多位浮点数，所以只能向上取整了导致有几个像素的误差。 [代码] var computedSpan = function (height, options) { var rows = options.rows var gap = options.gap[1] var span = Math.ceil((height + gap) / (gap + rows)) return span } [代码] 最后我们能得到[代码]span[代码]的值了，只需要将[代码]load完成的视图修改样式即可[代码] [代码] var load = function (node, oldNode, dom) { if (!node.value) return false var index = node.index var waterfall = _getWaterfall(dom) // 获取虚拟组件，通过index下标确认是哪个，获取宽度高度 var view = _getView(index, dom) var otherView = _getOtherView(index, dom) var otherViewHeight = fix(otherView.style.height) // 计算虚拟组件的高度，其实就是计算图片在当前视图节点里的宽高比例 // image组件的mode="widthFix"也是这样计算的额 var virtualStyle = computedContainerHeight(node.value, view.style) // span取值，此处计算的高度应该是整个虚拟节点视图的高度 // load事件回调里，我们只传了load视图节点的宽高 // 后续通过selectComponent获取到了other视图节点的高度 var span = computedSpan( otherViewHeight + virtualStyle.height, waterfall.options ) // 设置虚拟组件的样式 view.dom.setStyle({ 'grid-row': 'auto / span ' + span, }) // 获取重新渲染后的虚拟组件高度 var viewHeight = view.dom.getComputedStyle(['width', 'height']) viewHeight = fix(viewHeight.height) // 上面说了因为浮点数的计算会导致有几个像素的误差 // 为了视图美观，我们将load视图节点的高度设置成虚拟视图节点的总高度减去静态节点的高度 var loadView = _getLoadView(index, dom) loadView.dom.setStyle({ width: virtualStyle.width + 'px', height: parseInt(viewHeight - otherViewHeight) + 'px', opacity: 1, visibility: 'visible', }) return false } module.exports = { load: load, setStyle: setStyle, } [代码] 抽离成虚拟节点自定义组件的利弊 利： 符合观察者模式的设计模式 降低代码耦合度 扩展性强 代码清晰 弊： 节点增加，如果视图节点过多会造成小程序性能警告 样式编写不便捷，需要写过多的判断代码去实现外部样式覆盖 wxs只能监听原生组件的事件，所以image的load事件触发时本可以直接去修改页面视图节点样式，不需要传回给父组件，然后父组件setData下标，wxs监听事件触发在去修改视图样式，多了一次setData的开销。 合： 时间有限没有扩展样式覆盖了，可以开启自定义组件的外部样式引入 节点过多的问题，在我自己电脑上，开发工具插入100个组件时，出现了卡顿，样式错乱，真机上目前还没发现上限。 后续想实现长列表功能，有回收机制，这样视图内的节点有限了，降低了性能开销，因为之前版本的长列表组件是通过[代码]createSelectorQuery[代码]获取节点信息，然后记录高度，通过创建[代码]createIntersectionObserver[代码]监听视图节点是否在视图来判断是否渲染。但是瀑布流有异步视图，初次渲染的高度跟异步加载完的高度是不一样，所以创建监听事件高度会不准确，若等到load完再创建监听事件，父级容器的高度又要经过计算，因为子节点会去填充空白区域实现瀑布流，目前项目中为了避免节点过大造成性能警告，加了item的个数限制，如果超过100或者1000个就清空数组，类似分页的功能。不过上面总结的思路可以去试试。 等把功能完善了，发布npm依赖包安装。 后续有时间会将项目里比较实用的组件抽离出来。。 自定义tabbar 自定义navbar 长列表 下拉刷新 上拉加载 购物车sku … Demo page调用页面 [代码]<view class="container"> <waterfall wx:if="{{ _type === 0 }}" generic:selectable="test-view" views="{{ views }}" options="{{ options }}" /> <waterfall wx:else generic:selectable="image-view" views="{{ images }}" options="{{ options }}" /> </view> <view class="btns"> <button bind:tap="loadView">模拟节点</button> <button bind:tap="loadImage">远程图片</button> </view> [代码] [代码]Page({ data: { views: [], loading: false, options: { span: 30, column: 2, gap: [10, 10], rows: 2, }, images: [], _page: 1, _type: 0, }, onLoad() { // 生成随机数据 // this.generateViews() // this.getHuaBanList() }, loadView() { this.data._page = 1 this.setData({ images: [], _type: 0 }) this.generateViews() }, loadImage() { this.data._type = 1 this.setData({ views: [], _type: 1 }) this.getHuaBanList() }, getHuaBanList() { let { images, _page } = this.data wx.request({ url: `https://huaban.com/search/?q=随机&page=${_page}&per_page=10&wfl=1`, header: { accept: 'application/json', 'accept-language': 'zh-CN,zh;q=0.9', 'x-request': 'JSON', 'x-requested-with': 'XMLHttpRequest', }, success: (res) => { res.data.pins.map((v) => { images.push({ url: `https://hbimg.huabanimg.com/${v.file.key}_/fw/480/format/webp`, title: v.raw_text, }) }) this.setData({ images, _page: ++_page }) wx.hideLoading() }, }) }, generateViews() { const { views } = this.data for (let i = 0; i < 10; i++) { views.push({ width: this._randomNum(150, 500) + 'px', height: this._randomNum(200, 600) + 'px', }) } this.setData({ views, }) }, _randomNum(minNum, maxNum) { switch (arguments.length) { case 1: return parseInt(String(Math.random() * minNum + 1), 10) break case 2: return parseInt(Math.random() * (maxNum - minNum + 1) + minNum, 10) break default: return 0 break } }, onReachBottom() { let { loading, _type } = this.data if (!loading) { wx.showLoading({ title: 'loading...', }) loading = true setTimeout(() => { _type === 0 ? this.generateViews() : this.getHuaBanList() wx.hideLoading() loading = false }, 1000) } }, }) [代码] [代码]{ "usingComponents": { "waterfall": "/components/waterfall/index", "test-view": "/components/test-view/index", "image-view": "/components/image-view/index" } } [代码] 模拟load异步的自定义组件 [代码]<view class="c-test-view"> <view class="waterfall-load-node"> {{value.width}}*{{value.height}} </view> <view class="waterfall-load-other">模拟加载图片</view> </view> [代码] [代码]Component({ properties: { value: Object, index: Number, }, lifetimes: { ready() { const { index } = this.data const timer = 1000 + 300 * String(index).charAt(index.length - 1) setTimeout(() => this.load(), timer) }, }, methods: { load() { this.triggerEvent('load', { ...this.data, }) }, }, }) [代码] [代码].c-test-view { width: 100%; height: 100%; display: flex; flex-flow: column; justify-content: center; align-items: center; background: white; } .c-test-view .waterfall-load-node { height: 50%; flex-grow: 1; transition: all 0.3s; display: inline-flex; flex-flow: column; justify-content: center; align-items: center; background: #eeeeee; width: 100%; opacity: 0; } .c-test-view .waterfall-load-other { width: 100%; height: 80rpx; display: inline-flex; justify-content: center; align-items: center; background: cornflowerblue; color: white; } [代码] 随机获取花瓣网图片的自定义组件 [代码]<view class="c-image-view"> <view class="waterfall-load-node"> <image class="load-image" src="{{ value.url }}" bind:load="load" /> </view> <view class="waterfall-load-other">{{ value.title }}</view> </view> [代码] [代码]Component({ properties: { value: Object, index: Number, }, lifetimes: { ready() {}, }, methods: { load(event) { this.triggerEvent('load', { ...this.data, value: { ...event.detail }, }) }, }, }) [代码] [代码].c-image-view { width: 100%; display: inline-flex; flex-flow: column; background: white; border-radius: 10px; overflow: hidden; height: 100%; } .c-image-view .waterfall-load-node { width: 100%; height: 50%; display: inline-flex; flex-grow: 1; background: gainsboro; transition: opacity 0.3s; opacity: 0; overflow: hidden; visibility: hidden; } .c-image-view .waterfall-load-node .load-image { width: 100%; height: 100%; overflow: hidden; } .c-image-view .waterfall-load-other { font-size: 30rpx; background: white; min-height: 60rpx; padding: 10px; display: flex; align-items: center; } [代码] 代码片段 https://developers.weixin.qq.com/s/Q02FETmW7ind

#### 背景介绍 在各种小程序中，我们经常会遇到 这种情况 有一个 列表，点击列表中的一项进入详情，详情有个按钮，删除了这一项，这个时候当用户返回到列表页时, 发现列表中的这一项依然存在，这种情况，就是一个 `bug`，也就是数据不同步问题，这个时候测试小姐姐 肯定会找你，让你解决，这个时候，你也许会很快速的解决，但过一会儿，测试小姐姐又来找你说，我打开了 四五个页面更改了用户状态，但我一层一层返回到首页，发现有好几个页面数据没有刷新，也是一个 bug， 这个时候你就犯愁了，怎么解决，常规方法有下面几种 #### 解决方法     1. 将所有请求放到 生命周期 `onShow` 中，只要我们页面重新显示，就会重新请求，数据也会刷新     2. 通过用 `getCurrentPages` 获取页面栈，然后找到对应的 页面实例，调用实例方法，去刷新数据     3. 通过设置一个全局变量，例如 App.globalData.xxx，通过改变这个变量的值，然后在对应 onShow        中检查，如果值已改变，刷新数据     4. 在打开详情页时，使用 redirectTo 而不是 navigateTo，这样在打开新的页面时，会销毁当前页面，        返回时就不会回到这个里面，自然也不会有数据不同步问题    #### 存在的问题 1. 假如我们将 所有 请求放到 onShow 生命周期中，自然能解决所有数据刷新问题，但是 onShow 这个生命周期，有两个问题 第一个问题，它其实是在 onLoad 后面执行的，也就是说，假如请求耗时相同，从它发起请求到页面渲染， 会比 onLoad 慢 第二个问题，那就是页面隐藏、调用微信分享、锁频等等都会触发执行，请求放置于 `onShow` 中就会造成 大量不需要的请求，造成服务器压力，多余的资源浪费、也会造成用户体验不好的问题 2. 通过 `getCurrentPages` 获取页面栈，然后找到对应的 页面实例，调用实例方法，去刷新数据，这也 不失为一个办法，但是就如微信官方文档所说 > 不要尝试修改页面栈，会导致路由以及页面状态错误。 > 不要在 App.onLaunch 的时候调用 `getCurrentPages()`，此时 page 还没有生成。 同时、当需要通信的页面有两个、三个、多个呢，这里去使用 `getCurrentPages` 就会比较困难、繁琐 3. 通过设置全局变量的方法，当需要使用的地方比较少时，可以接受，当使用的地方多的时候，维护起来 就会很困难，代码过于臃肿，也会有很多问题 4. 使用 redirectTo 而不是 navigateTo，从用来体验来说，很糟糕，并且只存在一个页面，对于 tab 页面，它也无能为力，不推荐使用 #### 最佳实践 在 Vue 中， 可以通过 new Vue() 来实现一个 event bus作为事件总线，来达到事件通知的功能，在各大 框架中，也有自身的事件机制实现，那么我们完全可以通过同样的方法，实现一个事件中心，来管理我们的事件， 同时，解决我们的问题。iny-bus 就是这样一个及其轻量的事件库,使用 typescript 编写，100% 测试覆 盖率，能运行 js 的环境，就能使用 传送门 [源码](https://github.com/landluck/iny-bus) [NPM](https://www.npmjs.com/package/iny-bus) [文档](https://landluck.github.io/iny-bus/docs/) #### 简单使用 iny-bus 使用及其简单，在需要的页面 onLoad 中添加事件监听， 在需要触发事件的地方派发事件，使监 听该事件的每个页面执行处理函数，达到通信和刷新数据的目的，在小程序中的使用可以参考以下代码 [代码]   // 小程序[代码] [代码]   import bus from [代码][代码]'iny-bus'[代码]   [代码]   // 添加事件监听[代码] [代码]   // 在 onLoad 中注册, 避免在 onShow 中使用[代码] [代码]    onLoad () {[代码] [代码]      this[代码][代码].eventId = bus.on([代码][代码]'事件名'[代码][代码], (a, b, c, d) => {[代码] [代码]      // 支持多参数[代码] [代码]      console.log(a, b, c, d)[代码]   [代码]      this[代码][代码].setData({ a [代码]}) [代码]      // 调用页面请求函数，刷新数据[代码] [代码]      this[代码][代码].refreshPageData()[代码] [代码]    })[代码]   [代码]    // 添加只需要执行一次的 事件监听[代码]   [代码]    this[代码][代码].eventIdOnce = bus.once([代码][代码]'事件名'[代码][代码], () => {[代码] [代码]      // do some thing[代码] [代码]     })[代码] [代码]   }[代码]   [代码]   // 移除事件监听，该函数有两个参数，第二个事件id不传，会移除整个事件监听，传入ID，会移除该[代码] [代码]   // 页面的事件监听，避免多余资源浪费, 在添加事件监[代码][代码]/// 听后，页面卸载(onUnload)时建议移除[代码]   [代码]   onUnload () {[代码] [代码]     bus.remove([代码][代码]'事件名'[代码][代码], [代码][代码]this[代码][代码].eventId)[代码] [代码]   }[代码]   [代码]   // 派发事件，触发事件监听处更新视图[代码] [代码]  // 支持多参传递[代码] [代码]  onClick () {[代码] [代码]    bus.emit([代码][代码]'事件名'[代码][代码], a, b, c)[代码] [代码]  }[代码] 更详细的使用和例子可以参考 [Github iny-bus 小程序代码](https://github.com/landluck/iny-bus/tree/master/examples) #### iny-bus 具体实现 * 基本打包工具，这里使用非常优秀的开源库 [typescript-library-starter](https://github.com/alexjoverm/typescript-library-starter)，具体细节不展开 * 测试工具 使用 facebook 的 [jest](https://github.com/facebook/jest) * build ci 使用 [travis-ci](https://www.travis-ci.org/） * 测试覆盖率上传使用 [codecov](https://codecov.io/) * 具体的其他细节大家可以看源码中的 [package.json](https://github.com/landluck/iny-bus/blob/master/package.json)，这里就一一展开讲了 iny-bus 的核心代码，其实就这么多，总的来说，非常少，但是能解决我们在小程序中遇到的大量 通信 和 数据刷新问题，是采用 各大平台小程序 原生开发时，页面通信的不二之选，同时，100% 的测试覆盖率，确保了 iny-bus 在使用中的稳定性和安全性，当然，每个库都是从简单走向复杂，功能慢慢完善，如果 大家在使用或者源码中发现了bug或者可以优化的点，欢迎大家提 pr 或者直接联系我 最后，如果 iny-bus 给你提供了帮助或者让你有任何收获，请给 作者 点个赞，感谢大家 [点赞](https://github.com/landluck/iny-bus)

- 需求的场景描述（希望解决的问题） image组件目前必须要显式地定义宽高才能显示，无法根据图片尺寸自动决定组件宽高。 就是说，当我取得的图片尺寸是不固定的时候（比如聊天双方发送的图片），我无法控制image组件的尺寸随着图片尺寸自动变化。而只能在一个固定大小的image框中，来决定我要让这张图片左右留白还是上下留白（在等比例缩放且显示全图的前提下）。 - 希望提供的能力 希望image组件的能尺寸随着图片尺寸自动变化。 类似于web端的"width/height：auto"，比如图片本身的尺寸是100px*300px，允许设定image组件的style=“width:200px;height:auto”,使得整个image组件的宽高是200*600。 你可能会建议我使用mode=“aspectFit”，但是这个属性设置后只能使得图片“看起来被缩放了”，整个image组件依然是固定设置的大小。

看官方demo的小伙伴知道，自定义tabbar需要在小程序根目录底下建一个名叫custom-tab-bar的组件（我有试过，如果放在components目录里面小程序会识别不了），目前我自己实现的效果是：通过在配置可以切换tab，也可以点击tab后重定向到新页面，支持隐藏tabbar，同时也可以显示右上角文本和小红点。 官方demo里面用的是cover-view，我改成view，因为如果页面有弹窗的话我希望可以盖住tabbar 总结一下有以下注意点： 1、tabbar组件的目录命名需要是custom-tab-bar 2、app.json增加自定义tabbar配置 3、wx.navigateTo不允许跳转到tabb页面 4、进入tab页面时，需要调用tabbar.js手动切换tab 效果图： [图片] 可以扫码体验 [图片] 代码目录如下： [图片] 代码如下： app.json增加自定义tabbar配置 "tabBar": { "custom": true, "color": "#7A7E83", "selectedColor": "#3cc51f", "borderStyle": "black", "backgroundColor": "#ffffff", "list": [ { "pagePath": "pages/love/love", "text": "首页" }, { "pagePath": "pages/tabbar/empty", "text": "礼物说" }, { "pagePath": "pages/tabbar/empty", "text": "恋人圈" }, { "pagePath": "pages/me/me", "text": "我" } ] }, 自定义tabbar组件代码如下 index.js //api.js是我自己对微信接口的一些封装 const api = require('../utils/api.js'); //获取应用实例 const app = getApp(); Component({ data: { isPhoneX: false, selected: 0, hide: false, list: [{ showRedDot: false, showBadge: false, badgeText: "", pagePath: "/pages/love/love", iconPath: "/images/tabbar/home.png", selectedIconPath: "/images/tabbar/home-select.png", text: "首页" }, { showRedDot: false, showBadge: false, badgeText: "", pagePath: "/pages/tabbar/empty", navigatePath: "/pages/gifts/giftList", iconPath: "/images/tabbar/gift.png", selectedIconPath: "/images/tabbar/gift-select.png", text: "礼物说", hideTabBar: true }, { showRedDot: false, showBadge: false, badgeText: "", pagePath: "/pages/tabbar/empty", navigatePath: "/pages/moments/moments", iconPath: "/images/tabbar/lover-circle.png", selectedIconPath: "/images/tabbar/lover-circle-select.png", text: "恋人圈", hideTabBar: true }, { showRedDot: false, showBadge: false, badgeText: "", pagePath: "/pages/me/me", iconPath: "/images/tabbar/me.png", selectedIconPath: "/images/tabbar/me-select.png", text: "我" }] }, ready() { // console.error("custom-tab-bar ready"); this.setData({ isPhoneX: app.globalData.device.isPhoneX }) }, methods: { switchTab(e) { const data = e.currentTarget.dataset; console.log("tabBar参数：", data); api.vibrateShort(); if (data.hideTabBar) { api.navigateTo(data.navigatePath); } else { /*this.setData({ selected: data.index }, function () { wx.switchTab({url: data.path}); });*/ /** * 改为直接跳转页面， * 因为发现如果先设置selected的话， * 对应tab图标会先选中，然后页面再跳转， * 会出现图标变成未选中然后马上选中的过程 */ wx.switchTab({url: data.path}); } }, /** * 显示tabbar * @param e */ showTab(e){ this.setData({ hide: false }, function () { console.log("showTab执行完毕"); }); }, /** * 隐藏tabbar * @param e */ hideTab(e){ this.setData({ hide: true }, function () { console.log("hideTab执行完毕"); }); }, /** * 显示小红点 * @param index */ showRedDot(index, success, fail) { try { const list = this.data.list; list[index].showRedDot = true; this.setData({ list }, function () { typeof success == 'function' && success(); }) } catch (e) { typeof fail == 'function' && fail(); } }, /** * 隐藏小红点 * @param index */ hideRedDot(index, success, fail) { try { const list = this.data.list; list[index].showRedDot = false; this.setData({ list }, function () { typeof success == 'function' && success(); }) } catch (e) { typeof fail == 'function' && fail(); } }, /** * 显示tab右上角文本 * @param index * @param text */ showBadge(index, text, success, fail) { try { const list = this.data.list; Object.assign(list[index], {showBadge: true, badgeText: text}); this.setData({ list }, function () { typeof success == 'function' && success(); }) } catch (e) { typeof fail == 'function' && fail(); } }, /** * 隐藏tab右上角文本 * @param index */ hideBadge(index, success, fail) { try { const list = this.data.list; Object.assign(list[index], {showBadge: false, badgeText: ""}); this.setData({ list }, function () { typeof success == 'function' && success(); }) } catch (e) { typeof fail == 'function' && fail(); } } } }); index.html <view class="footer-tool-bar flex-center {{isPhoneX? 'phx_68':''}}" hidden="{{hide}}"> <view class="tab flex-full {{selected === index ? 'focus':''}}" wx:for="{{list}}" wx:key="index" data-path="{{item.pagePath}}" data-index="{{index}}" data-navigate-path="{{item.navigatePath}}" data-hide-tab-bar="{{item.hideTabBar}}" data-open-ext-mini-program="{{item.openExtMiniProgram}}" data-ext-mini-program-app-id="{{item.extMiniProgramAppId}}" bindtap="switchTab"> <view class="text"> <view class="dot" wx:if="{{item.showRedDot}}"></view> <view class="badge" wx:if="{{item.showBadge}}">{{item.badgeText}}</view> <image class="icon" src="{{item.selectedIconPath}}" hidden="{{selected !== index}}"></image> <image class="icon" src="{{item.iconPath}}" hidden="{{selected === index}}"></image> </view> </view> </view>     index.json { "component": true, "usingComponents": {} } index.wxss @import "/app.wxss"; .footer-tool-bar{ background-color: #fff; height: 100rpx; width: 100%; position: fixed; bottom: 0; z-index: 100; text-align: center; font-size: 24rpx; transition: transform .3s; border-radius: 30rpx 30rpx 0 0; /*padding-bottom: env(safe-area-inset-bottom);*/ box-shadow:0rpx 0rpx 18rpx 8rpx rgba(212, 210, 211, 0.35); } .footer-tool-bar .tab{ color: #242424; height: 100%; line-height: 100rpx; } .footer-tool-bar .focus{ color: #f96e49; font-weight: 500; } .footer-tool-bar .icon{ width: 44rpx; height: 44rpx; margin: 18rpx auto; } .footer-tool-bar .text{ line-height: 80rpx; height: 80rpx; position: relative; display: inline-block; padding: 0rpx 40rpx; box-sizing: border-box; margin: 10rpx auto; } .footer-tool-bar .dot{ position: absolute; top: 16rpx; right: 16rpx; height: 16rpx; width: 16rpx; border-radius: 50%; background-color: #f45551; } .footer-tool-bar .badge{ position: absolute; top: 8rpx; right: 8rpx; height: 30rpx; width: 30rpx; line-height: 30rpx; border-radius: 50%; background-color: #f45551; color: #fff; text-align: center; font-size: 20rpx; font-weight: 450; } .hide{ transform: translateY(100%); } app.wxss（这里的样式文件是我用来存放一些公共样式） /**app.wxss**/ page { background-color: #f5f5f5; height: 100%; -webkit-overflow-scrolling: touch; } .container { height: 100%; display: flex; flex-direction: column; align-items: center; justify-content: space-between; box-sizing: border-box; } .blur { filter: blur(80rpx); opacity: 0.65; } .flex-center { display: flex; align-items: center; justify-content: center; } .flex-column { display: flex; /*垂直居中*/ align-items: center; /*水平居中*/ justify-content: center; flex-direction: column; } .flex-start-horizontal{ display: flex; justify-content: flex-start; } .flex-end-horizontal{ display: flex; justify-content: flex-end; } .flex-start-vertical{ display: flex; align-items: flex-start; } .flex-end-vertical{ display: flex; align-items: flex-end; } .flex-wrap { display: flex; flex-wrap: wrap; } .flex-full { flex: 1; } .reset-btn:after { border: none; } .reset-btn { background-color: #ffffff; border-radius: 0; margin: 0; padding: 0; overflow: auto; } .loading{ opacity: 0; transition: opacity 1s; } .load-over{ opacity: 1; } .phx_68{ padding-bottom: 68rpx; } .phx_34{ padding-bottom: 34rpx; } 另外我还对tabbar的操作做了简单的封装： tabbar.js const api = require('/api.js'); /** * 切换tab * @param me * @param index */ const switchTab = function (me, index) { if (typeof me.getTabBar === 'function' && me.getTabBar()) { console.log("切换tab：", index); me.getTabBar().setData({ selected: index }) } }; /** * 显示 tabBar 某一项的右上角的红点 * @param me * @param index */ const showRedDot = function (me, index, success, fail) { if (typeof me.getTabBar === 'function' && me.getTabBar()) { me.getTabBar().showRedDot(index, success, fail); } }; /** * 隐藏 tabBar 某一项的右上角的红点 * @param me * @param index */ const hideRedDot = function (me, index, success, fail) { if (typeof me.getTabBar === 'function' && me.getTabBar()) { me.getTabBar().hideRedDot(index, success, fail); } }; /** * 显示tab右上角文本 * @param me * @param index * @param text */ const showBadge = function (me, index, text, success, fail) { if (typeof me.getTabBar === 'function' && me.getTabBar()) { me.getTabBar().showBadge(index, text, success, fail); } }; /** * 隐藏tab右上角文本 * @param me * @param index */ const hideBadge = function (me, index, success, fail) { if (typeof me.getTabBar === 'function' && me.getTabBar()) { me.getTabBar().hideBadge(index, success, fail); } }; /** * 显示tabbar * @param me * @param success */ const showTab = function(me, success){ if (typeof me.getTabBar === 'function' && me.getTabBar()) { me.getTabBar().showTab(success); } }; /** * 隐藏tabbar * @param me * @param success */ const hideTab = function(me, success){ if (typeof me.getTabBar === 'function' && me.getTabBar()) { me.getTabBar().hideTab(success); } }; module.exports = { switchTab, showRedDot, hideRedDot, showBadge, hideBadge, showTab, hideTab }; 最后，进入到tab对应页面的时候要手动调用一下swichTab接口，然tabbar聚焦到当前tab /** * 生命周期函数--监听页面显示 */ onShow: function () { tabbar.switchTab(this, this.data.tabIndex);//tabIndex是当前tab的索引 }

错误："errMsg": "request:fail url not in domain list" 排查方案： 1、确认域名 登录mp后台对域名进行确认（左侧导航->开发->开发管理->开发设置->服务器域名配置） 2、详情页确认 小程序右上角的胶囊->点击该小程序的名称->点击更多资料->进入到详情页 3、kill重新打开 配置完域名之后，在手机端，下拉小程序->把当前的小程序删除->再重新进行进入，重试。（需要删除手机上该小程序的开发版、体验版、正式版才会生效） 4、配置重定向域名 确认域名是否有重定向，有的话重定向后的域名也要配置。

https://developers.weixin.qq.com/miniprogram/dev/api/file/FileSystemManager.writeFileSync.html 今天2020/4/27 在下午时间使用FileSystemManager.writeFileSync(string filePath, string|ArrayBuffer data, string encoding)可以将图片读取出来 在六点左右 这个方法报错 不知是微信在维护还是我代码抒写的问题

前言最近在学习Redis相关知识，看了阿里的redis开发规范，以及Redis开发与运维这本书。分使用规范、有坑的命令、项目实战操作、运维配置四个方向。整理了使用Redis的21个注意点，希望对大家有帮助，一起学习哈 [图片] 1、Redis的使用规范 1.1、 key的规范要点 我们设计Redis的key的时候，要注意以下这几个点： 以业务名为key前缀，用冒号隔开，以防止key冲突覆盖。如，live:rank:1确保key的语义清晰的情况下，key的长度尽量小于30个字符。key禁止包含特殊字符，如空格、换行、单双引号以及其他转义字符。Redis的key尽量设置ttl，以保证不使用的Key能被及时清理或淘汰。 1.2、value的规范要点 Redis的value值不可以随意设置的哦。 第一点，如果大量存储bigKey是会有问题的，会导致慢查询，内存增长过快等等。 如果是String类型，单个value大小控制10k以内。如果是hash、list、set、zset类型，元素个数一般不超过5000。 第二点，要选择适合的数据类型。不少小伙伴只用Redis的String类型，上来就是set和get。实际上，Redis 提供了丰富的数据结构类型，有些业务场景，更适合[代码]hash、zset[代码]等其他数据结果。 [图片] 反例： set user:666:name jay set user:666:age 18 正例 hmset user:666 name jay age 18 1.3. 给Key设置过期时间，同时注意不同业务的key，尽量过期时间分散一点因为Redis的数据是存在内存中的，而内存资源是很宝贵的。我们一般是把Redis当做缓存来用，而不是数据库，所以key的生命周期就不宜太长久啦。因此，你的key，一般建议用expire设置过期时间。 如果大量的key在某个时间点集中过期，到过期的那个时间点，Redis可能会存在卡顿，甚至出现缓存雪崩现象，因此一般不同业务的key，过期时间应该分散一些。有时候，同业务的，也可以在时间上加一个随机值，让过期时间分散一些。 1.4.建议使用批量操作提高效率 我们日常写SQL的时候，都知道，批量操作效率会更高，一次更新50条，比循环50次，每次更新一条效率更高。其实Redis操作命令也是这个道理。 Redis客户端执行一次命令可分为4个过程：1.发送命令-> 2.命令排队-> 3.命令执行-> 4. 返回结果。1和4 称为RRT（命令执行往返时间）。 Redis提供了批量操作命令，如mget、mset等，可有效节约RRT。但是呢，大部分的命令，是不支持批量操作的，比如hgetall，并没有mhgetall存在。Pipeline 则可以解决这个问题。 Pipeline是什么呢?它能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端. 我们先来看下没有使用Pipeline执行了n条命令的模型： [图片] 使用Pipeline执行了n次命令，整个过程需要1次RTT，模型如下： [图片] 2、Redis 有坑的那些命令 2.1. 慎用[代码]O(n)[代码]复杂度命令，如[代码]hgetall[代码]、[代码]smember[代码]，[代码]lrange[代码]等 因为Redis是单线程执行命令的。hgetall、smember等命令时间复杂度为O(n)，当n持续增加时，会导致 Redis CPU 持续飙高，阻塞其他命令的执行。 hgetall、smember，lrange等这些命令不是一定不能使用，需要综合评估数据量，明确n的值，再去决定。比如hgetall，如果哈希元素n比较多的话，可以优先考虑使用hscan。 2.2 慎用Redis的monitor命令 Redis Monitor 命令用于实时打印出Redis服务器接收到的命令，如果我们想知道客户端对redis服务端做了哪些命令操作，就可以用Monitor 命令查看，但是它一般调试用而已，尽量不要在生产上用！因为monitor命令可能导致redis的内存持续飙升。 monitor的模型是酱紫的，它会将所有在Redis服务器执行的命令进行输出，一般来讲Redis服务器的QPS是很高的，也就是如果执行了monitor命令，Redis服务器在Monitor这个客户端的输出缓冲区又会有大量“存货”，也就占用了大量Redis内存。 [图片] 2.3、生产环境不能使用 keys指令 Redis Keys 命令用于查找所有符合给定模式pattern的key。如果想查看Redis 某类型的key有多少个，不少小伙伴想到用keys命令，如下： keys key前缀* 但是，redis的[代码]keys[代码]是遍历匹配的，复杂度是[代码]O（n）[代码]，数据库数据越多就越慢。我们知道，redis是单线程的，如果数据比较多的话，keys指令就会导致redis线程阻塞，线上服务也会停顿了，直到指令执行完，服务才会恢复。因此，一般在生产环境，不要使用keys指令。官方文档也有声明： Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using sets. 其实，可以使用scan指令，它同keys命令一样提供模式匹配功能。它的复杂度也是 O(n)，但是它通过游标分步进行，不会阻塞redis线程;但是会有一定的重复概率，需要在客户端做一次去重。 scan支持增量式迭代命令，增量式迭代命令也是有缺点的：举个例子， 使用 SMEMBERS 命令可以返回集合键当前包含的所有元素， 但是对于 SCAN 这类增量式迭代命令来说， 因为在对键进行增量式迭代的过程中， 键可能会被修改， 所以增量式迭代命令只能对被返回的元素提供有限的保证 。 2.4 禁止使用flushall、flushdb Flushall 命令用于清空整个 Redis 服务器的数据(删除所有数据库的所有 key )。Flushdb 命令用于清空当前数据库中的所有 key。 这两命令是原子性的，不会终止执行。一旦开始执行，不会执行失败的。 2.5 注意使用del命令 删除key你一般使用什么命令？是直接del？如果删除一个key，直接使用del命令当然没问题。但是，你想过del的时间复杂度是多少嘛？我们分情况探讨一下： 如果删除一个String类型的key，时间复杂度就是[代码]O（1）[代码]，可以直接del。如果删除一个List/Hash/Set/ZSet类型时，它的复杂度是[代码]O(n)[代码], n表示元素个数。 因此，如果你删除一个List/Hash/Set/ZSet类型的key时，元素越多，就越慢。当n很大时，要尤其注意，会阻塞主线程的。那么，如果不用del，我们应该怎么删除呢？ 如果是List类型，你可以执行[代码]lpop或者rpop[代码]，直到所有元素删除完成。如果是Hash/Set/ZSet类型，你可以先执行[代码]hscan/sscan/scan[代码]查询，再执行[代码]hdel/srem/zrem[代码]依次删除每个元素。 2.6 避免使用SORT、SINTER等复杂度过高的命令。 执行复杂度较高的命令，会消耗更多的 CPU 资源，会阻塞主线程。所以你要避免执行如[代码]SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE[代码]等聚合命令，一般建议把它放到客户端来执行。 3、项目实战避坑操作 3.1 分布式锁使用的注意点 分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。秒杀下单、抢红包等等业务场景，都需要用到分布式锁。我们经常使用Redis作为分布式锁，主要有这些注意点： 3.1.1 两个命令SETNX + EXPIRE分开写（典型错误实现范例） if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁 expire（key_resource_id，100）; //设置过期时间 try { do something //业务请求 }catch(){ 　　} 　　finally { jedis.del(key_resource_id); //释放锁 } } 如果执行完[代码]setnx[代码]加锁，正要执行expire设置过期时间时，进程crash或者要重启维护了，那么这个锁就“长生不老”了，别的线程永远获取不到锁啦，所以一般分布式锁不能这么实现。 3.1.2 SETNX + value值是过期时间 (有些小伙伴是这么实现，有坑) long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间 String expiresStr = String.valueOf(expires); // 如果当前锁不存在，返回加锁成功 if (jedis.setnx(key_resource_id, expiresStr) == 1) { return true; } // 如果锁已经存在，获取锁的过期时间 String currentValueStr = jedis.get(key_resource_id); // 如果获取到的过期时间，小于系统当前时间，表示已经过期 if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) { // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈） String oldValueStr = jedis.getSet(key_resource_id, expiresStr); if (oldValueStr != null && oldValueStr.equals(currentValueStr)) { // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁 return true; } } //其他情况，均返回加锁失败 return false; } 这种方案的缺点： 过期时间是客户端自己生成的，分布式环境下，每个客户端的时间必须同步没有保存持有者的唯一标识，可能被别的客户端释放/解锁。锁过期的时候，并发多个客户端同时请求过来，都执行了[代码]jedis.getSet()[代码]，最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖。 3.1.3： SET的扩展命令（SET EX PX NX）（注意可能存在的问题） if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加锁 try { do something //业务处理 }catch(){ 　　} 　　finally { jedis.del(key_resource_id); //释放锁 } } 这个方案还是可能存在问题： 锁过期释放了，业务还没执行完。锁被别的线程误删。 3.1.4 SET EX PX NX + 校验唯一随机值,再删除（解决了误删问题，还是存在锁过期，业务没执行完的问题） if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁 try { do something //业务处理 }catch(){ 　　} 　　finally { //判断是不是当前线程加的锁,是才释放 if (uni_request_id.equals(jedis.get(key_resource_id))) { jedis.del(lockKey); //释放锁 } } } 在这里，判断是不是当前线程加的锁和释放锁不是一个原子操作。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端，会解除他人加的锁。 [图片] 一般也是用lua脚本代替。lua脚本如下： if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end; 3.1.5 Redisson框架 + Redlock算法 解决锁过期释放，业务没执行完问题+单机问题 Redisson 使用了一个[代码]Watch dog[代码]解决了锁过期释放，业务没执行完问题，Redisson原理图如下: [图片] 以上的分布式锁，还存在单机问题： [图片] 如果线程一在Redis的master节点上拿到了锁，但是加锁的key还没同步到slave节点。恰好这时，master节点发生故障，一个slave节点就会升级为master节点。线程二就可以获取同个key的锁啦，但线程一也已经拿到锁了，锁的安全性就没了。 针对单机问题，可以使用Redlock算法。有兴趣的朋友可以看下我这篇文章哈，七种方案！探讨Redis分布式锁的正确使用姿势 3.2 缓存一致性注意点 如果是读请求，先读缓存，后读数据库如果写请求，先更新数据库，再写缓存每次更新数据后，需要清除缓存缓存一般都需要设置一定的过期失效一致性要求高的话，可以使用biglog+MQ保证。 感兴趣的小伙伴点击链接，了解更多详情~ http://github.crmeb.net/u/yi 3.3 合理评估Redis容量，避免由于频繁set覆盖，导致之前设置的过期时间无效。 我们知道，Redis的所有数据结构类型，都是可以设置过期时间的。假设一个字符串，已经设置了过期时间，你再去重新设置它，就会导致之前的过期时间无效。 [图片] Redis [代码]setKey[代码]源码如下： void setKey(redisDb *db,robj *key,robj *val) { if(lookupKeyWrite(db,key)==NULL) { dbAdd(db,key,val); }else{ dbOverwrite(db,key,val); } incrRefCount(val); removeExpire(db,key); //去掉过期时间 signalModifiedKey(db,key); } 实际业务开发中，同时我们要合理评估Redis的容量，避免频繁set覆盖，导致设置了过期时间的key失效。新手小白容易犯这个错误。 3.4 缓存穿透问题 先来看一个常见的缓存使用方式：读请求来了，先查下缓存，缓存有值命中，就直接返回；缓存没命中，就去查数据库，然后把数据库的值更新到缓存，再返回。 [图片] 缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。 通俗点说，读请求访问时，缓存和数据库都没有某个值，这样就会导致每次对这个值的查询请求都会穿透到数据库，这就是缓存穿透。 缓存穿透一般都是这几种情况产生的： 业务不合理的设计，比如大多数用户都没开守护，但是你的每个请求都去缓存，查询某个userid查询有没有守护。业务/运维/开发失误的操作，比如缓存和数据库的数据都被误删除了。黑客非法请求攻击，比如黑客故意捏造大量非法请求，以读取不存在的业务数据。 如何避免缓存穿透呢？ 一般有三种方法。 如果是非法请求，我们在API入口，对参数进行校验，过滤非法值。如果查询数据库为空，我们可以给缓存设置个空值，或者默认值。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。 布隆过滤器原理：它由初始值为0的位图数组和N个哈希函数组成。一个对一个key进行N个hash算法获取N个值，在比特数组中将这N个值散列后设定为1，然后查的时候如果特定的这几个位置都为1，那么布隆过滤器判断该key存在。 3.5 缓存雪奔问题 缓存雪奔： 指缓存中数据大批量到过期时间，而查询数据量巨大，请求都直接访问数据库，引起数据库压力过大甚至down机。 缓存雪奔一般是由于大量数据同时过期造成的，对于这个原因，可通过均匀设置过期时间解决，即让过期时间相对离散一点。如采用一个较大固定值+一个较小的随机值，5小时+0到1800秒酱紫。Redis 故障宕机也可能引起缓存雪奔。这就需要构造Redis高可用集群啦。 3.6 缓存击穿问题 缓存击穿： 指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。 缓存击穿看着有点像，其实它两区别是，缓存雪奔是指数据库压力过大甚至down机，缓存击穿只是大量并发请求到了DB数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别，是区别在于击穿针对某一热点key缓存，雪奔则是很多key。 解决方案就有两种： 1.使用互斥锁方案。缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。2. “永不过期”，是指没有设置过期时间，但是热点数据快要过期时，异步线程去更新和设置过期时间。 3.7、缓存热key问题 在Redis中，我们把访问频率高的key，称为热点key。如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。 而热点Key是怎么产生的呢？主要原因有两个： 用户消费的数据远大于生产的数据，如秒杀、热点新闻等读多写少的场景。请求分片集中，超过单Redi服务器的性能，比如固定名称key，Hash落入同一台服务器，瞬间访问量极大，超过机器瓶颈，产生热点Key问题。 那么在日常开发中，如何识别到热点key呢？ 凭经验判断哪些是热Key；客户端统计上报；服务代理层上报 如何解决热key问题？ Redis集群扩容：增加分片副本，均衡读流量；对热key进行hash散列，比如将一个key备份为key1,key2……keyN，同样的数据N个备份，N个备份分布到不同分片，访问时可随机访问N个备份中的一个，进一步分担读流量；使用二级缓存，即JVM本地缓存,减少Redis的读请求。 4. Redis配置运维 4.1 使用长连接而不是短连接，并且合理配置客户端的连接池 如果使用短连接，每次都需要过 TCP 三次握手、四次挥手，会增加耗时。然而长连接的话，它建立一次连接，redis的命令就能一直使用，酱紫可以减少建立redis连接时间。连接池可以实现在客户端建立多个连接并且不释放，需要使用连接的时候，不用每次都创建连接，节省了耗时。但是需要合理设置参数，长时间不操作 Redis时，也需及时释放连接资源。 4.2 只使用 db0 Redis-standalone架构禁止使用非db0.原因有两个 一个连接，Redis执行命令select 0和select 1切换，会损耗新能。Redis Cluster 只支持 db0，要迁移的话，成本高 4.3 设置maxmemory + 恰当的淘汰策略。 为了防止内存积压膨胀。比如有些时候，业务量大起来了，redis的key被大量使用，内存直接不够了，运维小哥哥也忘记加大内存了。难道redis直接这样挂掉？所以需要根据实际业务，选好maxmemory-policy(最大内存淘汰策略)，设置好过期时间。一共有8种内存淘汰策略： volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰；allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（最近最少使用）算法进行淘汰。volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key。allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰；volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据；。allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰；noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。 4.4 开启 lazy-free 机制 Redis4.0+版本支持lazy-free机制，如果你的Redis还是有bigKey这种玩意存在，建议把lazy-free开启。当开启它后，Redis 如果删除一个 bigkey 时，释放内存的耗时操作，会放到后台线程去执行，减少对主线程的阻塞影响。 [图片] 参考与感谢Redis 千万不要乱用KEYS命令，不然会挨打的阿里云Redis开发规范Redis 最佳实践指南：7个维度+43条使用规范Redis的缓存穿透及解决方法——布隆过滤器BloomFilter Redis 缓存性能实践及总结 作者：捡田螺的小男孩 感兴趣的小伙伴点击链接，了解详情~ http://github.crmeb.net/u/yi