edit at 11/12 代码传到了：https://github.com/eclipseglory/zasi-components , DEMO演示在文章结尾 小程序没有提供color-picker类似的组件，只能自己做。 可传统的RGB颜色选择器，真的腻了，而且在手机上也不是很操作，就跑网上搜了一圈，发现有一种圆环形的(基于HSV)我很喜欢： [图片] 我自诩对canvas2d和webgl很熟悉，做个这玩意儿很轻松，开始做！没想到痛苦开始了。 从上周5开始，一共做了三个版本： 1.纯canvas版本 2.canvas+组件版本 3.纯组件版本 纯canvas版本这个版本做了整整一天！ [图片] 由于canvas绘制性能问题，特别是因为没有requestAnimationFrame可以调用，别说在真机上测试特别不流畅，就是在模拟器上也小卡小卡的。而且，在纯的canvas进行触摸定位等事件响应处理，计算起来太麻烦，bug不断，只能放弃了。 混合版本因为wxs模块是提供requestAnimationFrame接口的，所以我就想，使用canvas作为底部颜色环，上面就直接用view作为指针，这样，事件触发和处理比起纯canvas要简单得多，而且还能利用rAF回调页面接口去绘制其他canvas。 的确，我的想法得到了证实，这个混合版本比起第一个要流畅得多！ 可就要完工的时候，我却发现，在真机上，cover-view的鼠标事件有很大问题，坐标值飘忽不定，也就是说拖动指针会发生鬼畜般的抖动！加上我不知道怎么debug到wxs模块中，于是跟个sb一样fix，找了半天也没找到问题在哪儿，直到我搜索时，返现有人也遇到和我一样的问题，我才安心了：这是小程序的问题。 动手改！既然cover-view有不行，那就不用它。 实际上canvas在该组件中的作用无非就是绘制一个圆环而已，如果我利用离屏canvas事先画好，然后保存成图片，再用image加载它，这样就可以避免使用canvas来显示圆环了，也就可以不用cover-view放到其顶部！ 想法是好的，可是到了真机上，绘制保存出来的图片时好时坏： [图片] 只能放弃，又耽误我一天。 无canvas版本刚才说了，canvas在该组件中的作用，仅仅是绘制一个颜色环而已，除此之外真没什么用。 那我就用css模拟一个类似圆环就好了，精确到每一度一个颜色一点意义没有。 所以就利用css的background-image属性，做了4个四分之一圆弧，然后拼在一起，得到了一个彩色原版，再用一个小的view遮挡，让它们只露出一部分，圆环就做好了。 之前的代码都不用改，直接用新作的圆环views替换canvas的标签即可。主体框架和功能，不到一天就完成了，不得不说，比起纯的canvas绘制，要方便太多太多。 这是截图： [图片] 代码片段这里是 演示DEMO，要使用的话，复制里面的组件出来用就好。 有些代码我混淆过，但不耽误使用。 有问题找我

在小程序开发过程中经常涉及到一些图表类需求，其中环形进度条比较属于比较常见的需求 [图片] [中间的文字部分需要自己实现，因为每个项目不同，本工具只实现进度条] 上图中，一方面我们我们需要实现动态计算弧度的进度条，还需要在进度条上加上渐变效果，如果每次都需要自己手写，那需要很多重复劳动，所以决定为为小程序生态圈贡献一份小小的力量，下面来介绍一下整个工具的实现思路，喜欢的给个star咯 https://github.com/lucaszhu2zgf/mp-progress 环形进度条由灰色底圈+渐变不确定圆弧+双色纽扣组成，首先先把页面结构写好： .canvas{     position: absolute;     top: 0;     left: 0;     width: 400rpx;     height: 400rpx; } 因为进度条需要盖在文字上面，所以采用了绝对定位。接下来先把灰色底圈给画上： const context = wx.createContext(); // 打底灰色曲线 context.beginPath(); context.arc(this.convert_length(200), this.convert_length(200), r, 0, 2*Math.PI); context.setLineWidth(12); context.setStrokeStyle('#f0f0f0'); context.stroke(); wx.drawCanvas({     canvasId: 'progress',     actions: context.getActions() }); 效果如下： [图片] 接下来就要画绿色的进度条，渐变暂时先不考虑 // 圆弧角度 const deg = ((remain/total).toFixed(2))*2*Math.PI;      // 画渐变曲线 context.beginPath(); // 由于外层大小是400，所以圆弧圆心坐标是200,200 context.arc(this.convert_length(200), this.convert_length(200), r, 0, deg); context.setLineWidth(12); context.setStrokeStyle('#56B37F'); context.stroke(); // 辅助函数，用于转换小程序中的rpx convert_length(length) {     return Math.round(wx.getSystemInfoSync().windowWidth * length / 750); } [图片] 似乎完成了一大部分，先自测看看不是满圆的情况是啥样子，比如现在剩余车位是120个 [图片] 因为圆弧函数arc默认的起点在3点钟方向，而设计想要的圆弧的起点从12点钟方向开始，现在这样是没法达到预期效果。是不是可以使用css让canvas自己旋转-90deg就好了呢？于是我在上面的canvas样式中新增以下规则： .canvas{     transform: rotate(-90deg); } 但是在真机上并不起作用，于是我把新增的样式放到包裹canvas的外层元素上，发现外层元素已经旋转，可是圆弧还是从3点钟方向开始的，唯一能解释这个现象的是官方说：小程序中的canvas使用的是原生组件，所以这样设置css并不能达到我们想要的效果 [图片] 所以必须要在canvas画图的时候把坐标原点移动到弧形圆心，并且在画布内旋转-90deg [图片] // 更换原点 context.translate(this.convert_length(200), this.convert_length(200)); // arc原点默认为3点钟方向，需要调整到12点 context.rotate(-90 * Math.PI / 180); // 需要注意的是，原点变换之后圆弧arc原点也变成了0,0 真机预览效果达成预期 [图片] 接下来添加环形渐变效果，但是canvas原本提供的渐变类型只有两种： 1、LinearGradient线性渐变 [图片] 2、CircularGradient圆形渐变 [图片] 两种渐变中离设计效果最近的是线性渐变，至于为什么能够形成似乎是随圆形弧度增加而颜色变深的效果也只是控制坐标开始和结束的坐标位置罢了 const grd = context.createLinearGradient(0, 0, 100, 90); grd.addColorStop(0, '#56B37F'); grd.addColorStop(1, '#c0e674'); // 画渐变曲线 context.beginPath(); context.arc(0, 0, r, 0, deg); context.setLineWidth(12); context.setStrokeStyle(grd); context.stroke(); 来看一下真机预览效果： [图片] 非常棒，最后就剩下跟随进度条的纽扣效果了 [图片] 根据三角函数，已知三角形夹角根据公式radian = 2*Math.PI/360*deg，再利用cos和sin函数可以x、y，从而计算出纽扣在各部分半圆的坐标 const mathDeg = ((remain/total).toFixed(2))*360; // 计算弧度 let radian = ''; // 圆圈半径 const r = +this.convert_length(170); // 三角函数cos=y/r，sin=x/r，分别得到小点的x、y坐标 let x = 0; let y = 0; if (mathDeg <= 90) {   // 求弧度   radian = 2*Math.PI/360*mathDeg;   x = Math.round(Math.cos(radian)*r);   y = Math.round(Math.sin(radian)*r); } else if (mathDeg > 90 && mathDeg <= 180) {   // 求弧度   radian = 2*Math.PI/360*(180 - mathDeg);   x = -Math.round(Math.cos(radian)*r);   y = Math.round(Math.sin(radian)*r); } else if (mathDeg > 180 && mathDeg <= 270) {   // 求弧度   radian = 2*Math.PI/360*(mathDeg - 180);   x = -Math.round(Math.cos(radian)*r);   y = -Math.round(Math.sin(radian)*r); } else{   // 求弧度   radian = 2*Math.PI/360*(360 - mathDeg);   x = Math.round(Math.cos(radian)*r);   y = -Math.round(Math.sin(radian)*r); } [图片] 有了纽扣的圆形坐标，最后一步就是按照设计绘制样式了 // 画纽扣 context.beginPath(); context.arc(x, y, this.convert_length(24), 0, 2 * Math.PI); context.setFillStyle('#ffffff'); context.setShadow(0, 0, this.convert_length(10), 'rgba(86,179,127,0.5)'); context.fill(); // 画绿点 context.beginPath(); context.arc(x, y, this.convert_length(12), 0, 2 * Math.PI); context.setFillStyle('#56B37F'); context.fill(); 来看一下最终效果 [图片] 最后我重新review了整个代码逻辑，并且已经将代码开源到https://github.com/lucaszhu2zgf/mp-progress，欢迎大家使用

Protocol Buffers，是Google公司开发的一种数据描述语言，类似于XML能够将结构化数据序列化，可用于数据存储、通信协议等方面。 本文和大家聊聊怎样在前端使用 protobuf，在开始前先聊聊 JSON。 关于 JSON 我们前端通常是使用 JSON 格式作为数据格式，JSON也有优点： 1、原生支持 符合 JavaScript 原生语法，书写简单，直观一目了然 2、解析 我们可以使用 JSON.parse 和 JSON.stringify 来做反序列化和序列化，性能好，这一切不需要使用第三方库。 3、不需要描述文件 这点还是优于 PB 的，PB文件需要描述文件来做对应的解析，而 JSON 不需要描述文件。 4、抓包方便 我们可以很方便地通过 Chrome DevTools ， Fiddler，Whistle 等抓包工具可以查看返回的 JSON 数据。 关于 protobuf 要使用 protobuf 首先要一个数据结构的描述文件，然后使用特殊生成的源代码轻松的在各种数据流中使用各种语言进行编写和读取结构数据。 优点： 1、体积小 protobuf 对数据序列化后，数据大小可约小3倍（当然，压缩比还要看具体内容）。 2、语言无关、平台无关 ProtoBuf 支持 Java、C++、Python 等多种语言，支持多个平台。 3、高效 即比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更为简单。 4、扩展性、兼容性好 你可以更新数据结构，而不影响和破坏原有的旧程序。 为什么在前端使用 protobuf protobuf 已经被后台广为使用，而且优点那么多，为什么前端不愿意使用呢？我认为很重要的两点： 1、不便于抓包和调试，因为 protobuf 需要依赖对应的描述文件才可以正确地把数据解析出来，而JSON不需要，这就导致在开发和测试场景下不便于抓包。 2、需要先把 protobuf 描述文件异步加载，这就多了一次网络请求，或者打包到业务代码中，导致业务代码变大。 3、解析后有很多冗余的字段，需要前端过滤和整理成可用的 JSON 结构体。 有了这些问题为什么还折腾 protobuf 呢？ 其实在某些场景下比如单个请求数据量较大，上几M 的回包，当然也可以选择分包拉取，但这样无论并发加载还是阻塞加载，如果需要读取到某片数据，那么你的业务代码写起来将是将是非常复杂。 ##数据对比 后端通过 protobuf 指令生成的 protobuf 描述文件，需要依赖于 google-protobuf.js。 拿我们的回放业务来做对比，课堂进入回放模式时需要加载互动字幕文件，如果这些数据使用 protobuf 会有什么变化？ 先看看企鹅辅导的回放字幕文件结构： [图片] 注：因为数据有嵌套 protobuf ，所以要分为整体字幕文件​ 和 具体的交互 pb 描述文件，待解析到具体交互时，才会使用 交互 pb 描述文件去解析 。 文件名 说明 体积 pbplaybackinfo_pb.js 整体字幕 pb 描述文件 83KB chat_pb.js 聊天 pb 描述文件 473KB envelope_pb.js 红包 pb 描述文件 83KB exam_pb.js 考试 pb 描述文件 35KB vote_pb.js 投票 pb 描述文件 90KB 注：以上 pb 描述文件整体 zip 之后 52 KB。 google-protobuf.js 大小：157 KB，zip 后 33KB。 一共 zip 后 85 KB （机子压缩工具没 gzip 格式，这里暂用 zip 。gzip 比 zip 压缩比更高） （1）两种格式字幕文件体积对比 这里抽样对比pb格式的二进制字幕文件体积与对应的json格式的字幕文件的体积 pb字幕文件体积 json字幕文件体积 json体积/pb体积 4.3M 16M 3.72 6.5K 16K 2.46 40K 143K 3.575 23K 97K 4.21 通过抽样对比可得，json格式的字幕文件的体积基本是pb格式的2倍以上，最多甚至是4倍以上，体积差异比较大。 （2）浏览器解析pb字幕文件速度对比 因为字幕文件中的信息节点较多，这里调研解析pb字幕文件的速度。使用的字幕文件是目前体积最大的文件，体积是4.3M。 解析字幕文件的过程分为两步： 解析外层数据，得到json格式概要信息 + 二进制具体数据 解析内层数据，得到json格式具体数据 [图片] 字幕pb 文件（4.3M）做测试得出耗时数据： 解析步骤 耗时 只解析外层数据 279ms 解析外层数据+解析内层数据 1995ms 总结：如果一次解析外层数据和内层数据，会耗时较长，而如果只解析内层数据只需要279ms，比较短。在实现的时候只需要解析外层数据得到概要信息（时间信息、消息类型等），在具体展示的时候才解析内层数据，这样是可以大幅降低初次解析数据导致的耗时。 兼容性 dcodeIO 给出的浏览器兼容 IE9+ [图片] Show you the code 后端提供给前端 pb 描述文件需要执行以下命令来生成 js 可用的 pb 描述文件 [代码]protoc --js_out=library=myproto_libs,binary:. messages.proto base.proto [代码] 假设前端已经拿到了 pb 描述文件 pbplaybackinfo_pb.js ，但描述文件依赖于 google-protobuf.js ，要整体打包后使用。 那么首先 npm i google-protobuf 在业务代码中开始引入： [代码]const messages = require('./pbplaybackinfo_pb'); const playbackRspBody = new messages.PlaybackRspBody; fetch('https://fudao.qq.com/pb/test.pb').then((res) => { res.arrayBuffer().then((res) => { console.time('pb'); const arrayBuffer = new Uint8Array(res); console.log(messages.PlaybackRspBody.deserializeBinary(arrayBuffer, playbackRspBody).toObject()); console.timeEnd('pb'); }); }); [代码] 接着我们这里的例子是异步拉取测试用的 pb 文件，假设是 test.pb。 因为 pb 数据文件是二进制的，所以这里需要使用 arrayBuffer() 的方式，待拉取完毕后再转 Uint8Array 类型。什么是 arrayBuffer ，什么是 uint8Array？ google-protobuf 提供的反序列化接口 deserializeBinary 必须是由对应的 pb 描述中的静态方提供。所以上面使用了 [代码]messages.PlaybackRspBody.deserializeBinary( )[代码] 到这里你拿到是未格式化的二进制 arrayBuffer，所以一定要 .toObject( ) ，官方文档没有提及到这个方法，在这我也折腾了比较长的时间。 最后 前端使用 json 还是 protobuf，还是看具体场景，普通的数据量小的接口当然是 JSON 最好，因为无论从可读性和调试成本上来看，这是最做优的。如果是数据量较大的情况下，需要综合业务代码的改造成本和用户体验等多方面做权衡。

UI组件库合集，大家有遇到好的组件库，欢迎留言评论然后加入到文档里。 第一款： 官方WeUI组件库，地址 https://developers.weixin.qq.com/miniprogram/dev/extended/weui/ 预览码： [图片] 第二款： ColorUI：地址 https://github.com/weilanwl/ColorUI 预览码：   [图片] 第三款： vantUI（又名：ZanUI）：地址 https://youzan.github.io/vant-weapp/#/intro 预览码： [图片] 第四款： MinUI： 地址 https://meili.github.io/min/docs/minui/index.html 预览码： [图片] 第五款： iview-weapp：地址 https://weapp.iviewui.com/docs/guide/start 预览码： [图片] 第六款： WXRUI：暂无地址 预览码： [图片] 第七款： WuxUI：地址https://www.wuxui.com/#/introduce 预览码： [图片] 第八款： WussUI：地址 https://phonycode.github.io/wuss-weapp/quickstart.html 预览码： [图片] 第九款： TouchUI：地址 https://github.com/uileader/touchwx 预览码: [图片] 第十款： Hello UniApp： 地址 https://m3w.cn/uniapp 预览码： [图片] 第十一款： TaroUI：地址 https://taro-ui.jd.com/#/docs/introduction 预览码： [图片] 第十二款： Thor UI： 地址 https://thorui.cn/doc/ 预览码： [图片] 第十三款： GUI：https://github.com/Gensp/GUI 预览码： [图片] 第十四款： QyUI：暂无地址 预览码： [图片] 第十五款： WxaUI：暂无地址 预览码： [图片] 第十六款： kaiUI： github地址 https://github.com/Chaunjie/kai-ui 组件库文档：https://chaunjie.github.io/kui/dist/#/start 预览码： [图片] 第十七款： YsUI：暂无地址 预览码： [图片] 第十八款： BeeUI：git地址 http://ued.local.17173.com/gitlab/wxc/beeui.git 预览码： [图片] 第十九款： AntUI： 暂无地址 预览码： [图片] 第二十款： BleuUI：暂无地址 预览码： [图片] 第二十一款： uniydUI：暂无地址 预览码： [图片] 第二十二款： RovingUI：暂无地址 预览码： [图片] 第二十三款： DojayUI：暂无地址 预览码： [图片] 第二十四款： SkyUI：暂无地址 预览码： [图片] 第二十五款： YuUI：暂无地址 预览码： [图片] 第二十六款： wePyUI：暂无地址 预览码： [图片] 第二十七款： WXDUI：暂无地址 预览码： [图片] 第二十八款： XviewUI：暂无地址 预览码： [图片] 第二十九款： MinaUI：暂无地址 预览码： [图片] 第三十款： InyUI：暂无地址 预览码： [图片] 第三十一款： easyUI：地址 https://github.com/qq865738120/easyUI 预览码: [图片] 第三十二款 Kbone-UI： 地址 https://wechat-miniprogram.github.io/kboneui/ui/#/ 暂无预览码 第三十三款 VtuUi： 地址 https://github.com/jisida/VtuWeapp 预览码： [图片] 第三十四款 Lin-UI 地址：http://doc.mini.talelin.com/ 预览码： [图片] 第三十五款 GraceUI 地址： http://grace.hcoder.net/ 这个是收费的哦～ 预览码： [图片] 第三十六款 anna-remax-ui npm：https://www.npmjs.com/package/anna-remax-ui/v/1.0.12 anna-remax-ui 地址： https://annasearl.github.io/anna-remax-ui/components/general/button 预览码 [图片] 第三十七款 Olympus UI 地址：暂无 网易严选出品。 预览码 [图片] 第三十八款 AiYunXiaoUI 地址暂无 预览码 [图片] 第三十九款 visionUI npm：https://www.npmjs.com/package/vision-ui 预览码： [图片] 第四十款 AnimaUI(灵动UI) 地址：https://github.com/AnimaUI/wechat-miniprogram 预览码： [图片] 第四十一款 uView 地址：http://uviewui.com/components/quickstart.html 预览码： [图片] 第四十二款 firstUI 地址：https://www.firstui.cn/ 预览码： [图片]

#1 在网页制作中，我们经常需要根据业务需求在网页中不同位置展示滚动消息。 比如，新下单用户、抢购、秒杀等。 在网页中制作滚动消息有很多种实现方式，那么在小程序里面我们可以复用这些方式吗？ 答案是：可以的，但没必要。 为什么呢？ 因为网页中制作滚动消息效果都会用到JS， 而在小程序中我们可以直接使用原生组件 swiper 来实现滚动消息效果。 #2 在开始制作之前，我们先说说为什么不用JS？ 不用JS来实现主要是两个原因：   1、性能的原因，虽然小程序已为我们优化了很多，但总归是有一些损耗的。   2、JS 实现滚动消息效果要多写一些代码 （嘿嘿嘿） 上面讲了为什么不用JS而用 swiper，那接下来就讲讲 swiper 实现滚动消息效果的思路 其实非常简单，同样只需要两点就可以：   1、把 swiper 滚动方向改为垂直（如果你要实现的是左右方向的滚动消息，这一点都可省略）   2、在 swiper-item 上面盖一层 view 遮挡一下，避免用户手动去滚动消息。 #3 思路理好了，我们先画一下 view 之间的关系 [图片] 首先容器 view，来存放滚动消息遮罩层。 不要这个容器可以吗？ 答案是：可以的，但很麻烦。因为遮罩层需要用绝对定位来覆盖在滚动消息层上面，没有容器作为父级 view。遮罩层会出现期望外的效果。 然后是滚动消息层，也就是本文主角 swiper 组件。可以根据业务需要改变滚动方向、时间间隔、样式等。 最后就是遮罩层，主要是防止用户误点而触发 swiper。 #4 总算到了代码环节，开始之前我们先看看效果 [图片] 首先是 wxml  [图片] 然后是 wxss [图片] 最后是模拟数据  [图片] #5 到这里，在小程序中实现滚动消息就结束了。文中源码关注公众号回复 滚动消息 下载。如果你有其他疑问或者需求加我微信(qwertyax)一起交流 [图片]

中秋快乐，帮社区里的小伙伴写的选图效果，仿造的微信朋友圈选图，长按拖动排序主要是用交互监听来实现的。还有几个需要处理的地方。另外在真机上的动画速度总感觉快那么一丢丢。没做预览图，详情见代码片段咯。安卓机效果没试过。。 今天是9月23，这两天接受定制改动~ 第一次发经验分享。。轻点喷。。 哦，对了，这里 wx.createSelectorQuery 有个bug。。如果选择的基础库版本在2.0.9以上，第一次打开开发者工具，要先直接点一次编译，不然会出错。。真机上没问题 代码片段：wechatide://minicode/RFLmzDmL7I2a 有小伙伴反馈，在片段上面增加内容会乱位，是因为没计算顶部偏移量，方便懒人，完善了下 新的片段：wechatide://minicode/fOTEM3mI7l3B 终于拿到安卓机器试了，果然卡得很。。要控制频率。这很尴尬，太频繁的话，安卓会卡，太不频繁呢，刚开始移动那阵子会卡。。有同学反馈，说点快了会出问题，于是又加了点击频率的限制 现在的代码片段：wechatide://minicode/xBDdCom17R3c（要重新拿安卓机测试了再看看。。） 附上gif： [图片]

由于我们无法将小程序直接分享到朋友圈，但分享到朋友圈的需求又很多，业界目前的做法是利用小程序的 Canvas 功能生成一张带有小程序码的图片，然后引导用户下载图片到本地后再分享到朋友圈。相信大家在绘制分享图中应该踩到 Canvas 的各种（坑）彩dan了吧～ 这里首先推荐一个开源的组件：painter（通过该组件目前我们已经成功在支付宝小程序上也应用上了分享图功能） 咱们不多说，直接上手就是干。 [图片] 首先我们新增一个自定义组件，在该组件的json中引入painter [代码]{ "component": true, "usingComponents": { "painter": "/painter/painter" } } [代码] 然后组件的WXML (代码片段在最后) [代码]// 将该组件定位在屏幕之外，用户查看不到。 <painter style="position: absolute; top: -9999rpx;" palette="{{imgDraw}}" bind:imgOK="onImgOK" /> [代码] 重点来了 JS (代码片段在最后) [代码]Component({ properties: { // 是否开始绘图 isCanDraw: { type: Boolean, value: false, observer(newVal) { newVal && this.handleStartDrawImg() } }, // 用户头像昵称信息 userInfo: { type: Object, value: { avatarUrl: '', nickName: '' } } }, data: { imgDraw: {}, // 绘制图片的大对象 sharePath: '' // 生成的分享图 }, methods: { handleStartDrawImg() { wx.showLoading({ title: '生成中' }) this.setData({ imgDraw: { width: '750rpx', height: '1334rpx', background: 'https://qiniu-image.qtshe.com/20190506share-bg.png', views: [ { type: 'image', url: 'https://qiniu-image.qtshe.com/1560248372315_467.jpg', css: { top: '32rpx', left: '30rpx', right: '32rpx', width: '688rpx', height: '420rpx', borderRadius: '16rpx' }, }, { type: 'image', url: this.data.userInfo.avatarUrl || 'https://qiniu-image.qtshe.com/default-avatar20170707.png', css: { top: '404rpx', left: '328rpx', width: '96rpx', height: '96rpx', borderWidth: '6rpx', borderColor: '#FFF', borderRadius: '96rpx' } }, { type: 'text', text: this.data.userInfo.nickName || '青团子', css: { top: '532rpx', fontSize: '28rpx', left: '375rpx', align: 'center', color: '#3c3c3c' } }, { type: 'text', text: `邀请您参与助力活动`, css: { top: '576rpx', left: '375rpx', align: 'center', fontSize: '28rpx', color: '#3c3c3c' } }, { type: 'text', text: `宇宙最萌蓝牙耳机测评员`, css: { top: '644rpx', left: '375rpx', maxLines: 1, align: 'center', fontWeight: 'bold', fontSize: '44rpx', color: '#3c3c3c' } }, { type: 'image', url: 'https://qiniu-image.qtshe.com/20190605index.jpg', css: { top: '834rpx', left: '470rpx', width: '200rpx', height: '200rpx' } } ] } }) }, onImgErr(e) { wx.hideLoading() wx.showToast({ title: '生成分享图失败，请刷新页面重试' }) //通知外部绘制完成，重置isCanDraw为false this.triggerEvent('initData') }, onImgOK(e) { wx.hideLoading() // 展示分享图 wx.showShareImageMenu({ path: e.detail.path, fail: err => { console.log(err) } }) //通知外部绘制完成，重置isCanDraw为false this.triggerEvent('initData') } } }) [代码] 那么我们该如何引用呢？ 首先json里引用我们封装好的组件share-box [代码]{ "usingComponents": { "share-box": "/components/shareBox/index" } } [代码] 以下示例为获取用户头像昵称后再生成图。 [代码]<button class="intro" bindtap="getUserInfo">点我生成分享图</button> <share-box isCanDraw="{{isCanDraw}}" userInfo="{{userInfo}}" bind:initData="handleClose" /> [代码] 调用的地方： [代码]const app = getApp() Page({ data: { isCanDraw: false }, // 组件内部关掉或者绘制完成需重置状态 handleClose() { this.setData({ isCanDraw: !this.data.isCanDraw }) }, getUserInfo(e) { wx.getUserProfile({ desc: "获取您的头像昵称信息", success: res => { const { userInfo = {} } = res this.setData({ userInfo, isCanDraw: true // 开始绘制海报图 }) }, fail: err => { console.log(err) } }) } }) [代码] 最后绘制分享图的自定义组件就完成啦~效果图如下： [图片] tips： 文字居中实现可以看下代码片段 文字换行实现（maxLines）只需要设置宽度，maxLines如果设置为1，那么超出一行将会展示为省略号 代码片段：https://developers.weixin.qq.com/s/J38pKsmK7Qw5 附上painter可视化编辑代码工具：点我直达，因为涉及网络图片，代码片段设置不了downloadFile合法域名，建议真机开启调试模式，开发者工具 详情里开启不校验合法域名进行代码片段的运行查看。 最后看下面大家评论问的较多的问题：downLoadFile合法域名在小程序后台 开发>开发设置里配置，域名为你图片的域名前缀 比如我文章里的图https://qiniu-image.qtshe.com/20190605index.jpg。配置域名时填写https://qiniu-image.qtshe.com即可。如果你图片cdn地址为https://aaa.com/xxx.png, 那你就配置https://aaa.com即可。

本月份的组件分享，事件效果由 wxs事件完成，注释在代码片段里有。 按钮可拖动，子菜单上没有点击事件，是根据touchend位置来判断点击的谁。有bug欢迎反馈 代码片段：https://developers.weixin.qq.com/s/9BNYnhmG7tcl 社区这会儿效果图gif上传不了。。不是我的错 图标iconfont下的，没版权问题吧。。

1.背景 如今信息流业务是各大互联网公司争先抢占的一个大面包，为了提高用户的后续消费，产品想出了各种各样的方法，例如在微视中，用户可以无限上拉出下一条视频；在知乎中，也可以无限上拉出下一条回答。这样的操作方式用户体验更好，后续消费也更多。最近几年的时间，微信小程序已经从一颗小小的萌芽成长为参天大树，形成了较大规模的生态，小程序也拥有了一个很大的流量入口。 2.demo体验 那如何才能在小程序中实现类原生APP效果的下一条无限刷体验？ 这篇文章详细记录了下一条无限刷效果的实现原理，以及细节和体验优化，并将相关代码抽象成一个微信小程序代码片段，有需要的同学可查看demo源码。 线上效果请用微信扫码体验： [图片] 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a 3.实现原理 出于性能和兼容性考虑，我们尽量采用小程序官方提供的原生组件来实现下一条无限刷效果。我们发现，可以将无限上拉下一篇的文章看作一个竖向滚动的轮播图，又由于每一篇文章的内容长度高于一屏幕高度，所以需要实现文章内部可滚动，以及文章之间可以上拉和下拉切换的功能。 在多次尝试后，我们最终采用了在[代码]<swiper>[代码]组件内部嵌套一个[代码]<scroll-view>[代码]组件的方式实现，利用[代码]<swiper>[代码]组件来实现文章之间上拉和下拉切换的功能，利用[代码]<scroll-view>[代码]来实现一篇文章内部可上下滚动的功能。 所以页面的dom结构如下所示： [代码]<swiper class='scroll-swiper' circular="{{false}}" vertical="{{true}}" bindchange="bindChange" skip-hidden-item-layout="{{true}}" duration="{{500}}" easing-function="easeInCubic" > <block wx:for="{{articleData}}"> <swiper-item> <scroll-view scroll-top="0" scroll-with-animation="{{false}}" scroll-y > content </scroll-view> </swiper-item> </block> </swiper> [代码] 4.性能优化 我们知道view部分是运行在webview上的，所以前端领域的大多数优化方式都有用。例如减少代码包体积，使用分包，渲染性能优化等。下面主要讲一下渲染性能优化。 4.1 dom优化 由于页面需要无限上拉刷新，所以要在[代码]<swiper>[代码]组件中不断的增加[代码]<swiper-item>[代码]，这样必然会导致页面的dom节点成倍数的增加，最后非常卡顿。 为了优化页面的dom节点，我们利用[代码]<swiper>[代码]的[代码]current[代码]和[代码]<swiper-item>[代码]的[代码]index[代码]来做优化，控制是否渲染dom节点。首先，仅当[代码]index <= current + 1[代码]时渲染[代码]<swiper-item>[代码]，也就是页面中最多预先加载出下一条，而不是将接口返回的所有后续数据都渲染出来；其次，对于用户已经消费过的之前的[代码]<swiper-item>[代码]，不能直接销毁dom节点，否则会导致[代码]<swiper>[代码]的[代码]current[代码]值出现错乱，但是我们可以控制是否渲染[代码]<swiper-item>[代码]内部的子节点，我们设置了仅当[代码]current <= index + 1 && index -1 <= current[代码]时才会渲染[代码]<swiper-item>[代码]中的内容，也就是仅渲染当先文章，及上一篇和下一篇的文章内容，其他文章的dom节点都被销毁了。 这样，无论用户上拉刷新了多少次，页面中最多只会渲染3篇文章的内容，避免了因为上拉次数太多导致的页面卡顿。 4.2 分页时setData的优化 setData工作原理 [图片] 小程序的视图层目前使用[代码]WebView[代码]作为渲染载体，而逻辑层是由独立的 [代码]JavascriptCore[代码] 作为运行环境。在架构上，[代码]WebView[代码] 和 [代码]JavascriptCore[代码] 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 [代码]evaluateJavascript[代码] 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 [代码]JS[代码] 脚本，再通过执行 [代码]JS[代码] 脚本的形式传递到两边独立环境。 而 [代码]evaluateJavascript[代码] 的执行会受很多方面的影响，数据到达视图层并不是实时的。 每次 [代码]setData[代码] 的调用都是一次进程间通信过程，通信开销与 setData 的数据量正相关。 [代码]setData[代码] 会引发视图层页面内容的更新，这一耗时操作一定时间中会阻塞用户交互。 [代码]setData[代码] 是小程序开发中使用最频繁的接口，也是最容易引发性能问题的接口。 避免不当使用setData [代码]data[代码] 应仅包括与页面渲染相关的数据，其他数据可绑定在this上。使用 [代码]data[代码] 在方法间共享数据，会增加 setData 传输的数据量，。 使用 [代码]setData[代码] 传输大量数据，通讯耗时与数据正相关，页面更新延迟可能造成页面更新开销增加。仅传输页面中发生变化的数据，使用 [代码]setData[代码] 的特殊 [代码]key[代码] 实现局部更新。 避免不必要的 [代码]setData[代码]，避免短时间内频繁调用 [代码]setData[代码]，对连续的setData调用进行合并。不然会导致操作卡顿，交互延迟，阻塞通信，页面渲染延迟。 避免在后台页面进行 [代码]setData[代码]，这样会抢占前台页面的渲染资源。可将页面切入后台后的[代码]setData[代码]调用延迟到页面重新展示时执行。 优化示例 无限上拉刷新的数据会采用分页接口的形式，分多次请求回来。在使用分页接口拉取到下一刷的数据后，我们需要调用[代码]setData[代码]将数据写进[代码]data[代码]的[代码]articleData[代码]中，这个[代码]articleData[代码]是一个数组，里面存放着所有的文章数据，数据量十分庞大，如果直接[代码]setData[代码]会增加通讯耗时和页面更新开销，导致操作卡顿，交互延迟。 为了避免这个问题，我们将[代码]articleData[代码]改进为一个二维数组，每一次[代码]setData[代码]通过分页的 [代码]cachedCount[代码]标识来实现局部更新，具体代码如下： [代码]this.setData({ [`articleData[${cachedCount}]`]: [...data], cachedCount: cachedCount + 1, }) [代码] [代码]articleData[代码]的结构如下： [图片] 4.3 体验优化 解决了操作卡顿，交互延迟等问题，我们还需要对动画和交互的体验进行优化，以达到类原生APP效果的体验。 在文章间上拉切换时，我们使用了[代码]<swiper>[代码]组件自带的动画效果，并通过设置[代码]duration[代码]和[代码]easing-function[代码]来优化滚动细节和动画。 当用户阅读文章到底部时，会提示下一篇文章的标题等信息，而在页面上拉时，由于下一篇文章的内容已经加载出来了，这样在滑动过程中会出现两个重复的标题。为了避免这种情况出现，我们通过一个占满屏幕宽高的空白[代码]<view>[代码]来将下一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]hidden="{{index !== current && index !== current + 1}}"[代码]来隐藏这个空白[代码]<view>[代码]，并对这个空白[代码]<view>[代码]的高度变化增加动画，来实现下一篇文章从屏幕底部滚动到屏幕顶部的效果： [代码].fake-scroll { height: 100%; width: 100%; transition: height 0.3s cubic-bezier(0.167,0.167,0.4,1); } [代码] [图片] 而当用户想要上拉查看之前阅读过的文章时，我们需要给用户一个“下滑查看上一条”提示，所以也可以采用同上的方式，通过一个占满屏幕宽高的提示语[代码]<view>[代码]来将上一篇文章的内容撑出屏幕，并在滚动结束时，通过[代码]wx:if="{{index + 1 === current}}"[代码]来隐藏这个提示语[代码]<view>[代码]，并对这个提示语[代码]<view>[代码]的透明度变化增加动画，来实现下拉时提示“下滑查看上一条”的效果： [代码].fake-previous { height: 100%; width: 100%; opacity: 0; transition: opacity 1s ease-in; } .fake-previous.show-fake-previous { opacity: 1; } [代码] 至此，这个类原生APP效果的下一条无限刷体验的需求的所有要点和细节都已实现。 记录在此，欢迎交流和讨论。 小程序demo体验请点击：https://developers.weixin.qq.com/s/vIfPUomP7f9a

下滑刷新，请求数据成功。数据更新成功，但是页面在手机上出现白屏现象，手机模拟器视图不更新，数据条数大概在380条左右，可能是什么问题的了？？？？

自定义navigate+分包+自定义tabbar，有需要的可以拿去用用，可能会存在一些问题，根据自己的业务改改吧 大家也可以多多交流 代码片段：在这里 {"version":"1.1.5","update":[{"title":"修复 [复制代码片段提示] 无法使用的问题","date":"2020-06-15 09:20","imgs":[]}]} 更新日志:     2019-11-25  自定义navigate 也可以调用wx.showNavigationBarLoading 和 wx.hideNavigationBarLoading     2019-11-25  页面滚动条显示在自定义navigate 和 自定义tabbar上面的问题(点击“体验custom Tabbar” [图片] [图片] 其他demo: 云开发之微信支付：代码片段

开发工具和iOS测过，android我没测过。。哈哈哈哈哈 https://developers.weixin.qq.com/s/kh8HhjmA7A4D 注释不知道写啥，简单描述了下 [图片]