- 当前 Bug 的表现（可附上截图） https://union-wifi.oss-cn-shanghai.aliyuncs.com/wxminioprogram/dialect/156122pp.mp4； - 预期表现 https://union-wifi.oss-cn-shanghai.aliyuncs.com/wxminioprogram/dialect/156122pp.mp4； - 复现路径 https://union-wifi.oss-cn-shanghai.aliyuncs.com/wxminioprogram/dialect/156122pp.mp4； - 提供一个最简复现 Demo 基础库2.2.4版本起废弃从微信下拉的【我的小程序】进入的场景值1104， 现在微信下拉【我的小程序】与【最近使用】进入小程序的场景值都是1089， 意思不可能区分，官方给个答案，基础库版本可以下调吗？ 基础库是不是跟微信版本有关吧，我微信最新版本应该就高于2.2.4,那么请解释一下，视频里出现的现象：https://union-wifi.oss-cn-shanghai.aliyuncs.com/wxminioprogram/dialect/156122pp.mp4；人家是如何在已有的场景值下，能有如此骚操作，还是你们暴露给人家，特殊的接口让他们可以查询到不一样的场景值。 此帖唯一，别隐藏了。

在微信小程序/小游戏的开发中，网络传输主要是依靠http的短连接和webSocket 长连接来完成的。 在一般web服务中，大多使用短连接来向服务器请求资源，与服务器的交互频率低，次数少。而在一些需要与服务器交互频繁，需要及时收到服务器推送的场景，比如直播、多人实时游戏，更适合使用 webSocket 进行通讯。 这次的小故事主要分享 webSocket 在微信小程序/小游戏开发上的一些经验。 长连的生命周期介绍 webSocket的生命周期一共有4个状态：connecting、open、closing、closed。我们可以通过 socketTask 的 readyState 属性来获取当前 webSocket 长连的状态。webSocket 的生命周期过程和 API 间的调用关系可以简单的入下图所示。 [图片] 注意：只有长连处在 open 状态，才能够正常的收发消息，其他状态均会报错。 客户端长连的断开机制 当小游戏进入到后台运行超过5秒时，客户端会禁止小游戏的所有网络连接。这是一个非常频繁的断线逻辑，十分考验程序断线错误处理逻辑。建议大家可以在用户点击右上角按钮退出小程序/小游戏时，主动帮用户断线，待用户切回时再重接上去。   当 webSocket 长连超过一段时间没有任何网络传输时，客户端会主动关闭这条长连，以节省资源。开发者可以设置业务心跳，每隔一段时间与后台进行一次通讯，维持长连。 如何选择长连的接口 API接口主要有两类，一类是前缀为 “wx” 的接口，一类 “socketTask” 的接口。举例，同样是连接长连后发送一条消息，两种写法区别如下。 [图片] 最初小游戏只允许存在1个 webSocket 连接时，并没开放 socketTask 的管理方式。随着小游戏的能力提升，可支持同时存在的 webSocket 连接个数变多，在使用 wx.connectSocket 创建 webSocket 连接时会返回 socketTask 任务对象，便于去管理每一条连接链路。   推荐开发者尽量使用 socketTask 的方式去管理 webSocket 链接，每一条链路的生命周期都更加可控。同时存在多个 webSocket 的链接的情况下使用 wx 前缀的方法可能会带来一些和预期不一致的情况。例如：当存在多条连接时，wx.onSocketOpen、wx.sendSocketMessage、wx.onSocketMessage 等接口会只作用于第一条连接的长连。且wx.onSocketOpen 接口不能多次注册 webSocket 长连的回调函数，仅最后一次生效。使用 socketTask 任务的方式则不会出现上述问题。 开发与调试的建议 01微信提供了 webSocket 最基础的接口能力，开发者可以在其基础上进行封装，根据业务需要扩展能力。比如封装一个 offSocketOpen 的方法来取消注册 socketOpen 的回调函数。 02 长连并没有像短连那样“一问一答”的交互形式。在某些场景下，开发者需要这种与服务器的交互。建议前端与后台协议，每条客户端上行的信息，服务器都下发一个对应的回包，去“模拟短连”。比如开发者向服务器询问1+1和1+2等于多少，服务器返回了3和2，便可清晰知道哪一个数字对应着哪一个请求的答案。此外，还可以设置业务超时逻辑，便于判断上传是否丢包 03 在 webSocket 发送数据时，数据格式可以选择string或者ArrayBuffer。这里要注意的是，由于小游戏禁止了 Function() 和 eval()语法。所以像 protobufjs 这类用了这些语法的库是不能直接拿来用的。 04 在测试调试长连的时，目前开发者工具不支持通过设置 offline 模拟长连断网的情况（短连是支持的），所以在测试断线重连的一些情况时，可以辅助一些第三方工具，或者用真机调试以及“拔网线”的方式来测试。 05 在进行多人游戏测试时，在开发者工具中熟练使用“自定义编译条件”，以及“多账号调试”这两个功能可以极大的提升开发测试效率。 06 长连占用的系统资源，会导致手机发热比较明显。所以在不需要使用 webSocket 的场景下，建议及早断开长连，需要时再连接。 异常断线的监控 监控长连是否异常断线，在长连的使用中，尤其在小游戏多人对战中是尤为重要的。socketError 事件并不能认为是异常断线。 首先 socketError 事件并不一定会导致断线，其次若是由客户端机制断开的长连，是不会触发 socketError 事件的。   最简单的方式可以通过 onClose 回调函数触发时系统传入的 code 是否为1000来判断。当然开发者自身也可以通过代码判断是否是自身调用的 close 函数触发的 onclose 事件，监控异常断线。 希望大家在实际应用中能帮助到到大家。

在「小程序 · 小故事」的第一期，我们曾和大家一起分享过「分包加载」的故事。随着小程序功能越来越多样，页面也越来越多，但不同页面的访问频率是有一定差异的。 分包加载允许开发者将小程序划分为主包和若干个分包，将较少用到的页面或功能划分到若干个分包中，主包内只保留最频繁使用的页面和公共的代码。小程序启动时默认只加载主包，再按需加载分包。这一机制保证了在小程序包大小增加的情况下，依然能保持良好的启动速度。 为满足小程序承载的功能不断丰富的需要，小程序的代码包大小上限已提高到 8M。随着小程序应用场景和使用范围的扩大，在实践中，我们发现分包加载仍有一定的局限性。尤其是越来越多的 H5 服务迁移到小程序后，对于小程序的启动速度有更高要求。为了更好的提升小程序的加载速度和使用体验，小程序近期开放了「独立分包」和「分包预下载」两个新的能力，进一步丰富了分包加载的功能和使用场景。 01独立分包 1  技术背景 由于技术实现的差异，小程序首次启动时需要进行代码包的下载，因此在启动性能上与网页相比有一定劣势。通过对小程序启动耗时的分析，我们发现代码包大小对小程序启动速度是有最直接的影响。 一方面，代码包越大，下载时间就越长； 另一方面，代码包越大，通常意味着小程序页面结构和代码逻辑复杂，启动时代码注入执行的时间越长。 采用分包加载一定程度上解决了代码包下载耗时过长的问题。但小程序中的某些场景（如广告页、活动页、支付页等），通常功能不是很复杂且相对独立，对启动性能有很高的要求。在现有方案中，启动这一页面需要依赖整个主包的下载，如果页面在分包中，还需等待分包的下载，启动性能有严重的瓶颈。此时如果依赖开发者进行代码重构，重新分包，不仅工作量大，而且会影响其他分包的使用体验。为了解决这一问题，我们提出了「独立分包」方案。 2  功能简介 独立分包是小程序中一种特殊类型的分包，可以独立于主包和其他分包运行。从独立分包中页面进入小程序时，不需要下载主包。当用户进入普通分包或主包内页面时，主包才会被下载。 开发者可以将部分对启动性能要求很高的页面放到特殊的独立分包中。当小程序从独立分包页面启动时，只需要下载分包就可以直接运行，可以很大程度上提高分包页面的启动速度，实现小程序的秒开。 [图片] 由于小游戏中没有页面的概念，也没有小程序中多种入口的使用场景，因此小游戏目前没有支持独立分包。 3  配置方法 独立分包的配置方法十分简单，只需要在原有分包配置的基础上定义 independent 字段，即可将一个分包设置为独立分包，例如： [图片] 4  使用限制 独立分包虽然属于分包的一种，但其不依赖主包独立使用，因此在加载流程和运行环境上与普通分包相比有一些差异。除了分包本身的限制外，独立分包还有以下限制： ● 独立分包中不能依赖主包和其他分包中的内容，包括 js 文件、模板、wxss、自定义组件等； ● App 只能在主包内定义，独立分包中不能定义 App，会造成无法预期的行为； ●  独立分包中暂时不支持使用插件。 为了小程序有更好的使用体验，我们不建议开发者把过多的小程序逻辑放置到独立分包中，也不建议在小程序中过度的使用独立分包，例如把每个页面都放到一个独立分包中。 关于独立分包的详细内容请参见 独立分包 · 小程序 02 分包预下载 1  技术背景 在使用「分包加载」后，虽然能够显著提升小程序的启动速度，但是当用户在使用小程序过程中跳转到分包内页面时，需要等待分包下载完成后才能进入页面，造成页面切换的延迟，影响小程序的使用体验。分包预下载便是为了解决首次进入分包页面时的延迟问题而设计的。如果能够在用户进入分包页面之前就预先将分包下载完毕，那么进入分包页面的延迟就能够尽可能降低。 此前，小游戏中已经提供了「基于API」的分包预下载能力。在设计小程序分包预下载能力时，我们设计了「基于配置」和「基于API」两种分包预下载形式，「基于配置」的方式使用简单，且便于对预下载的使用情况进行控制，防止开发者滥用；「基于API」的方式使用起来更灵活，能够动态的调整预下载策略。综合考虑用户的使用感受和内测阶段第三方开发者的反馈后，我们最终决定首先推出「基于配置」的分包预下载能力。 2  功能简介 开发者可以预先配置某个页面可能会跳转到的分包（对于独立分包，也可以预下载主包），在进入小程序某个页面时，由基础库在后台自动预下载可能需要的分包。用户在进行页面跳转时，分包通常已经下载完成，不需要额外等待，可以有效提升进入后续分包页面时的启动速度。此外，考虑到用户的流量和存储空间，小程序也会对预下载的大小和网络进行一定的限制。 [图片] 3  配置方法 开发者可以通过在 app.json 中增加 preloadRule 字段，控制进入某个页面时进行预下载的分包，并设置触发预下载的网络环境。 [图片] [图片] 4  使用限制 对于手机用户而言，数据流量和存储空间是非常重要的资源。一方面，分包预下载能够提升小程序用户的使用体验；另一方面，过度的预下载也会破坏分包按需使用的原则，过度的占用用户的存储空间，消耗数据流量。如果开发者每次启动小程序时都将所有分包进行下载，会消耗很多不必要的流量和存储空间。 为了在分包预下载的效果和对用户资源的消耗上取得平衡，我们限制了同一个分包中的页面预下载总大小不得超过2M，并鼓励开发者按需设置分包预下载的网络条件。 关于独分包预下载详细内容请参见 分包预下载 · 小程序 03 小结 独立分包与分包预下载进一步丰富了分包加载的功能，大大拓展了分包加载的使用场景。同时，独立分包和分包预下载是相辅相成的，配合使用可以获得更好的效果。 例如，开发者可以将一个活动推广页放到一个独立分包中，利用独立分包的特性能够提升活动页面的加载速度，提升转化率。在页面中开发者可以引导有需要的用户跳转到小程序其他页面，使用小程序的更丰富的功能。在这一过程中，可以利用分包预下载能力，将主包或相关分包进行预下载，降低页面跳转的延迟，留住更多用户。 开发者在使用这两个新能力的过程中，如果遇到问题或者有什么建议，欢迎在微信开放社区（https://developers.weixin.qq.com）进行反馈，我们会根据开发者的反馈，不断的优化和丰富分包加载功能，减少功能限制，提升小程序的加载性能和使用体验。

[图片] 海报生成示例 最近智酷君在做[小程序]canvas生成海报的项目中遇到一些棘手的问题，在网上查阅了各种资料，也踩扁了各种坑，智酷君希望把这些“填坑”经验整理一下分享出来，避免后来的兄弟重复“掉坑”。 [图片] 原型图 这是一个大致的原型图，下面来看下如何制作这个海报，以及整体的思路。 [图片] 海报生成流程 [代码片段]Canvas生成海报实战demo demo的微信路径：https://developers.weixin.qq.com/s/Q74OU3m57c9x demo的ID：Q74OU3m57c9x 如果你装了IDE工具，可以直接访问上面的demo路径 通过代码片段将demo的ID输入进去也可添加： [图片] [图片] 下面分享下主要的代码内容和“填坑现场”： 一、添加字体 https://developers.weixin.qq.com/miniprogram/dev/api/canvas/font.html [代码]canvasContext.font = value //示例 ctx.font = `normal bold 20px sans-serif`//设置字体大小，默认10 ctx.setTextAlign('left'); ctx.setTextBaseline("top"); ctx.fillText("《智酷方程式》专注研究和分享前端技术", 50, 15, 250)//绘制文本 [代码] 符合 CSS font 语法的 DOMString 字符串，至少需要提供字体大小和字体族名。默认值为 10px sans-serif 文字过长在canvas下换行问题处理（最多两行，超过“…”代替） [代码]ctx.setTextAlign('left'); ctx.setFillStyle('#000');//文字颜色：默认黑色 ctx.font = `normal bold 18px sans-serif`//设置字体大小，默认10 let canvasTitleArray = canvasTitle.split(""); let firstTitle = ""; //第一行字 let secondTitle = ""; //第二行字 for (let i = 0; i < canvasTitleArray.length; i++) { let element = canvasTitleArray[i]; let firstWidth = ctx.measureText(firstTitle).width; //console.log(ctx.measureText(firstTitle).width); if (firstWidth > 260) { let secondWidth = ctx.measureText(secondTitle).width; //第二行字数超过，变为... if (secondWidth > 260) { secondTitle += "..."; break; } else { secondTitle += element; } } else { firstTitle += element; } } //第一行文字 ctx.fillText(firstTitle, 20, 278, 280)//绘制文本 //第二行问题 if (secondTitle) { ctx.fillText(secondTitle, 20, 300, 280)//绘制文本 } [代码] 通过 ctx.measureText 这个方法可以判断文字的宽度，然后进行切割。 （一行字允许宽度为280时，判断需要写小点，比如260） 二、获取临时地址并设置图片 [代码]let mainImg = "https://demo.com/url.jpg"; wx.getImageInfo({ src: mainImg,//服务器返回的图片地址 success: function (res) { //处理图片纵横比例过大或者过小的问题！！！ let h = res.height; let w = res.width; let setHeight = 280, //默认源图截取的区域 setWidth = 220; //默认源图截取的区域 if (w / h > 1.5) { setHeight = h; setWidth = parseInt(280 / 220 * h); } else if (w / h < 1) { setWidth = w; setHeight = parseInt(220 / 280 * w); } else { setHeight = h; setWidth = w; }; console.log(setWidth, setHeight) ctx.drawImage(res.path, 0, 0, setWidth, setHeight, 20, 50, 280, 220); ctx.draw(true); }, fail: function (res) { //失败回调 } }); [代码] 在开发过程中如果封面图无法按照约定的比例（280x220）给到： 那么我们就需要处理默认封面图过大或者过小的问题，大致思路是：代码中通过比较纵横比（280/220=1.27）正比例放大或者缩小原图，然后从左上切割，竟可能保证过高的图是宽度100%，过宽的图是高度100%。 在canvas中draw图片，必须是一个（相对）本地路径，我们可以通过将图片保存在本地后生成的临时路径。 微信官方提供两个API： wx.downloadFile(OBJECT)和wx.getImageInfo(OBJECT)。都需先配置download域名才能生效。 三、裁切“圆形”头像画图 [代码]ctx.save(); //保存画图板 ctx.beginPath()//开始创建一个路径 ctx.arc(35, 25, 15, 0, 2 * Math.PI, false)//画一个圆形裁剪区域 ctx.clip()//裁剪 ctx.closePath(); ctx.drawImage(headImageLocal, 20, 10, 30, 30); ctx.draw(true); ctx.restore()//恢复之前保存的绘图上下文 [代码] 使用图形上下文的不带参数的clip()方法来实现Canvas的图像裁剪功能。该方法使用路径来对Canvas话不设置一个裁剪区域。因此，必须先创建好路径。创建完整后，调用clip()方法来设置裁剪区域。 需要注意的是裁剪是对画布进行的，裁切后的画布不能恢复到原来的大小，也就是说画布是越切越小的，要想保证最后仍然能在canvas最初定义的大小下绘图需要注意save()和restore()。画布是先裁切完了再进行绘图。并不一定非要是图片，路径也可以放进去~ 小程序 canvas 裁切BUG [代码]ctx.setFillStyle("#fff"); ctx.fillRect(0, 0, 320, 500); //第一个填充矩形 wx.downloadFile({ url: headUri, success(res) { ctx.beginPath() ctx.arc(50, 50, 25, 0, 2 * Math.PI) ctx.clip() ctx.drawImage(res.tempFilePath, 25, 25); //第二个填充图片 ctx.draw() ctx.restore() ctx.setFillStyle("#fff"); ctx.fillRect(0, 0, 320, 500); ctx.draw(true) ctx.restore() } }) [代码] clip裁切这个功能，如果有超过一张图片/背景叠加，则裁切效果失效。 错误参考：http://html51.com/info-38753-1/ 四、将canvas导出成虚拟地址 [代码]wx.canvasToTempFilePath({ fileType: 'jpg', canvasId: 'customCanvas', success: (res) => { console.log(res.tempFilePath) //为canvas的虚拟地址 } }) res： { errMsg: "canvasToTempFilePath:ok", tempFilePath: "http://tmp/wx02935bb29080a7b4.o6zAJswFAuZuKQ5NZfPr….cGnD1a02PlVC0b3284be3a41d08986c2477579a5fd8e.jpg" } [代码] 这里需要把canvas里面的内容，导出成一个临时地址才能保存在相册，比如： http://tmp/wx02935bb29080a7b4.o6zAJswFAuZuKQ5NZfPr5UfJVR4k.cGnD1a02PlVC0b3284be3a41d08986c2477579a5fd8e.jpg 五、询问并获取访问手机本地相册权限 [代码]wx.getSetting({ success(res) { console.log(res) if (!res.authSetting['scope.writePhotosAlbum']) { //判断权限 wx.authorize({ //获取权限 scope: 'scope.writePhotosAlbum', success() { console.log('授权成功') //转化路径 self.saveImg(); } }) } else { self.saveImg(); } } }) [代码] 判断是否有访问相册的权限，如果没有，则请求权限。 六、保存到用户手机本地相册 [代码]wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, success: function (data) { wx.showToast({ title: '保存到系统相册成功', icon: 'success', duration: 2000 }) }, fail: function (err) { console.log(err); if (err.errMsg === "saveImageToPhotosAlbum:fail auth deny") { console.log("当初用户拒绝，再次发起授权") wx.openSetting({ success(settingdata) { console.log(settingdata) if (settingdata.authSetting['scope.writePhotosAlbum']) { console.log('获取权限成功，给出再次点击图片保存到相册的提示。') } else { console.log('获取权限失败，给出不给权限就无法正常使用的提示') } } }) } else { wx.showToast({ title: '保存失败', icon: 'none' }); } }, complete(res) { console.log(res); } }) [代码] 保存到本地需要一定的时间，需要加一个loading的状态。 七、关于组件中引用canvas [代码]let ctx = wx.createCanvasContext('posterCanvas',this); //需要加this [代码] 在components中canvas无法选中的问题： 在components自定义组件下，当前组件实例的this，表示在这个自定义组件下查找拥有 canvas-id 的 <canvas> ，如果省略则不在任何自定义组件内查找。

[图片] 海报生成速度缓慢问题的优化 微信头像在app.js中预先加载缓存 多图片异步加载 流程中断处理 二次授权失败的处理 请求或者下载图片失败处理 保存图片可被压缩 海报生成速度缓慢问题的优化 原因分析： 主要的时间消耗在于getImageInfo网络请求获取头像和下载图片获得临时地址的过程，可以看到海报中有3张图片（微信头像、主图、动态二维码（对应不同新闻的ID））需要下载，接下来主要就是对这3张图的优化 微信头像在app.js中预先加载缓存 [代码]//app.js //可以在app.js中使用小程序默认的全局变量，将头像在加载的时候预先缓存 App({ onLaunch: function () { // 获取用户信息 wx.getSetting({ success: res => { if (res.authSetting['scope.userInfo']) { // 已经授权，可以直接调用 getUserInfo 获取头像昵称，不会弹框 wx.getUserInfo({ success: res => { this.globalData.userInfo = res.userInfo; //从返回值中获取微信头像地址 let WxHeader = res.userInfo.avatarUrl; wx.getImageInfo({ src: WxHeader,//下载微信头像获得临时地址 success: res => { //将头像缓存在全局变量里 this.globalData.avatarUrlTempPath = res.path; }, fail: res => { //失败回调 } }); } }) } } }) }, globalData: { userInfo: null, //如果用户没有授权，无法在加载小程序的时候获取头像，就使用默认头像 avatarUrlTempPath: "./images/defaultHeader.jpg" } }) [代码] 大致思路是： 加载App.js的时候 ==> getSetting(判断是否授权) ==> getUserInfo（获取头像） ==> getImageInfo（生成临时地址） 将需要的网络请求在加载小程序的时候就异步完成，提前将临时地址缓存在全局变量globalData中，这样当用户进入新闻页面，点击生成海报的时候就不需要在请求微信头像，缩短了不少时间。 注意： 如果用户一开始没有微信授权，生成海报时又必须要用户头像不能使用默认的话，那就只能老老实实走之前的流程了。 多图片异步加载 [代码]let num = 0; //下载图片计数器，假设一共三张图片 //下载图片1 wx.getImageInfo({ src: image_1, success: function (res) { //判断是否是最后一张图 if (num >= 2) { console.log("图片全部下载完毕，可以绘制海报") } else { //如果不是最后一张图则+1，继续 num++; } }, fail: function (res) { //失败回调 } }); //下载图片2 wx.getImageInfo({ src: image_2, success: function (res) { //判断是否是最后一张图 if (num >= 2) { console.log("图片全部下载完毕，可以绘制海报") } else { //如果不是最后一张图则+1，继续 num++; } } }); ...... [代码] 这里智库君一开始是使用promise的同步办法，但是发现3张图片阻塞严重，如果一张图片下载过慢，就会影响整个海报生成时间，所以可以改为添加计数器判断的异步方法。 当海报生成需要多张图片的时候，完全可以异步的方式加载他们，通过计数器判断是否是最后一张。 流程中断处理 [图片] 从图中可以看出，整个海报生成过程有二次授权：用户信息授权获取头像和保存相册授权，非常可能因为用户的误点或者拒绝而导致流程中断。 主要分为二种情况： 需要的图片没有拿到，我们可以采取使用默认图片的方式替代。 保存相册授权被拒绝，我们可以提示用户“截图保存”，由于当前版本6.7.2+的**wx.openSetting()**被限制（无法直接被调用），如果必须要相册权限，我们可以通过showModal触发。 API/组件名称 终端类型 微信版本 触发方法 openSetting 6.7.2 2.3.0 showModal [代码]// 关于 openSetting 的调用方法 wx.showModal({ title: '相册权限', content: '需要你提供保存相册权限', success: function (res) { if (res.confirm) { wx.openSetting({ success(settingdata) { console.log(settingdata) if (settingdata.authSetting['scope.writePhotosAlbum']) { console.log('获取 相册 权限成功，给出再次点击图片保存到相册的提示。'); } else { console.log('获取 相册 权限失败，给出不给权限就无法正常使用的提示') } } }) } } }) //获取相册权限的流程处理 wx.saveImageToPhotosAlbum({ filePath: res.tempFilePath, //canvasToTempFilePath API生成的临时地址 success: function (data) { console.log("提示图片保存成功"); }, fail: function (err) { console.log(err); if (err.errMsg === "saveImageToPhotosAlbum:fail auth deny") { console.log("当初用户拒绝，再次发起授权") //调用上面说到的方法 wx.openSetting } else { console.log("提示：请截屏保存分享"); } }, complete(res) { console.log(res); } }) [代码] [图片] 保存图片可被压缩 小程序官方提供了一个API可以设置用户保存图片的质量，仅针对JPG。目前不完全确定：压缩会不会导致额外的性能开销而延长保存时间，自己测试下来 100%、80%、60% 保存时间上没有明显区别。 属性 默认值 说明 最低版本 quality 1.0 图片的质量，取值范围为 (0, 1] 1.7.0 [代码]wx.canvasToTempFilePath({ fileType: 'jpg', canvasId: 'canvasId', quality:0.8, //设置JPG保存质量 80% success: res => { }, fail:res => { } }, this) [代码] 官方文档地址： https://developers.weixin.qq.com/miniprogram/dev/api/wx.canvasToTempFilePath.html?search-key=canvasToTempFilePath [图片] [代码片段]Canvas生成海报实战demo demo的微信路径：https://developers.weixin.qq.com/s/Q74OU3m57c9x demo的ID：Q74OU3m57c9x 如果你装了IDE工具，可以直接访问上面的demo路径 通过代码片段将demo的ID输入进去也可添加： [图片] [图片] 如果智酷君的分享能够帮助到你，或者想持续获得最新的全栈攻略 可以搜索公众号 Geek_Club 或者 智酷方程式 扫描二维码关注公众号哟👇👇👇 [图片]

一、悬案 某日某晚 8 时许，一阵急促的报警电话响彻有赞分销员技术团队的工位，小虎同学，小峰同学纷纷打开监控平台一探究竟。分销员系统某核心应用，接口响应全部超时，dubbo 线程池被全部占满，并堆积了大量待处理任务，整个应用无法响应任何外部请求，处于“夯死”的状态。 [图片] 正当虎峰两位同学焦急的以各种姿势查看应用的各项指标时，5分钟过去了，应用居然自己自动恢复了。看似虚惊一场，但果真如此吗？ 二、勘查线索 2.1 QPS “是不是又有商家没有备案就搞活动了啊”，小虎同学如此说道。的确，对于应用突然夯死，大家可能第一时间想到的就是流量突增。流量突增会给应用稳定性带来不小冲击，机器资源的消耗的增加至殆尽，就像我们去自助餐厅胡吃海喝到最后一口水都喝不下，当然也就响应不了新的请求。我们查看了 QPS 的状况。 [图片] 事实让人失望，应用的 QPS 指标并没有出现陡峰，处于一个相对平缓的上下浮动的状态，小虎同学不禁一口叹气，看来不是流量突增导致的. 2.2 GC “是不是 GC 出问题了”，框架组一位资深的同学说道。JVM 在 GC 时，会因为 Stop The World 的出现，导致整个应用产生短暂的停顿时间。如果 JVM 频繁的发生 Stop The World，或者停顿时间较长，会一定程度的影响应用处理请求的能力。但是我们查看了 GC 日志，并没有任何的异常，看来也不是 GC 异常导致的。 [图片] 2.3 慢查 “是不是有慢查导致整个应用拖慢？”，DBA 同学提出了自己的看法。当应用的高 QPS 接口出现慢查时，会导致处理请求的线程池中（dubbo 线程池），大量堆积处理慢查的线程，占用线程池资源，使新的请求线程处于线程池队列末端的等待状态，情况恶劣时，请求得不到及时响应，引发超时。但遗憾的是，出问题的时间段，并未发生慢查。 2.4 TIMEDOUT 问题至此已经扑朔迷离了，但是我们的开发同学并没有放弃。仔细的小峰同学在排查机器日志时，发现了一个异常现象，某个平时不怎么报错的接口，在1秒内被外部调用了 500 多次，此后在那个时间段内，根据 traceid 这 500 多次请求产生了 400 多条错误日志，并且错误日志最长有延后好几分钟的。 [图片] 这是怎么回事呢？这里有两个问题让我们疑惑不解： 1、500 QPS 完全在这个接口承受范围内，压力还不够。 2、为什么产生的错误日志能够被延后好几分钟。 日志中明显的指出，这个 http 请求 Read timed out。http 请求中读超时设置过长的话，最终的效果会和慢查一样，导致线程长时间占用线程池资源（dubbo 线程池），简言之，老的出不去，新的进不来。带着疑问，我们翻到了代码。 [图片] 但是代码中确实是设置了读超时的，那么延后的错误日志是怎么来的呢？我们已经接近真相了吗？ 三、破案 我们不免对这个 RestTemplateBuilder 起了疑心，是这个家伙有什么暗藏的设置嘛？机智的小虎同学，针对这个工具类，将线上的情况回放到本地进行了模拟。我们构建了 500 个线程同时使用这个工具类去请求一个 http 接口，这个 http 接口让每个请求都等待 2 秒后再返回，具体的做法很简单就是 Thread.sleep(2000)，然后观察每次请求的 response 和 rt。 [图片] 我们发现 response 都是正常返回的（没有触发 Read timed out），rt是规律的5个一组并且有 2 秒的递增。看到这里，大家是不是感觉到了什么？对！这里面有队列！通过继续跟踪代码，我们找到了“元凶”。 [图片] 这个工具类默认使用了队列去发起 http 请求，形成了类似 pool 的方式，并且 pool active size 仅有 5。 现在我们来还原下整个案件的经过： 1、500 个并发的请求同时访问了我们应用的某个接口，将 dubbo 线程池迅速占满（dubbo 线程池大小为 200），这个接口内部逻辑需要访问一个内网的 http 接口 2、由于某些不可抗拒因素（运维同学还在辛苦奋战），这个时间段内这个内网的 http 接口全部返回超时 3、这个接口发起 http 请求时，使用队列形成了类似 pool 的方式，并且 pool active size 仅有 5，所以消耗完 500 个请求大约需要 500/52s=200s，这 200s 内应用本身承担着大约 3000QPS 的请求，会有大约 3000200=600000 个任务会进入 dubbo 线程池队列（如悬案中的日志截图）。PS：整个应用当然就凉凉咯。 4、消耗完这 500 个请求后，应用就开始慢慢恢复（恢复的速率与时间可以根据正常 rt 大致算一算，这里就不作展开了）。 四、思考 到这里，大家心里的一块石头已经落地。但回顾整个案件，无非就是我们工作中或者面试中，经常碰到或被问到的一个问题：“对象池是怎么用的呢？线程池是怎么用的呢？队列又是怎么用的呢？它们的核心参数是怎么设置的呢？”。答案是没有标准答案，核心参数的设置，一定需要根据场景来。拿本案举例，本案涉及两个方面： 4.1 发起 http 请求的队列 这个使用队列形成的 pool 的场景是侧重 IO 的操作，IO 操作的一个特性是需要有较长的等待时间，那我们就可以为了提高吞吐量，而适当的调大 pool active size（反正大家就一起等等咯），这和线程池的的 maximum pool size 有着异曲同工之处。那调大至多少合适呢？可以根据这个接口调用情况，平均 QPS 是多少，峰值 QPS 是多少，rt 是多少等等元素，来调出一个合适的值，这一定是一个过程，而不是一次性决定的。那又有同学会问了，我是一个新接口，我不知道历史数据怎么办呢？对于这种情况，如果条件允许的话，使用压测是一个不错的办法。根据改变压测条件，来调试出一个相对靠谱的值，上线后对其观察，再决定是否需要调整。 4.2 dubbo 线程池 在本案中，对于这个线程池的问题有两个，队列长度与拒绝策略。队列长度的问题显而易见，一个应用的负载能力，是可以通过各种手段衡量出来的。就像我们去餐厅吃饭一样，顾客从上桌到下桌的平均时间（rt）是已知的，餐厅一天存储的食物也是已知的（机器资源）。当餐桌满了的时候，新来的客人需要排队，如果不限制队列的长度，一个餐厅外面排上个几万人，队列末尾的老哥好不容易轮到了他，但他已经饿死了或者餐厅已经没吃的了。这个时候，我们就需要学会拒绝。可以告诉新来的客人，你们今天晚上是排不上的，去别家吧。也可以把那些吃完了，但是赖在餐桌上聊天的客人赶赶走（虽然现实中这么挺不礼貌，但也是一些自助餐限时2小时的原因）。回到本案，如果我们调低了队列的长度，增加了适当的拒绝策略，并且可以把长时间排队的任务移除掉（这么做有一定风险），可以一定程度的提高系统恢复的速度。 最后补一句，我们在使用一些第三方工具包的时候（就算它是 spring 的），需要了解其大致的实现，避免因参数设置不全，带来意外的“收获”。 总结了这么多，小虎和小峰同学，终于心满意足的走向了自助餐厅，开始享用他们的晚餐。

扩展Page / App? 自定义navigationBar? 冗余授权代码？ local/session/expire缓存管理混乱？ … 总结了一些开发微信小程序过程中遇到问题的解决方式/经验分享，另外共享几个通用组件. star+✨ https://github.com/JoweiBlog/wechat-miniprogram-dev

各位开发者： 大家好 为了让开发者能够更方便的使用小程序·云开发。我们对云开发提供的基础资源配额进行了调整，具体调整内容包括： 存储上传次数由 2 万/天调整为 60 万/月 存储下载次数由 5 万/天调整为150 万/月 去除数据库 QPS 限制 数据库单集合索引调整为系统参数限制，由原有 10 个调整为 20 个 云函数数量调整为系统参数限制，由原有 20 个调整为 50 个 增加数据库流量说明，单次出包大小为 16 M 其余参数不做调整。调整后的配额信息可参考 小程序·云开发配额。 同时，由于近期小程序·云开发将上线付费功能（付费功能针对非基础资源配额，基础资源配额仍可免费使用）。为了给开发者更充足的时间进行调整，对于截止 2019-05-17 日前通过邮件申请调整的配额（非基础资源配额）的截止日期统一延长至 2019-06-30 。且对于已申请过配额调整的小程序帐号： 存储上传次数和存储下载次数调整为按月计算。如之前存储上传次数为 10 万/天，则调整后为 300 万/月 去掉数据库 QPS 限制 数据库单集合索引调整为系统参数限制，由原有 10 个调整为 20 个 云函数数量调整为系统参数限制，由原有 20 个调整为 50 个 增加数据库流量说明，单次出包大小为 16 M 云开发控制台新增详细的资源使用量统计 为了方便开发者了解资源使用情况，我们在云开发控制台的资源使用中增加了详细的资源使用量统计数据以及资源生命周期。开发者可通过下载最新 RC Build 版的开发者工具进行功能体验。 [图片] 小程序·云开发新增 HTTP API 为了进一步降低开发门槛并解决数据孤岛问题，小程序·云开发新增 HTTP API 支持。HTTP API 提供了小程序外访问云开发资源的能力，使用 HTTP API 开发者可在已有服务器上访问云资源，实现与云开发资源的互通。具体使用方法请参考 小程序·云开发HTTP API文档。 云调用支持开放数据调用 为了方便开发者更快速的进行功能迭代，云调用支持开放数据调用。对返回敏感开放数据的小程序端接口，从基础库 2.7.0 起，如果小程序已开通云开发，则可在开放数据接口的返回值中获取到唯一对应敏感开放数据的 cloudID，通过云调用可以直接获取到开放数据，具体使用方法请参考 云调用直接获取开放数据。 微信团队 2019.05.17

微信小程序的开发者们在发布小程序之前，需要给每个小程序起好一个名称，设置好logo、简介及类目信息，然后才能进行代码提审。 这些账号的基础信息是用户对一个小程序的初步认知，平台希望这些信息能够给予用户准确预期每个小程序的功能和内容，也希望每个小程序的名称是具有独特性的，减少误导、混淆用户理解的可能性。 因此有以下几点名称规则调整及优化建议，希望开发者可以了解并遵循，后续可能会在名称审核、代码审核或已发布运营时，收到平台的审核通知或建议修改通知。 l 微信小程序的名称建议是品牌、商标或具有辨识度的短词 在微信小程序发布后，用户会通过搜索、传播等场景使用小程序的功能和服务。选择品牌、商标或具有辨识度的短词作为小程序的名称，可以帮助用户快速建立与小程序的记忆与关系。 名称为“印象笔记”会比“笔记”能更好的让用户记忆和理解，并使用“印象”品牌词进行搜索或传播。 [图片] l 不能直接使用功能性描述、广义归纳类的词汇作为名称 功能性描述的词汇虽然可传达出小程序所要提供的相关功能，但直接使用此类词汇，缺乏显著性且不具有识别、区分小程序的作用。 如名称为“牙科”的账号，用户能直接理解小程序的内容可能与“牙科”相关，但对这个小程序账号是没有建立认知和关系的。  [图片]  l 不能同时使用地域性词汇与广义归纳类词汇进行命名 使用“地域+广义归纳类”词汇进行命名，同样存在指向性过于宽泛的问题。 如以下案例， 名称包含的地域词：“四川”、归纳类词：“系统门窗”，并不会让用户对账号的功能产生有效的预期。以下示例是不允许的： [图片] 但在政务民生类服务场景，“广州地铁”、“广州公积金”可以被用户理解并接受属于政府或相关机构提供的服务和资讯，因此“地域+广义归纳类”词汇可被政府民生场景使用。 l 不建议使用具有营销属性的词汇进行命名 营销属性词汇如：免费、促销、清仓、打折等，鉴于活动规则普遍附有限制条件，在名称中使用，通常带有过于夸大的表达效果，并非是小程序的核心功能和用户的全部认知，存在误导的可能性。以下示例是不允许的： [图片] l 商品销售类小程序，需要包含品牌名称，不直接使用产品分类进行命名 商品销售类小程序，若仅使用产品分类进行命名，无法建立易于记忆、易于传播的品牌形象。如名称为“女鞋男鞋女包批发生产”，用户并不会因“女鞋”“男鞋”“女包”就会进行选择，反而“品牌+女装”才是用户真正需要的。以下示例是不允许的。 [图片] l 不在名称中堆砌热门搜索关键词 名称中堆砌多个关键词，过于冗长的热门搜索关键词堆砌名称无法建立品牌记忆，目的普遍是在搜索结果上获得更多的曝光。以下示例是不允许的： [图片] 结语 此次名称规则的调整和优化建议，平台希望开发者们能相应地调整自己的小程序名称。如未满足名称规范，平台会在后续的小程序名称设置、名称审核、代码审核流程进行规则提示和修改要求。并会在搜索场景优化需求基础上，对无辨识度的账号名称进行搜索策略调整。 微信小程序完整的名称规则可具体参照《微信小程序平台运营规范》2. 基本信息规范，除以上规则与示例之外，当然还包括了不得使用违法违规的名称、不得使用侵权他人的品牌词进行命名、在命中敏感类目如医疗词时提交主体资质等规则。 平台希望小程序名称的优化调整，可以使得每个被开发者精心创造出来的小程序都能让用户在使用时、搜索时、传播时逐渐接受并建立对产品品牌的认知。

本文的开始源于落地页项目中遇到的 Chrome 控制台 warn 提示，担心影响页面渲染，特此弄个究竟。提示如下， [代码]Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details. [代码] 除非特殊说明，否则本文中的浏览器均指 Chrome Browser。 前言 本文将从以下几个方面对 CORB 进行探讨， 什么是 CORB 为什么会产生 CORB 什么情况下会出现 CORB 出现 CORB 时，我们可以如何看待 CORB 发生时浏览器表现 CORB 是一种判断是否要在跨站资源数据到达页面之前阻断其到达当前站点进程中的算法，降低了敏感数据暴露的风险。 - Chrome 浏览器提示 当请求发生 CORB 时，浏览器控制台会打印如下警告内容， [图片] [代码]Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details [代码] 在 [代码]chrome 66[代码]或这个版本之前，提示信息有细微不同， [代码]Blocked current origin from receiving cross-site document at https://www.example.com/example.html with MIME type text/html [代码] <p style=“color: #2c74bd”>当请求的响应结果本身就出错或为空时，早期版本 Chrome 依旧会出现上述提示，但 Chrome 69 之后的版本不再出现上述提示。下文<b>实验一和实验二</b>验证了该描述。</p> - Chrome 浏览器行为 [代码]The response body is replaced with an empty body. // 响应数据置为空 The response headers are removed. // 移除响应请求头 [代码] <p style=“color: #2c74bd”> CORB 启动时，虽然响应结果会被置空，但是请求的服务仍然成功，[代码]status: 200[代码]。比如：使用 [代码]img[代码] 标签上报页面监控数据，尽管响应结果为空，但请求依旧发送成功，服务器亦正常响应。下文<b>实验一</b>已验证。 </p> 为什么会有 CORB 的出现？ 简单来说，就是出现了一些网络安全漏洞，为防止漏洞肆虐，便出现了站点隔离（Site Isolation），CORB 则是其中的一种实现策略。 Spectre 和 Meltdown 漏洞 当恶意代码和正常站点存在于同一个进程时，恶意代码便可以访问进程内的内存，进行一系列访问攻击，此时，恶意代码窃取数据的唯一难点在于不知道敏感数据的具体存储位置，但通过 CPU 预执行 和 SCA 可以一步步 试探 出来。详细了解可参看: https://zhuanlan.zhihu.com/p/32784852 什么是 CPU 预执行？ [代码]if(condition) do_sth(); [代码] CPU 执行速度大于内存读取速度，为了提升 CPU 使用率，在从内存中读取 [代码]condition[代码] 完成之前，CPU 就已经开始执行下文内容。即不管 [代码]if[代码] 条件是否返回 [代码]true[代码]，CPU 都会提前执行里面的语句[代码]do_sth()[代码]。 CPU 预执行是芯片制造者决定的，为了提升 CPU 使用速度和效率而建的，预执行红利不是轻易就能放弃的，因此，目前或短期来看基本没可能改变。 普通浏览器中，不同的站点可能共享同一个进程 在某些情况下，没有实现 Site Isolution 的普通浏览器会出现一个进程里面同时运行多个站点的代码，这就让恶意站点有机可乘。比如恶意站点 [代码]a.dd.com[代码] 在自己的代码中嵌入 [代码]<iframe src="https://v.qq.com" frameborder="0"></iframe>[代码]，这时，普通浏览器就会把带有恶意站点 [代码]a.dd.com[代码] 的恶意代码 和 [代码]v.qq.com[代码] 放在同一个内存中运行。 [图片] SCA(Side-Channel Attacks) 旁道攻击 简单来说，就是利用程序运行时，系统产生的一些物理特征（如：时延，能耗，电磁，错误消息，频率等）进行推测型攻击。看起来有点不可思议，但早在 1956 年，英国已经利用 SCA 获取了埃及驻伦敦的加密机。 缓冲时延（Cache Timing）旁路是通过内存访问时间的不同来产生的旁路。假设访问一个变量，这个变量在内存中，这需要上百个时钟周期才能完成，但如果变量访问过一次，这个变量被加载到缓冲（Cache）中了，下次再访问，可能几个时钟周期就可以完成了，可根据这种访问速度窃取特定数据。Spectre 和 Meltdown 漏洞便是利用了这种特性。 如何预防 Spectre 和 Meltdown 漏洞呢？ 漏洞三大关键点是 CPU 预执行、SCA 和 共享进程。预防就得从这三个方面着手。先看 SCA，算法运行时间的变化本质就是源于数据处理，根据时间变化推测运算操作和数据存储位置，因此 SCA 可预防性极低。再看 CPU 预执行，性能至少提高 10%，一片可观的红利，芯片厂商如何舍得放弃。如此，只能针对共享进程下手了，Site Isolation 便是剥离共享进程的一项技术，采用独立站点独立进程的方式实现，降低漏洞的威胁。 Site Isolation 站点隔离保证了不同站点页面始终被放入不同的进程，每个进程运行在一个有限制的沙箱环境中，在该环境中可能会阻止进程接收其它站点返回的某些特殊类型敏感信息，恶意站点不再和正常站点共享进程，这就让恶意站点窃取其它站点的信息变得更加困难。从 Chrome 67 开始，已默认启用 Site Isolation。 [图片] 经验证，[代码]Site Isolation[代码] 关于进程独立的原则是 只要一级域名一样，站点实例就共享一个进程，无论子域名是否一样。如果使用 iframe 嵌入了一级域名不一样的跨域站点，则会生成一个新的进程维护该跨域站点运行，这一点同前文介绍的普通浏览器共享进程不同。更详细的内容参看 http://www.yaoyanhuo.com/blog/site_isolate_process 这是 Site Isolation 的进程设计，那么其中的 CORB 扮演了什么角色呢？ 在同源策略下，Site Isolation 已经很好地隔离了站点，只是还有跨域标签这样的东西存在，敏感数据依旧会暴露，依旧会进驻恶意站点内存空间。 有这样一个场景，用户登录某站点 [代码]some.qq.com[代码]后，又访问了 [代码]bad.dd.com[代码] 恶意站点，恶意站点有如下代码，[代码]<script src="some.qq.com/login">[代码]，跨域请求了原站点的登录请求，此时，普通浏览器会正常返回登录后的敏感信息，且敏感信息会进驻 [代码]bad.dd.com[代码] 内存空间。好不容易站点隔离把各个站点信息分开了，这因为跨域又在一起了。咋整？CORB 来了。CORB 会在敏感信息到达 web apge 之前，将其拦截掉，如此，敏感信息既不会暴露于浏览器，也不会进驻内存空间，得到了很好的保护。 CORB 发生时机 当跨域请求回来的数据 MIME type 同跨域标签应有的 MIME 类型不匹配时，浏览器会启动 CORB 保护数据不被泄漏，被保护的数据类型只有 [代码]html[代码] [代码]xml[代码] 和 [代码]json[代码]。很明显 [代码]<script>[代码] 和 [代码]<img>[代码] 等跨域标签应有的 MIME type 和 [代码]html[代码]、[代码]xml[代码]、[代码]json[代码] 不一样。 MIME type (Multipurpose Internet Mail Extensions) MIME type 同 CORB 有着相当紧密的关系，可以说 CORB 的产生直接依附 MIME 类型。因此，阅读本文前，有必要先理解一下什么是 MIME type。 MIME 是一个互联网标准，扩展了电子邮件标准，使其可以支持更多的消息类型。常见 [代码]MIME[代码] 类型如：[代码]text/html[代码] [代码]text/plain[代码] [代码]image/png[代码] [代码]application/javascript[代码] ，用于标识返回消息属于哪一种文档类型。写法为 [代码]type/subtype[代码]。 在 HTTP 请求的响应头中，以 [代码]Content-Type: application/javascript; charset=UTF-8[代码] 的形式出现，[代码]MIME type[代码] 是 [代码]Content-Type[代码] 值的一部分。如下图， [图片] 内容嗅探技术（MIME sniffing） 内容嗅探技术是指 当响应头没有指明 [代码]MIME type[代码] 或 浏览器认为指定类型有误时，浏览器会对内容资源进行检查并执行，来猜测内容的正确[代码]MIME[代码]类型。嗅探技术的实现细节，不同的浏览器在不同的场景下有不同的方式，本文不做详述。详细内容参见：https://www.keycdn.com/support/what-is-mime-sniffing 如何禁用 [代码]MIME sniffing[代码] 呢？ 服务器在响应首部添加 [代码]X-Content-Type-Options: nosniff[代码]，用来告诉浏览器一定要相信 [代码]Content-Type[代码] 中指定的 [代码]MIME[代码] 类型，不要再使用内容嗅探技术探测响应内容类型。该方法仅对 [代码]<script>[代码] 和 [代码]<style>[代码] 有效。 官方解释：https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing 浏览器如何判断响应内容是否需要 CORB 保护？ 这可能是本文最需要关心的内容了，到底什么情况下会出现 CORB 。在满足跨域标签（如：[代码]<script>[代码]，[代码]<img>[代码]）请求的响应内容的 [代码]MIME type[代码] 是 [代码]HTML MIME type[代码] 、 [代码]XML MIME type[代码]、[代码]JSON MIME type[代码] 和 [代码]text/plain[代码] 时，以下三个条件任何一个满足，就享受 CORB 保护。（[代码]image/svg+xml[代码] 不在内，属图片类型） 响应头包含 [代码]X-Content-Type-Options: nosniff[代码] 响应结果状态码是 [代码]206 Partial Content[代码] （https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/206） 浏览器嗅探响应内容的 MIME 类型结果就是 json/xml/html 这种嗅探用于防止某些内容因被错误标记 MIME 类型 而被 CORB 阻断不能正常响应返回，且该嗅探基于 [代码]Content-Type[代码] 进行，比如类型是 [代码]text/json[代码]，便只会对内容进行 json 类型检查，而不会进行 xml 或 html 的检查。 [代码]HTML MIME type[代码] 、 [代码]XML MIME type[代码]、[代码]JSON MIME type[代码] 的出现能理解，为什么 [代码]text/plain[代码] 类型也会在保护范围内？ 因为 当 [代码]Content-Type[代码] 缺失的时候，响应内容 [代码]MIME type[代码] 有可能就是 [代码]text/plain[代码]；且据可靠数据显示， HTML, JSON, or XML 有时候也会被标记为 [代码]text/palin[代码]。如， data.txt [代码]{ "ret_code": 0, "msg": "请求成功！", "data": [1, 2, 3, 4, 5] } [代码] server.js [代码]app.get('/file', function getState(req,res,next){ // res.type('json') res.sendfile(`${__dirname}/public/data.txt`) }) [代码] 如上代码，启动 server.js ，Chrome 浏览器访问 [代码]/file[代码] 时服务返回 [代码]data.txt[代码] 内容，尽管响应头是 [代码]Content-Type: text/plain; charset=UTF-8[代码]，响应内容依旧能被识别为 [代码]json[代码]。由此， [代码]text/plain[代码] 会作为 [代码]json[代码] 的标记也是一种常见现象。如果跨域访问 [代码]/file[代码] 就会出现 CORB，验证结果如下图， [图片] 如果使用 script 跨域请求本就是 js 资源，但该资源却被打上了错误的 Content-Type，还添加了 nosiniff，会发生什么？ 很多时候 [代码]script[代码] 文件被会打上 [代码]html[代码] [代码]xml[代码] [代码]json[代码] 这些 MIME 类型，如果 Chrome 浏览器直接 block，将相应内容置空，当前域下的网站便会 因为缺少 js 执行内容而不能正常运行。为避免这种情况出现，Chrome 浏览器在决定是否保护响应内容前，会先判断 script 的响应内容是否是受保护的 MIME 类型（[代码]html[代码] [代码]xml[代码] [代码]json[代码] ）。如果检测结果是，则启动 CORB，如果无法检测会直接返回，不启用 CORB。 对于跨域请求 js 资源，如果已经存在 nosniff 的情况下，还把 js 资源设置成了其它类型（如：json），那么必定触发 CORB 保护机制，无法返回 js 资源内容，如果此时本域站点刚好需要这个 js 资源，就 GG 了。相当于 错误的 MIME type 加上 [代码]X-Content-Type-Options: nosniff[代码] 会触发 CORB ，即使资源真正的类型同跨域标签一致。 为了最佳安全策略，建议开发者 为响应内容标记正确的 [代码]Content-Type[代码]； 使用 [代码]X-Content-Type-Options: nosniff[代码] 禁止 [代码]MIME sniffing[代码]，如此，可以让浏览器不进行内容 MIME 类型嗅探，从而更简单快速地保护资源或响应返回。 控制台出现 CORB 提示时，不用担心，一般不会对页面产生本质性的影响，可以直接忽略。 Chrome 发生 CORB 保护时的提示和行为验证 虽然该部分内容属于验证类，但想了解一项知识点，仅仅简单地阅读是不够的，实际操作试验后才能获得更深的印象和理解。 环境准备 Chrome 版本： Chrome 73。 Node 服务代码 [代码]index.js[代码]， [代码]const express = require('express') const path = require('path') const app = express() const port = process.argv[2] || 3002 app.get('/', function (req, res) { res.send('<p>hello world!</p>') }) app.get('/data', function (req, res) { console.log('请求正常，只是浏览器将响应数据置空') res.json({greeting: 'hello chrome!'}) }) app.listen(port, () => console.log(`app is listening at localhost:${port}`)) [代码] 配置 host [代码]127.0.0.1 a.dd.com 127.0.0.1 c.dd.com 127.0.0.1 test.pp.com [代码] 实验一：在[代码]test.pp.com[代码]中使用 [代码]img[代码] 标签跨域请求 [代码]c.dd.com[代码] 的数据，数据 MIME 类型为 json 执行 [代码]npm init[代码] 和 [代码]npm install[代码] 安装服务依赖包 执行 [代码]node index.js[代码] 启动服务 浏览器中访问 [代码]test.pp.com:3002[代码] 并打开 开发者工具 开发者工具 [代码]Elements[代码] 中插入 [代码]<img src="http://c.dd.com:3002/data"/>[代码] （选中 body 元素，再按 F2 即可进入 html 编辑模式） [图片] 查看控制台 [代码]console[代码] 即可见，CORB 提示。 [图片] 删掉 [代码]app.get('/data')[代码] 方法返回的数据 [代码]{greeting: 'hello chrome!'}[代码]，即 将服务本身返回的数据本身置空，CORB 提示消失，但依旧看不到请求头 和 响应结果。 <p style=“color: red”> 实验结果：1. 使用 [代码]img[代码] 跨域请求 json 类型的数据确实会出现 CORB；2. 当服务本身返回数据为空时，CORB 提示会消失，但其行为依然保持。 </p> 实验二：在[代码]test.pp.com[代码] 中使用 [代码]script[代码] 跨域请求 [代码]c.dd.com[代码] 的数据，数据 MIME 类型为 json 补回实验一删掉的代码 [代码]{greeting: 'hello chrome!'}[代码]，浏览器中访问 test.pp.com 并 打开开发者工具。 在开发者工具 [代码]console[代码] 栏中执行下方代码，即可插入 js 标签并发送跨域请求。 [代码]s = document.createElement('script') s.src = 'http://c.dd.com:3002/data' document.head.appendChild(s) [代码] 效果如图， [图片] 同 [代码]img[代码] 表现一致，出现了 CORB 提示。清除[代码]{greeting: 'hello chrome!'}[代码]，将服务返回数据置空，效果同 [代码]img[代码] 方式表现一致，CROB 提示消失。其它行为也同 [代码]img[代码] 。 <p style=“color: red”> 实验结果：同 [代码]img[代码] 行为效果一模一样。 </p> 看了浏览器中 请求的响应 情况，现在看看，两次实验的 请求执行 情况， [图片] <p style=“color: red”> 可以看到尽管产生了 CORB 保护，让响应结果变为空，也隐藏了请求头，但服务请求本身始终正常接收请求并进行处理。由此，看到 CORB 后，一般可以直接忽略该提示。 </p> 如果跨域请求 [代码]http://a.dd.com:3002/data[代码] 本身发生错误，则完全无需 CORB 的保护，本身就已经不能正常返回了。因此，更不需要 CORB 的提示和行为。 实验三：在 [代码]test.pp.com[代码] 中跨域请求 [代码]c.dd.com[代码] 服务的 server.js 文件 本实验旨在验证 在某站点跨域请求 js 文件，而该 js 文件被设置了不同的 MIME 类型 和 [代码]nosniff[代码] 时，Chrome 是否会出现 CORB 。 第一步，server.js 文件 MIME 类型为默认，不设置 [代码]nosniff[代码]。[代码]c.dd.com[代码]服务代码 index.js 中添加如下代码， 代码片段一， [代码]app.get('/file', function getState(req,res,next){ res.sendfile(`${__dirname}/public/js/server.js`) }) [代码] 打开 Chrome [代码]test.pp.com[代码] 的开发者工具，并在开发者工具中执行如下代码，跨域请求 server.js 代码片段二， [代码]s = document.createElement('script') s.src = 'http://c.dd.com:3002/file' document.head.appendChild(s) [代码] 运行结果如下图， [图片] [图片] 如图所示：真实请求头被隐藏，[代码]Provisional headers are shown[代码]；响应头可见；响应结果可见。 第二步，设置 MIME 类型为 [代码]json[代码]，即 [代码]Content-Type: application/json; charset=utf-8[代码]，不设置 [代码]nosniff[代码]。修改 index.js [代码]/file[代码] 部分代码如下， 代码片段三， [代码]app.get('/file', function getState(req,res,next){ res.type('json') res.sendfile(`${__dirname}/public/js/server.js`) }) [代码] 再次执行本实验 代码片段二，发现运行结果同第一步（即默认 MIME 类型）完全一样：真实请求头被隐藏，Provisional headers are shown；响应头可见；响应结果可见。 第三步，设置 MIME 类型为 json，即 [代码]Content-Type: application/json; charset=utf-8[代码]，并添加 [代码]'X-Content-Type-Options': 'nosniff'[代码] 响应头。（如果不理解该响应头的含义，请再次阅读文顶内容嗅探相关描述） 两个响应头加在一起的意思是，明明自己是 js ，却告诉浏览器 MIME 类型是 json，还非不让浏览器使用嗅探技术修正 MIME 类型。 修改 index.js [代码]/file[代码]部分代码如下。 代码片段四， [代码]app.get('/file', function getState(req,res,next){ res.type('json') res.set({ 'X-Content-Type-Options': 'nosniff' }) res.sendfile(`${__dirname}/public/js/server.js`) }) [代码] 再次执行本实验 代码片段二，运行结果如下图， [图片] [图片] [图片] 如图所示： 跨域请求 js 文件时，如果没有设置 nosniff，甭管 MIME 类型设置了什么，都只是请求头不显示，响应头和响应结果正常显示。如果设置了 nosniff 且 MIME 类型不是 js，则会触发 CORB 保护，跨域 js 无法正常加载。 因此，如果作为跨域站点 [代码]c.dd.com[代码] 和 本域站点 [代码]test.pp.com[代码] 合作时，如果为了 减少 MIME 类型嗅探时间 加上了 [代码]nosniff[代码] 请求头，同时，需务必保证设置的 MIME 类型同 js 文件一致！否则 本域站点 无法拿到 跨域站点 的 js 资源数据！ ----------------- 关于 CORB ， Chrome 表现和行为验证结束 ------------------- 原文地址：http://www.yaoyanhuo.com/blog/corb 参考内容 CORB 行为官方说明：https://www.chromium.org/Home/chromium-security/corb-for-developers CORB Explainer：https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md speculative side-channel attack techniques: https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html Chrome浏览器安全新功能 网站隔离：https://www.trustauth.cn/wiki/26052.html 30 分钟理解 CORB 是什么：https://www.cnblogs.com/oneasdf/p/9525490.html X-Content-Type-Options：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-Content-Type-Options 浏览器 MIME 类型嗅探：https://www.keycdn.com/support/what-is-mime-sniffing 延伸阅读，曾经 IE 的一个内容嗅探技术漏洞：http://www.safebase.cn/article-131906-1.html 浏览器工作原理：https://www.infoq.cn/article/CS9-WZQlNR5h05HHDo1b 给程序员解释 Spectre 和 Meltdown 漏洞：https://zhuanlan.zhihu.com/p/32784852 旁道攻击：https://zh.wikipedia.org/wiki/旁路攻击 V8 引擎：https://zhuanlan.zhihu.com/p/27628685 一些还在讨论中的 CORB 行为：https://github.com/whatwg/fetch/issues?utf8=✓&q=is%3Aissue+CORB+ fetch API：https://developers.google.com/web/updates/2015/03/introduction-to-fetch

写在前面 今天你可以在小程序中使用 Cax 引擎高性能渲染 SVG！ SVG 是可缩放矢量图形(Scalable Vector Graphics)，基于可扩展标记语言，用于描述二维矢量图形的一种图形格式。它由万维网联盟制定，是一个开放标准。SVG 的优势有很多: SVG 使用 XML 格式定义图形，可通过文本编辑器来创建和修改 SVG 图像可被搜索、索引、脚本化或压缩 SVG 是可伸缩的，且放大图片质量不下降 SVG 图像可在任何的分辨率下被高质量地打印 SVG 可被非常多的工具读取和修改（比如记事本） SVG 与 JPEG 和 GIF 图像比起来，尺寸更小，且可压缩性、可编程星更强 SVG 完全支持 DOM 编程，具有交互性和动态性 而支持上面这些优秀特性的前提是 - 需要支持 SVG 标签。比如在小程序中直接写： [代码]<svg width="300" height="150"> <rect bindtap="tapHandler" height="100" width="100" style="stroke:#ff0000; fill: #0000ff"> </rect> </svg> [代码] 上面定义了 SVG 的结构、样式和点击行为。但是小程序目前不支持 SVG 标签，仅仅支持加载 SVG 之后 作为 background-image 进行展示，如 [代码]background-image: url("data:image/svg+xml.......)[代码]，或者 base64 后作为 background-image 的 url。 直接看在小程序种使用案例: [代码]import { html, renderSVG } from '../../cax/cax' Page({ onLoad: function () { renderSVG(html` <svg width="300" height="220"> <rect bindtap="tapHandler" height="110" width="110" style="stroke:#ff0000; fill: #ccccff" transform="translate(100 50) rotate(45 50 50)"> </rect> </svg>`, 'svg-a', this) }, tapHandler: function () { console.log('你点击了 rect') } }) [代码] 其中的 svg-a 对应着 wxml 里 cax-element 的 id: [代码]<view class="container"> <cax-element id="svg-c"></cax-element> </view> [代码] 声明组件依赖 [代码]{ "usingComponents": { "cax-element":"../../cax/index" } } [代码] 小程序中显示效果: [图片] 可以使用 [代码]width[代码]，[代码]height[代码]，[代码]bounds-x[代码] 和 [代码]bounds-y[代码] 设置绑定事件的范围，比如: [代码]<path width="100" height="100" bounds-x="50" bounds-y="50" /> [代码] 需要注意的是，元素的事件触发的包围盒受自身或者父节点的 transform 影响，所以不是绝对坐标的 rect 触发区域。 再来一个复杂的例子，用 SVG 绘制 Omi 的 logo: [代码]renderSVG(html` <svg width="300" height="220"> <g transform="translate(50,10) scale(0.2 0.2)"> <circle fill="#07C160" cx="512" cy="512" r="512"/> <polygon fill="white" points="159.97,807.8 338.71,532.42 509.9,829.62 519.41,829.62 678.85,536.47 864.03,807.8 739.83,194.38 729.2,194.38 517.73,581.23 293.54,194.38 283.33,194.38 "/> <circle fill="white" cx="839.36" cy="242.47" r="50"/> </g> </svg>`, 'svg-a', this) [代码] 小程序种显示效果: [图片] 在 omip 和 mps 当中使用 cax 渲染 svg，你可以不用使用 htm。比如在 omip 中实现上面两个例子： [代码] renderSVG( <svg width="300" height="220"> <rect bindtap="tapHandler" height="110" width="110" style="stroke:#ff0000; fill: #ccccff" transform="translate(100 50) rotate(45 50 50)"> </rect> </svg>, 'svg-a', this.$scope) [代码] [代码]renderSVG( <svg width="300" height="220"> <g transform="translate(50,10) scale(0.2 0.2)"> <circle fill="#07C160" cx="512" cy="512" r="512"/> <polygon fill="white" points="159.97,807.8 338.71,532.42 509.9,829.62 519.41,829.62 678.85,536.47 864.03,807.8 739.83,194.38 729.2,194.38 517.73,581.23 293.54,194.38 283.33,194.38 "/> <circle fill="white" cx="839.36" cy="242.47" r="50"/> </g> </svg>, 'svg-a', this.$scope) [代码] 需要注意的是在 omip 中传递的最后一个参数不是 [代码]this[代码]，而是 [代码]this.$scope[代码]。 在 mps 中，更加彻底，你可以单独创建 svg 文件，通过 import 导入。 [代码]//注意这里不能写 test.svg，因为 mps 会把 test.svg 编译成 test.js import testSVG from '../../svg/test' import { renderSVG } from '../../cax/cax' Page({ tapHandler: function(){ this.pause = !this.pause }, onLoad: function () { renderSVG(testSVG, 'svg-a', this) } }) [代码] 比如 test.svg ： [代码]<svg width="300" height="300"> <rect bindtap="tapHandler" x="0" y="0" height="110" width="110" style="stroke:#ff0000; fill: #0000ff" /> </svg> [代码] 会被 mps 编译成： [代码]const h = (type, props, ...children) => ({ type, props, children }); export default h( "svg", { width: "300", height: "300" }, h("rect", { bindtap: "tapHandler", x: "0", y: "0", height: "110", width: "110", style: "stroke:#ff0000; fill: #0000ff" }) ); [代码] 所以总结一下: 你可以在 mps 中直接使用 import 的 SVG 文件的方式使用 SVG 你可以直接在 omip 中使用 JSX 的使用 SVG 你可以直接在原生小程序当中使用 htm 的方式使用 SVG 这就完了？远没有，看 cax 在小程序中的这个例子： [图片] 详细代码: [代码]renderSVG(html` <svg width="300" height="200"> <path d="M 256,213 C 245,181 206,187 234,262 147,181 169,71.2 233,18 220,56 235,81 283,88 285,78.7 286,69.3 288,60 289,61.3 290,62.7 291,64 291,64 297,63 300,63 303,63 309,64 309,64 310,62.7 311,61.3 312,60 314,69.3 315,78.7 317,88 365,82 380,56 367,18 431,71 453,181 366,262 394,187 356,181 344,213 328,185 309,184 300,284 291,184 272,185 256,213 Z" style="stroke:#ff0000; fill: black"> <animate dur="32s" repeatCount="indefinite" attributeName="d" values="......太长，这里省略 paths........" /> </path> </svg>`, 'svg-c', this) [代码] 再试试著名的 SVG 老虎: [图片] path 太长，就不贴代码了，可以点击这里查看 pasiton 标签 [代码]import { html, renderSVG } from '../../cax/cax' Page({ onLoad: function () { const svg = renderSVG(html` <svg width="200" height="200"> <pasition duration="200" bindtap=${this.changePath} width="100" height="100" from="M28.228,23.986L47.092,5.122c1.172-1.171,1.172-3.071,0-4.242c-1.172-1.172-3.07-1.172-4.242,0L23.986,19.744L5.121,0.88 c-1.172-1.172-3.07-1.172-4.242,0c-1.172,1.171-1.172,3.071,0,4.242l18.865,18.864L0.879,42.85c-1.172,1.171-1.172,3.071,0,4.242 C1.465,47.677,2.233,47.97,3,47.97s1.535-0.293,2.121-0.879l18.865-18.864L42.85,47.091c0.586,0.586,1.354,0.879,2.121,0.879 s1.535-0.293,2.121-0.879c1.172-1.171,1.172-3.071,0-4.242L28.228,23.986z" to="M49.1 23.5H2.1C0.9 23.5 0 24.5 0 25.6s0.9 2.1 2.1 2.1h47c1.1 0 2.1-0.9 2.1-2.1C51.2 24.5 50.3 23.5 49.1 23.5zM49.1 7.8H2.1C0.9 7.8 0 8.8 0 9.9c0 1.1 0.9 2.1 2.1 2.1h47c1.1 0 2.1-0.9 2.1-2.1C51.2 8.8 50.3 7.8 49.1 7.8zM49.1 39.2H2.1C0.9 39.2 0 40.1 0 41.3s0.9 2.1 2.1 2.1h47c1.1 0 2.1-0.9 2.1-2.1S50.3 39.2 49.1 39.2z" from-stroke="red" to-stroke="green" from-fill="blue" to-fill="red" stroke-width="2" /> </svg>`, 'svg-c', this) this.pasitionElement = svg.children[0] }, changePath: function () { this.pasitionElement.toggle() } }) [代码] pasiton 提供了两个 path 和 颜色 相互切换的能力，最常见的场景比如 menu 按钮和 close 按钮点击后 path 的变形。 举个例子，看颜色和 path 同时变化： [图片] 线性运动 这里举一个在 mps 中使用 SVG 的案例: [代码]import { renderSVG, To } from '../../cax/cax' Page({ tapHandler: function(){ this.pause = !this.pause }, onLoad: function () { const svg = renderSVG(html` <svg width="300" height="300"> <rect bindtap="tapHandler" x="0" y="0" height="110" width="110" style="stroke:#ff0000; fill: #0000ff" /> </svg>` , 'svg-a', this) const rect = svg.children[0] rect.originX = rect.width/2 rect.originY = rect.height/2 rect.x = svg.stage.width/2 rect.y = svg.stage.height/2 this.pause = false this.interval = setInterval(()=>{ if(!this.pause){ rect.rotation++ svg.stage.update() } },15) }) [代码] 效果如下: [图片] 组合运动 [代码]import { renderSVG, To } from '../../cax/cax' Page({ onLoad: function () { const svg = renderSVG(html` <svg width="300" height="300"> <rect bindtap="tapHandler" x="0" y="0" height="110" width="110" style="stroke:#ff0000; fill: #0000ff" /> </svg>` ,'svg-a', this) const rect = svg.children[0] rect.originX = rect.width/2 rect.originY = rect.height rect.x = svg.stage.width/2 rect.y = svg.stage.height/2 var sineInOut = To.easing.sinusoidalInOut To.get(rect) .to().scaleY(0.8, 450, sineInOut).skewX(20, 900, sineInOut) .wait(900) .cycle().start() To.get(rect) .wait(450) .to().scaleY(1, 450, sineInOut) .wait(900) .cycle().start() To.get(rect) .wait(900) .to().scaleY(0.8, 450, sineInOut).skewX(-20, 900, sineInOut) .cycle() .start() To.get(rect) .wait(1350) .to().scaleY(1, 450, sineInOut) .cycle() .start() setInterval(() => { rect.stage.update() }, 16) } }) [代码] 效果如下: [图片] 其他 vscode 安装 lit-html 插件使 htm 的 html[代码]内容[代码] 高亮 还希望小程序 SVG 提供什么功能可以开 issues告诉我们，评估后通过，我们去实现！ Cax Github 参考文档

一、引子 随着越来越多的商家使用有赞，搜索或详情的需求也日益增长，针对需求及场景，之前提到过的《订单管理架构演变》及《 AKF 架构》等在这两篇文章里已经有所体现（可关注微信公众号：有赞coder），而这些数据的查询来自于不同的 Nosql，怎么同步这些非实时存储系统将是一个很有趣的事情。 1.1 同步现状 当前有赞订单同步流程及业务现状如图所示，采用了 ES+HBase（tip1）架构体系去解决搜索和详情的需求，利用 canal（tip2）将数据库变更写入到 mq 中，然后利用同步系统来解决相关数据同步问题，而后续下文中将叙述有赞订单同步面临的问题及应对方案。 [图片] 二、同步 2.1 实现同步基础 - 单表同步 2.1.1 乱序问题 单表同步如图所示： [图片] 业务场景中，在这任何一个序号链路中，如果并发出现同一主键的两条消息，同时在 Nosql 中没有做版本控制，都有可能造成消息乱序问题，而相反，如果通过顺序解析 binlog 的同时，为每条 statement sql 执行的结果分配一个顺序 SeqNo，该 SeqNo 保证有序（tip3），再通过 Nosql 中控制乐观锁就可以解决顺序性问题。 2.1.2 HBase 同步 Hbase 同步相对来说比较简单，Hbase 内部拥有 timestamp 协助控制每个 qualify 的版本，只要让 timestamp 传入上文所说的顺序 SeqNo，那么就可以保证每个字段读取出来的数据是最终一致性的。 2.1.3 ES 同步 ES 同步针对单表场景可以通过 index 的操作来进行写入，index 可以采用 exteneral 版本也称作外部版本号来进行控制，同样适用上述的 SeqNo 来做乐观锁去解决该问题。 2.1.4 同步过程图 [图片] 2.2 实现同步进阶 - 多表同步 2.2.1 乱序问题 多表同步基于单表同步的基础上做相关的同步，如图所示： [图片] 当数据库的两张表（不关心是否在一个实例上，如果不在，还更惨，SeqNo 还不一定能够保证有序）触发了更新操作，假设 t1 生成 binlog 的 SeqNo 小于 t2 生成binlog 的 SeqNo，若 t1 这条消息因序号链路中的网络抖动或其它原因造成消费晚于 t2，也就是 t2 的 binlogSeq 先写入 Nosql 中，那么就会造成一个 t1 的数据无法写入到 Nosql 中。 2.2.2 HBase同步 其实上述多表同步乱序的问题并不是绝对的，针对 Hbase 这种自带列版本号的将会自动处理或丢弃低版本数据，同时针对这种情况，设计成每个 table 表中的字段都会列入到 Hbase 中。举个例子，针对订单的情形存入订单主表和订单商品表 场景1:1 针对订单主表，我们写入的数据以订单号做 hash，然后以 hash 值:订单号作为主键降低热点问题，同时定义单 column family，qualifiy 格式为 表:字段 value为对应的 value 值，timestamp 为 SeqNo，如图所示： [图片] 场景1:n 针对订单商品表，我们写入的数据同样以订单号生成相应的 rowkey，同时定义单 column family，qualifiy 格式为 表:字段:对应记录的 id 值 value 为对应的 value 值，timestamp 为 SeqNo，如图所示： [图片] 通过上述写入，能够针对具体到某个字段都有对应的 timestamp 值的更新，为后期写入更新数据能够更新到具体字段级别。 2.2.3 ES同步 针对上面的同步乱序问题，ES 没有 HBase 这种列版本号，ES 只有 doc 级别的 version，如果上述真的出现 SeqNo2>SeqNo1,且 SeqNo2 早于 SeqNo1 写入到 ES 中，则就会出现 SeqNo1 的内容无法写入，也就会造成顺序不一致的情况。那如何去解决这个多表同步问题呢？ 既然会乱序，那让它有序就好了，数据保证有序不就能够解决这个事情嘛，让整个链路有序也就代表 canal 消费 binlog 数据保证有序且丢到 MQ 中有序，MQ 然后保证顺序投递到 Sync 消费处理程序中，通过消费一条消息然后 ack 告诉 MQ 是否成功，已达到保证所有数据全部有序（若多线程或多机器处理 MQ 中的多个分区都是会存在问题）。如图所示： [图片] 如此只要保证 t1 表的数据和 t2 表中的数据在 ES 不互相关联，每个数据写入的时候按照 update 方式写入（如果不存在需要做一次 create 操作）,这样就能保证所有数据按照顺序执行。 2.3 配置化同步 上文已经讲到数据同步是由一个数据源（这个数据源可以来自于 MQ、Mysql 等）同步到另外一个数据源（Mysql、ES、HBase、Alert 等），也就是一个管道的过程。借鉴了一下 logstash 官网，同样处理流程分为 input、filter、output 组件，这些流程称之为 task 任务，如图所示： [图片] 通过这些组件，抽象化出每个组件都有对应的配置，由这些配置来进行初始化组件，驱动组件去执行流程。简单来说，只需要在页面中配置一些组件，无需开发任何一行代码就能实现同步任务。如图所示： [图片] 通过一系列的配置，就能配置出一个任务，针对业务逻辑，可以采用动态语言 groovy 来实行脚本化处理（复杂业务场景可以通过 UDF 函数来做支持），针对 mqinput 拿到的字段然后经过处理，经过过滤 filter 等，可以直接拿到相关的数据进行组装，然后配置化的写入到 ES 中，无需开发任何一行 java 代码即可实现流程自动配置化，针对复杂的需求也能够高效率支持。配置界面如图所示： [图片] 2.3.1 性能瓶颈 上述就能解决 ES 多表同步的问题，但是同样会存在一些问题： 性能瓶颈问题 失败堆积问题 性能瓶颈：比如写入量超级大的场景情况下，而 Sync 消费程序只能针对 MQ 中的分区（kafka 的 partition 概念）消费，每个分区只能有一个线程去执行，消费速率与消费分区成正比，与消费 RT 成反比，尤其是大促场景下就会造成数据消费不过来，数据堆积严重问题。 失败堆积：因为是顺序消费，只要某个分区的某条消息消费失败，后续消息就会全部堆积，造成数据延迟率超高。所以建议用顺序队列的场景除非是业务量没有性能瓶颈的情况下可以采取使用，而怎么去解决顺序队列或者去掉顺序队列呢？ 用顺序队列无非就是保证有序，因为 ES 没有 HBase 的字段级别版本号，目前订单采用的是用 HBase 做一层中间处理层，解决该问题，如图所示： [图片] 通过借助 HBase 字段级别版本号帮助每个表保证表内部字段有序，同时 put 写入完数据之后，通过额外字段 version 做 increment 操作，当这两个写入动作完成之后立马 get 操作拿到 HBase 的数据写入到 ES 中，无论并发程度如何，最终至少有一次的 get 请求拿到的版本 version 字段是最大的，用该 version 作为 ES 的外部版本号解决 ES 版本号问题。 用此方案会有好处： HBase 协助管理内部字段版本，同时根据内部操作，协助 ES 拿到对应的版本，且数据能拿到最新数据； 去掉了顺序队列，HBase 具有良好的吞吐，相对于顺序队列拥有更大的吞吐量； 横向拓展增大消费速率； ES 可以采用 index 操作，性能更好。 当然也有弊端：HBase 存在抖动的情况，以及主备切换问题。 因为存在抖动或者准备切换问题，会造成数据不一致，我们该怎么去解决这个事情呢？ 2.4 未来扩展 目前订单同步是通过加载配置文件形式来做的，也就是横向拓展的机器都会去加载同一份配置文件，各个任务通过异常解耦，理论上不会有影响，但是会存在加载任务的重要度的问题。 举个例子： 我需要一台机器临时去消费数据解决线上问题； 有个量级很大但又不是很重要的任务，想不影响其他任务的进行； 要做对比，增量延迟对比或全量对比数据，但又不希望影响其他数据； 查询日志需要所有机器查看查询（当然，公司有内部日志系统，可直接上去查看） 如此，可以让同步系统无状态化，每个任务的配置加载有任务配置平台来进行配置，指定相关的机器做相关的处理，扩容也可以动态申请扩容，如图所示，可以自由分配机器处理不同的任务。 [图片] 三、一致性保障 上文讲了有赞在处理订单的时候怎么讲数据同步到 ES 或 HBase，数据来源于 binlog，写入到 MQ，也就是说处理的来源来自于 MQ。简单一句话来讲：我们不生产消息，我们是消息的搬运工。“搬运工”的角色可以做一些事情，同样有赞在处理数据对比也是如此，这章讲讲“搬运工”可以做什么： 3.1 数据对比 上述一般情况下不会出问题，那如果出问题了怎么办，需要做数据对比，而数据来源就是我们刚刚抛弃的顺序队列，顺序队列有个缺点就是堆积，同样我们也可以利用堆积的特性，让其第一条消息堆积十分钟，那么后续消息基本上也会堆积十分钟，然后就可以消费这个消息进行数据拉取，拿到最新的数据进行数据对比，如图所示： [图片] 通过对比结果发送到 alert 中，就可以知道哪些数据不一致，频率多少，这也是一种同步（mq->filter->alert)! 3.2 全量对比/数据刷入 上述我们讲到数据同步到 Nosql 中，但是只是讲了增量的一个过程，涉及到历史数据，就需要对历史数据进行迁移，同样，这也是一种数据同步，后面将会出相关博文怎么去做全量数据同步。 四、Tips Tip-1：为什么采用 ES + HBase 处理搜索和详情？ 一般情况下，公司达到一定规模，有类似全文检索的需求或者高频 key:value 的时候，大家会推荐 ES+HBase 的架构体系去完成搜索和详情的需求，而现实中，绝大多数情况下生产环境不会将数据直接写入到 ES 或者 Hbase，大家都会优先写入数据库，不进行双写的操作是因为增加链路影响业务。当然 Hbase 可能还好一点，ES 本身就是非实时查询系统（为什么是非实时，有兴趣的可以去看看ES读写流程），这种情况下也造就了 ES 和 HBase 的一个准实时系统。针对业务来说，准实时是可以满足相关需求的，比如商家搜索订单并不要求实时。 Tip-2：为什么有赞选 canal 解析 binlog，而不是采用业务消息进行数据同步？ 数据表被更改，比如修数据情况，业务消息不会触发，导致无法写入到对应的 Nosql 中造成。数据不一致 顺序性问题无法得到相关保障； 业务消息并不能拿到所有相关的数据进行写入到 nosql 中。 Tip-3：SeqNo 实现方式，为什么不用 binlogoffset？ 因为 cana 实例与 mysql 实例是 1:N（推荐 1:1),而大部分业务场景同一种数据一般会落在同一个实例上，canal 就可以通过该台实例的时间与每秒处理的个数相结合。如：timestamp*10000+counter++，而不用 binlogoffset 的原因是 mysql 的实例挂了话，binlogoffset 可能会乱序。 五、结语 有赞交易订单管理承接了亿级流量的同步任务，面临着众多的需求挑战，从最开始的mysql到如今的产品化的同步任务，从单表同步到多表同步，从单索引到多索引，从增量到全量，都有不同的解决之道，如今新兴搜索中台更是承接亿级搜索和同步流量，如有兴趣，欢迎加入，我们一起共同探讨。

首先,我知道第三方只能创建部分线下类目, 但是我发现的是获取出来的数据有冲突. 下图可见,在官方文档中, "丽人"下面明明有好几个选项,这都是快速创建允许的类目 [图片] [图片] 用获取类目接口获取出来的,却没有这几个 [图片] [图片] 给出的返回结果, 丽人下面有 children 子节点, 有814  820 ..... 等等的id, 但是纵观整个返回的list, 却没有这几个的name. 如果这个是不允许快速创建小程序使用的"线下类目" 那么本问题开头官方给出的文档链接中,却包含了这几个子类目. 我猜他们的id肯定对应的是官方给出的腾讯文档中圈出来的这几个. 所以,这也是线下类目啊,那么到底是能设置还是不能设置呢? 另外必须吐槽一下文档. [图片] 然而实际上却是 categories_list 而不是文档中的 category_list [图片] 业界良心哪里去了? 还有下面这个, 标点符号还是中英文混合的. [图片]

第三方登录模块使开发者能快捷灵活的拥有自己的用户系统，是 LeanCloud 最受欢迎的功能之一。随着第三方平台的演化，特别是微信小程序的流行，LeanCloud 第三方登录模块也一直在改进： v2.0*：增加微信小程序一键登录功能。支持开发者不写任何后端代码实现微信小程序用户系统与 LeanCloud 用户系统的关联。 v3.6：增加 unionid 登录接口。支持开发者使用 unionid 关联一个微信开发者帐号下的多个应用从而共享一套 LeanCloud 用户系统。 这两个功能各自都非常简单可靠，但是其中重叠的部分需求却是一个难题：「如何在小程序中支持 unionid 登录，既能得到 unionid 登录机制的灵活性，又保留一键登录功能的便利性」。 在最近发布的 JavaScript SDK v3.13 中包含了微信小程序 unionid 登录支持。我们根据不同的需求设计了不同的解决方案。 * 这里的版本指开始支持该功能的 JavaScript SDK 版本。 一键登录 LeanCloud 的用户系统支持一键使用微信用户身份登录。要使用一键登录功能，需要先设置小程序的 AppID 与 AppSecret： 1.登录 微信公众平台，在 设置 > 开发设置 中获得 AppID 与 AppSecret。 前往 LeanCloud 控制台 > 组件 > 社交，保存「微信小程序」的 AppID 与 AppSecret。 这样你就可以在应用中使用[代码]AV.User.loginWithWeapp()[代码]方法来使用当前用户身份登录了。 [代码]AV.User.loginWithWeapp().then(user => { this.globalData.user = user; }).catch(console.error); [代码] 使用一键登录方式登录时，LeanCloud 会将该用户的小程序 [代码]openid[代码] 与 [代码]session_key[代码] 等信息保存在对应的 [代码]user.authData.lc_weapp[代码] 属性中，你可以在控制台的 [代码]_User[代码] 表中看到： [代码]{ "authData": { "lc_weapp": { "session_key": "2zIDoEEUhkb0B5pUTzsLVg==", "expires_in": 7200, "openid": "obznq0GuHPxdRYaaDkPOHk785DuA" } } } [代码] 如果用户是第一次使用此应用，调用登录 API 会创建一个新的用户，你可以在 控制台 > 存储 中的 [代码]_User[代码] 表中看到该用户的信息，如果用户曾经使用该方式登录过此应用（存在对应 openid 的用户），再次调用登录 API 会返回同一个用户。 用户的登录状态会保存在客户端中，可以使用 [代码]AV.User.current()[代码] 方法来获取当前登录的用户，下面的例子展示了如何为登录用户保存额外的信息： [代码]// 假设已经通过 AV.User.loginWithWeapp() 登录 // 获得当前登录用户 const user = AV.User.current(); // 调用小程序 API，得到用户信息 wx.getUserInfo({ success: ({userInfo}) => { // 更新当前用户的信息 user.set(userInfo).save().then(user => { // 成功，此时可在控制台中看到更新后的用户信息 this.globalData.user = user; }).catch(console.error); } }); [代码] [代码]authData[代码] 默认只有对应用户可见，开发者可以使用 masterKey 在云引擎中获取该用户的 [代码]openid[代码] 与 [代码]session_key[代码] 进行支付、推送等操作。详情的示例请参考 支付。 小程序的登录态（[代码]session_key[代码]）存在有效期，可以通过 wx.checkSession() 方法检测当前用户登录态是否有效，失效后可以通过调用 [代码]AV.User.loginWithWeapp()[代码] 重新登录。 使用 unionid 微信开放平台使用 unionid 来区分用户的唯一性，也就是说同一个微信开放平台帐号下的移动应用、网站应用和公众帐号（包括小程序），用户的 unionid 都是同一个，而 openid 会是多个。如果你想要实现多个小程序之间，或者小程序与使用微信开放平台登录的应用之间共享用户系统的话，则需要使用 unionid 登录。 要在小程序中使用 unionid 登录，请先确认已经在 微信开放平台 绑定了该小程序 在小程序中有很多途径可以 获取到 unionid。不同的 unionid 获取方式，接入 LeanCloud 用户系统的方式也有所不同。 一键登录时静默获取 unionid 当满足以下条件时，一键登录 API [代码]AV.User.loginWithWeapp()[代码] 能静默地获取到用户的 unionid 并用 unionid + openid 进行匹配登录。 微信开放平台帐号下存在同主体的公众号，并且该用户已经关注了该公众号。 微信开放平台帐号下存在同主体的公众号或移动应用，并且该用户已经授权登录过该公众号或移动应用。 要启用这种方式，需要在一键登录时指定参数 [代码]preferUnionId[代码] 为 true： [代码]AV.User.loginWithWeapp({ preferUnionId: true, }); [代码] 使用 unionid 登录后，用户的 authData 中会增加 _[代码]weixin_unionid[代码] 一项（与 [代码]lc_weapp[代码] 平级）： [代码]{ "authData": { "lc_weapp": { "session_key": "2zIDoEEUhkb0B5pUTzsLVg==", "expires_in": 7200, "openid": "obznq0GuHPxdRYaaDkPOHk785DuA", "unionid": "ox7NLs5BlEqPS4glxqhn5kkO0UUo" }, "_weixin_unionid": { "uid": "ox7NLs5BlEqPS4glxqhn5kkO0UUo" } } } [代码] 用 unionid + openid 登录时，会按照下面的步骤进行用户匹配： 如果已经存在对应 [代码]unionid（authData._weixin_unionid.uid[代码]）的用户，则会直接作为这个用户登录，并将所有信息（[代码]openid[代码]、[代码]session_key[代码]、[代码]unionid[代码] 等）更新到该用户的 [代码]authData.lc_ewapp[代码] 中。 如果不存在匹配 unionid 的用户，但存在匹配 openid（[代码]authData.lc_weapp.openid[代码]）的用户，则会直接作为这个用户登录，并将所有信息（[代码]session_key[代码]、[代码]unionid[代码] 等）更新到该用户的 [代码]authData.lc_ewapp[代码] 中，同时将 [代码]unionid[代码] 保存到 [代码]authData._weixin_unionid.uid[代码] 中。 如果不存在匹配 unionid 的用户，也不存在匹配 openid 的用户，则创建一个新用户，将所有信息（[代码]session_key[代码]、[代码]unionid[代码] 等）更新到该用户的 [代码]authData.lc_ewapp[代码] 中，同时将 [代码]unionid[代码] 保存到 [代码]authData._weixin_unionid.uid[代码] 中。 不管匹配的过程是如何的，最终登录用户的 [代码]authData[代码] 都会是上面这种结构。 LeanTodo Demo 便是使用这种方式登录的，如果你已经关注了其关联的公众号（搜索 AVOSCloud，或通过小程序关于页面的相关公众号链接访问），那么你在登录后会在 LeanTodo Demo 的 设置 - 用户 页面看到当前用户的 [代码]authData[代码] 中已经绑定了 unionid。 [图片] 微信扫描二维码进入 Demo 需要注意的是： 如果用户不符合上述静默获取 unionid 的条件，那么就算指定了 [代码]preferUnionId[代码] 也不会使用 unionid 登录。 如果用户符合上述静默获取 unionid 的条件，但没有指定 [代码]preferUnionId[代码]，那么该次登录不会使用 unionid 登录，但仍然会将获取到的 unionid 作为一般字段写入该用户的 [代码]authData.lc_weapp[代码] 中。此时用户的 [代码]authData[代码] 会是这样的： [代码]{ "authData": { "lc_weapp": { "session_key": "2zIDoEEUhkb0B5pUTzsLVg==", "expires_in": 7200, "openid": "obznq0GuHPxdRYaaDkPOHk785DuA", "unionid": "ox7NLs5BlEqPS4glxqhn5kkO0UUo" } } } [代码] 通过其他方式获取 unionid 后登录 如果开发者自行获得了用户的 unionid（例如通过解密 wx.getUserInfo 获取到的用户信息），可以在小程序中调用 [代码]AV.User.loginWithWeappWithUnionId()[代码] 投入 unionid 完成登录授权： [代码]AV.User.loginWithWeappWithUnionId(unionid, { asMainAccount: true }).then(console.log, console.error); [代码] 通过其他方式获取 unionid 与 openid 后登录 如果开发者希望更灵活的控制小程序的登录流程，也可以自行在服务端实现 unionid 与 openid 的获取，然后调用通用的第三方 unionid 登录接口指定平台为 [代码]lc_weapp[代码] 来登录： [代码]const unionid = ''; const authData = { openid: '', session_key: '' }; const platform = 'lc_weapp'; AV.User.loginWithAuthDataAndUnionId(authData, platform, unionid, { asMainAccount: true }).then(console.log, console.error); [代码] 相对上面提到的一些 Weapp 相关的登录 API，loginWithAuthDataAndUnionId 是更加底层的第三方登录接口，不依赖小程序运行环境，因此这种方式也提供了更高的灵活度： 可以在服务端获取到 unionid 与 openid 等信息后返回给小程序客户端，在客户端调用 [代码]AV.User.loginWithAuthDataAndUnionId[代码] 来登录。 也可以在服务端获取到 unionid 与 openid 等信息后直接调用 [代码]AV.User.loginWithAuthDataAndUnionId[代码] 登录，成功后得到登录用户的 [代码]sessionToken[代码] 后返回给客户端，客户端再使用该 [代码]sessionToken[代码] 直接登录。 关联第二个小程序 这种用法的另一种常见场景是关联同一个开发者帐号下的第二个小程序。 因为一个 LeanCloud 应用默认关联一个微信小程序（对应的平台名称是 [代码]lc_weapp[代码]），使用小程序系列 API 的时候也都是默认关联到 [代码]authData.lc_weapp[代码] 字段上。如果想要接入第二个小程序，则需要自行获取到 unionid 与 openid，然后将其作为一个新的第三方平台登录。这里同样需要用到 [代码]AV.User.loginWithAuthDataAndUnionId[代码] 方法，但与关联内置的小程序平台（[代码]lc_weapp[代码]）有一些不同： 需要指定一个新的 [代码]platform[代码] 需要将 [代码]openid[代码] 保存为 [代码]uid[代码]（内置的微信平台做了特殊处理可以直接用 [代码]openid[代码] 而这里是作为通用第三方 OAuth 平台保存因此需要使用标准的 [代码]uid[代码] 字段）。 这里我们以新的平台 [代码]weapp2[代码] 为例： [代码]const unionid = ''; const openid = ''; const authData = { uid: openid, session_key: '' }; const platform = 'weapp2'; AV.User.loginWithAuthDataAndUnionId(authData, platform, unionid, { asMainAccount: true }).then(console.log, console.error); [代码] 获取 unionid 后与现有用户关联 如果一个用户已经登录，现在通过某种方式获取到了其 unionid（一个常见的使用场景是用户完成了支付操作后在服务端通过 getPaidUnionId 得到了 unionid）希望与之关联，可以在小程序中使用 [代码]AV.User#associateWithWeappWithUnionId()[代码]： [代码]const user = AV.User.current(); // 获取当前登录用户 user.associateWithWeappWithUnionId(unionid, { asMainAccount: true }).then(console.log, console.error); [代码] 启用其他登录方式 上述的登录 API 对接的是小程序的用户系统，所以使用这些 API 创建的用户无法直接在小程序之外的平台上登录。如果需要使用 LeanCloud 用户系统提供的其他登录方式，如用手机号验证码登录、邮箱密码登录等，在小程序登录后设置对应的用户属性即可： [代码]// 小程序登录 AV.User.loginWithWeapp().then(user => { // 设置并保存手机号 user.setMobilePhoneNumber('13000000000'); return user.save(); }).then(user => { // 发送验证短信 return AV.User.requestMobilePhoneVerify(user.getMobilePhoneNumber()); }).then({ // 用户填写收到短信验证码后再调用 AV.User.verifyMobilePhone(code) 完成手机号的绑定 // 成功后用户的 mobilePhoneVerified 字段会被置为 true // 此后用户便可以使用手机号加动态验证码登录了 }).catch(console.error); [代码] 验证手机号码功能要求在 控制台 > 存储 > 设置 > 用户账号 启用「用户注册时，向注册手机号码发送验证短信」。 绑定现有用户 如果你的应用已经在使用 LeanCloud 的用户系统，或者用户已经通过其他方式注册了你的应用（比如在 Web 端通过用户名密码注册），可以通过在小程序中调用 [代码]AV.User#associateWithWeapp()[代码] 来关联已有的账户： [代码]// 首先，使用用户名与密码登录一个已经存在的用户 AV.User.logIn('username', 'password').then(user => { // 将当前的微信用户与当前登录用户关联 return user.associateWithWeapp(); }).catch(console.error); [代码] 更多内容欢迎查看《在微信小程序与小游戏中使用 LeanCloud》。

前段时间收到一个蓝牙设备，需求是控制板子上面的电机，这对于从未接触过硬件的小白来说无疑是一个挑战，然而我是一个喜欢挑战的蓝人，于是开始了我的研究。 我开始各种搜罗Demo，查看文档及各大论坛。 终于，黄天不负苦心人，我成功的连接上了设备，并且获取到了他的服务及特征值，当然，每台外设可用的服务及特征值都是不一样的，而且有些是不可用的，什么 read、write、notify、indicate 要根据自己的操作需求去看哪个特征值支持。每个服务下面都有不同的特征值，每个特征值下面又分出来几个不同的特征值列表，接下来就是根据自己需求筛选了。 支持列表： read：读取低功耗蓝牙设备的特征值的二进制数据值 write：向低功耗蓝牙设备特征值中写入二进制数据 notify || indicate：启用低功耗蓝牙设备特征值变化时的 notify 功能，订阅特征值 这些都选好后该开始向蓝牙设备写入指令，让他动起来了（想想就有些小激动） 不过根据官方提供的方式转换指令并写入的时候，意外发生了！ 我在回调里面打印成功与否的时候，显示成功，但是设备却没人任何反应，于是我又开始找原因（设备通过某个App试过，写入指令后是正常的），又开始了我的搜寻之旅。 之后发现原因是因为我使用的指令转换后超过了20字节，在Api文档中 https://developers.weixin.qq.com/miniprogram/dev/api/wx.writeBLECharacteristicValue.html 标注了建议每次写入不超过20字节，但是也不是强制性的呀，导致我很懵逼，明明返回的是成功。 [图片] 事到如今，只能接着寻找解决方法了，总不能跟他这么耗着呀。接着我的搜寻之旅吧！（废话那么多，重点该来了） 终于，找到种分包的方式，把超过20字节的指令分批发送（当然，没有超过20字节的话，也不影响使用），这边需要注意一下，不能直接连发，需要有一个延迟，然后~完美写入指令，我的小电机动起来了。 整体的流程如下： 打开蓝牙模块 => 搜索蓝牙 => 获取所有已发现的设备 => 连接蓝牙设备 => 获取蓝牙设备的所有服务 => 获取蓝牙设备服务下的所有特征值 => 向蓝牙设备写入指令 => 完成 =>关闭蓝牙模块 行了，不哔哔了。我结合官方提供的Demo修改了一下，添加了一个分包写入，已经打包成代码片段，可以直接使用。 代码片段中服务和特征值这两个地方我写成了固定的，根据自己的需求可以修改下。 [图片] [图片] 核心代码： 延时定时器 格式转换 判断并分包写入 [图片] [图片] 代码片段： https://developers.weixin.qq.com/s/oFJc70mI7o8K 如有不对的地方或者更好的解决方案，还望大佬们及时提出，希望对你们有所帮助。

目前canvas组件中的的方法drawImage中的图片资源只支持图片url的形式，请问能否支持提供base64的形式提供图片资源来画画布？

内容一模一样的，我更新了，他马上更新。。。。

历程 从4月20日开始，起初小程序页面被微信爬虫访问时，会携带特定的 user-agent：mpcrawler 及场景值：1129 附部分IP地址与访问次数： [代码]223.166.222.109 - 1,150[代码] [代码]101.91.60.23 - 1,069[代码] [代码]223.166.222.11 - 1,044[代码] [代码]101.227.139.164 - 1,033[代码] [代码]101.91.60.22 - 1,020[代码] [代码]101.91.60.101 - 983[代码] [代码]223.166.222.108 - 897[代码] [代码]101.91.60.11 - 843[代码] [代码]58.247.206.157 - 266[代码] [代码]58.247.206.142 - 265[代码] [代码]58.247.206.152 - 256[代码] [代码]58.247.206.147 - 240[代码] 此后几天，断断续续有爬虫访问小程序页面 4月25日，收到【日志服务告警】- 短时间内大量415、400的状态码，这次开始很特殊——爬虫即没有user-agent也没有携带场景值 但是这次IP同之前的微信爬虫IP大多重叠，而且referer规则都是：https://servicewechat.com/${app_id}/0/page-frame.html，其中version=0（开发版、体验版以及审核版本），以为是机器人审核，但是也不应该持续触发大量非法请求并且没有携带user-agent 附4月25日 - Nginx日志： [图片] 引用自小程序官方问答Q&A： 网络请求的 referer 是不可以设置的，格式固定为 [代码]https://servicewechat.com/{appid}/{version}/page-frame.html[代码]，其中 [代码]{appid}[代码] 为小程序的 appid，[代码]{version}[代码] 为小程序的版本号，版本号为 0 表示为开发版、体验版以及审核版本，版本号为 devtools 表示为开发者工具，其余为正式版本。 就在今天（4月28日）中午将小程序【页面收录】功能设置为关闭，晚上19～20点18～19点，接口被爬虫1小时内累计调用200w次+ 附4月28日晚上19～20点18～19点 - Nginx日志分析： [图片] 疑问 101.91.60.*、223.166.222.*、58.247.206.*等IP是否为微信官方爬虫IP？ 微信官方爬虫IP有哪些？ 微信爬虫访问是否一定会携带user-agent：mpcrawler 及场景值：1129？

小程序提供了路由功能来实现页面跳转，但是在使用的过程中我们还是发现有些不方便的地方，通过封装，我们可以实现诸如路由管理、简化api等功能。 页面的跳转存在哪些问题呢？ 与接口的调用一样面临url的管理问题； 传递参数的方式不太友好，只能拼装url； 参数类型单一，只支持string。 alias 第一个问题很好解决，我们做一个集中管理，比如新建一个[代码]router/routes.js[代码]文件来实现alias： [代码]// routes.js module.exports = { // 主页 home: '/pages/index/index', // 个人中心 uc: '/pages/user_center/index', }; [代码] 然后使用的时候变成这样： [代码]const routes = require('../../router/routes.js'); Page({ onReady() { wx.navigateTo({ url: routes.uc, }); }, }); [代码] query 第二个问题，我们先来看个例子，假如我们跳转[代码]pages/user_center/index[代码]页面的同时还要传[代码]userId[代码]过去，正常情况下是这么来操作的： [代码]const routes = require('../../router/routes.js'); Page({ onReady() { const userId = '123456'; wx.navigateTo({ url: `${routes.uc}?userId=${userId}`, }); }, }); [代码] 这样确实不好看，我能不能把参数部分单独拿出来，不用拼接到url上呢？ 可以，我们试着实现一个[代码]navigateTo[代码]函数： [代码]const routes = require('../../router/routes.js'); function navigateTo({ url, query }) { const queryStr = Object.keys(query).map(k => `${k}=${query[k]}`).join('&'); wx.navigateTo({ url: `${url}?${queryStr}`, }); } Page({ onReady() { const userId = '123456'; navigateTo({ url: routes.uc, query: { userId, }, }); }, }); [代码] 嗯，这样貌似舒服一点。 参数保真 第三个问题的情况是，当我们传递的参数argument不是[代码]string[代码]，而是[代码]number[代码]或者[代码]boolean[代码]时，也只能在下个页面得到一个[代码]string[代码]值： [代码]// pages/index/index.js Page({ onReady() { navigateTo({ url: routes.uc, query: { isActive: true, }, }); }, }); // pages/user_center/index.js Page({ onLoad(options) { console.log(options.isActive); // => "true" console.log(typeof options.isActive); // => "string" console.log(options.isActive === true); // => false }, }); [代码] 上面这种情况想必很多人都遇到过，而且感到很抓狂，本来就想传递一个boolean，结果不管传什么都会变成string。 有什么办法可以让数据变成字符串之后，还能还原成原来的类型？ 好熟悉，这不就是json吗？我们把要传的数据转成json字符串（[代码]JSON.stringify[代码]），然后在下个页面把它转回json数据（[代码]JSON.parse[代码]）不就好了嘛！ 我们试着修改原来的[代码]navigateTo[代码]： [代码]const routes = require('../../router/routes.js'); function navigateTo({ url, data }) { const dataStr = JSON.stringify(data); wx.navigateTo({ url: `${url}?jsonStr=${dataStr}`, }); } Page({ onReady() { navigateTo({ url: routes.uc, data: { isActive: true, }, }); }, }); [代码] 这样我们在页面中接受json字符串并转换它： [代码]// pages/user_center/index.js Page({ onLoad(options) { const json = JSON.parse(options.jsonStr); console.log(json.isActive); // => true console.log(typeof json.isActive); // => "boolean" console.log(json.isActive === true); // => true }, }); [代码] 这里其实隐藏了一个问题，那就是url的转义，假如json字符串中包含了类似[代码]?[代码]、[代码]&[代码]之类的符号，可能导致我们参数解析出错，所以我们要把json字符串encode一下： [代码]function navigateTo({ url, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } // pages/user_center/index.js Page({ onLoad(options) { const json = JSON.parse(decodeURIComponent(options.encodedData)); console.log(json.isActive); // => true console.log(typeof json.isActive); // => "boolean" console.log(json.isActive === true); // => true }, }); [代码] 这样使用起来不方便，我们封装一下，新建文件[代码]router/index.js[代码]： [代码]const routes = require('./routes.js'); function navigateTo({ url, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } function extract(options) { return JSON.parse(decodeURIComponent(options.encodedData)); } module.exports = { routes, navigateTo, extract, }; [代码] 页面中我们这样来使用： [代码]const router = require('../../router/index.js'); // page home Page({ onLoad(options) { router.navigateTo({ url: router.routes.uc, data: { isActive: true, }, }); }, }); // page uc Page({ onLoad(options) { const json = router.extract(options); console.log(json.isActive); // => true console.log(typeof json.isActive); // => "boolean" console.log(json.isActive === true); // => true }, }); [代码] route name 这样貌似还不错，但是[代码]router.navigateTo[代码]不太好记，[代码]router.routes.uc[代码]有点冗长，我们考虑把[代码]navigateTo[代码]换成简单的[代码]push[代码]，至于路由，我们可以使用[代码]name[代码]的方式来替换原来[代码]url[代码]参数： [代码]const routes = require('./routes.js'); function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const url = routes[name]; wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } function extract(options) { return JSON.parse(decodeURIComponent(options.encodedData)); } module.exports = { push, extract, }; [代码] 在页面中使用： [代码]const router = require('../../router/index.js'); Page({ onLoad(options) { router.push({ name: 'uc', data: { isActive: true, }, }); }, }); [代码] navigateTo or switchTab 页面跳转除了navigateTo之外还有switchTab，我们是不是可以把这个差异抹掉？答案是肯定的，如果我们在配置routes的时候就已经指定是普通页面还是tab页面，那么程序完全可以切换到对应的跳转方式。 我们修改一下[代码]router/routes.js[代码]，假设home是一个tab页面： [代码]module.exports = { // 主页 home: { type: 'tab', path: '/pages/index/index', }, uc: { path: '/pages/a/index', }, }; [代码] 然后修改[代码]router/index.js[代码]中[代码]push[代码]的实现： [代码]function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const route = routes[name]; if (route.type === 'tab') { wx.switchTab({ url: `${route.path}`, // 注意tab页面是不支持传参的 }); return; } wx.navigateTo({ url: `${route.path}?encodedData=${dataStr}`, }); } [代码] 搞定，这样我们一个[代码]router.push[代码]就能自动切换两种跳转方式了，而且之后一旦页面类型有变动，我们也只需要修改[代码]route[代码]的定义就可以了。 直接寻址 alias用着很不错，但是有一点挺麻烦得就是每新建一个页面都要写一个alias，即使没有别名的需要，我们是不是可以处理一下，如果在alias没命中，那就直接把name转化成url？这也是阔以的。 [代码]function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const route = routes[name]; const url = route ? route.path : name; if (route.type === 'tab') { wx.switchTab({ url: `${url}`, // 注意tab页面是不支持传参的 }); return; } wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } [代码] 在页面中使用： [代码]Page({ onLoad(options) { router.push({ name: 'pages/user_center/a/index', data: { isActive: true, }, }); }, }); [代码] 注意，为了方便维护，我们规定了每个页面都必须存放在一个特定的文件夹，一个文件夹的当前路径下只能存在一个index页面，比如[代码]pages/index[代码]下面会存放[代码]pages/index/index.js[代码]、[代码]pages/index/index.wxml[代码]、[代码]pages/index/index.wxss[代码]、[代码]pages/index/index.json[代码]，这时候你就不能继续在这个文件夹根路径存放另外一个页面，而必须是新建一个文件夹来存放，比如[代码]pages/index/pageB/index.js[代码]、[代码]pages/index/pageB/index.wxml[代码]、[代码]pages/index/pageB/index.wxss[代码]、[代码]pages/index/pageB/index.json[代码]。 这样是能实现功能，但是这个name怎么看都跟alias风格差太多，我们试着定义一套转化规则，让直接寻址的name与alias风格统一一些，[代码]pages[代码]和[代码]index[代码]其实我们可以省略掉，[代码]/[代码]我们可以用[代码].[代码]来替换，那么原来的name就变成了[代码]user_center.a[代码]： [代码]Page({ onLoad(options) { router.push({ name: 'user_center.a', data: { isActive: true, }, }); }, }); [代码] 我们再来改进[代码]router/index.js[代码]中[代码]push[代码]的实现： [代码]function push({ name, data }) { const dataStr = encodeURIComponent(JSON.stringify(data)); const route = routes[name]; const url = route ? route.path : `pages/${name.replace(/\./g, '/')}/index`; if (route.type === 'tab') { wx.switchTab({ url: `${url}`, // 注意tab页面是不支持传参的 }); return; } wx.navigateTo({ url: `${url}?encodedData=${dataStr}`, }); } [代码] 这样一来，由于支持直接寻址，跳转home和uc还可以写成这样： [代码]router.push({ name: 'index', // => /pages/index/index }); router.push({ name: 'user_center', // => /pages/user_center/index }); [代码] 这样一来，除了一些tab页面以及特定的路由需要写alias之外，我们也不需要新增一个页面就写一条alias这么麻烦了。 其他 除了上面介绍的navigateTo和switchTab外，其实还有[代码]wx.redirectTo[代码]、[代码]wx.navigateBack[代码]以及[代码]wx.reLaunch[代码]等，我们也可以做一层封装，过程雷同，所以我们就不再一个个介绍，这里贴一下最终简化后的api以及原生api的映射关系： [代码]router.push => wx.navigateTo router.replace => wx.redirectTo router.pop => wx.navigateBack router.relaunch => wx.reLaunch [代码] 最终实现已经在发布在github上，感兴趣的朋友可以移步了解：mp-router。

正文从下面开始。 今天的小技巧是使用纯 CSS 生成火焰，逼真一点的火焰。 嗯，长什么样子？在 CodePen 上输入关键字 [代码]CSS Fire[代码]，能找到这样的： [图片] 或者这样的： [图片] 我们希望，仅仅使用 CSS ，效果能再更进一步吗？能不能是这样子： [图片] 如何实现 嗯，我们需要使用 [代码]filter[代码] + [代码]mix-blend-mode[代码] 的组合来完成。 很多 CSS 华而不实的效果都是 [代码]filter[代码] + [代码]mix-blend-mode[代码]，很有意思，但是业务中根本用不上，当然多了解了解总没坏处。 如上图，整个蜡烛的骨架， 除去火焰的部分很简单，掠过不讲。主要来看看火焰这一块如何生成，并且如何赋予动画效果。 Step 1: filter blur && filter contrast 模糊滤镜叠加对比度滤镜产生的融合效果。 单独将两个滤镜拿出来，它们的作用分别是： [代码]filter: blur()[代码]： 给图像设置高斯模糊效果。 [代码]filter: contrast()[代码]： 调整图像的对比度。 但是，当他们“合体”的时候，产生了奇妙的融合现象。 先来看一个简单的例子： [图片] 仔细看两圆相交的过程，在边与边接触的时候，会产生一种边界融合的效果，通过对比度滤镜把高斯模糊的模糊边缘给干掉，利用高斯模糊实现融合效果。 利用上述 [代码]filter blur & filter contrast[代码]，我们要先生成一个类似火焰形状的三角形。（略去过程） 这里类似火焰形状的三角形的具体实现过程，在这篇文章有详细的讲解：你所不知道的 CSS 滤镜技巧与细节 [图片] 父元素添加 [代码]filter: blur(5px) contrast(20)[代码]，会变成这样： [图片] Step 2: 火焰粒子动画 看着已经有点样子了，接下来是火焰动画，我们先去掉父元素的 [代码]filter: blur(5px) contrast(20)[代码] ，然后继续 。 这里也是利用了 [代码]filter[代码] 的融合效果，我们在上述火焰中，利用 SASS 随机均匀分布大量大小不一的圆形棕色 div ，隐匿在火焰三角内部，大概是这样： [图片] 接下来，我们再利用 SASS，给中间每个小圆赋予一个从下往上逐渐消失的动画，并且均匀赋予不同的 [代码]animation-delay[代码]，看起来会是这样： [图片] OK，最重要的一步，我们再把父元素的 [代码]filter: blur(5px) contrast(20)[代码] 打开，神奇的火焰效果就出来了： [图片] Step 3: mix-blend-mode 润色 当然，上述效果已经很不错了。经过各种尝试，调整参数，最后我发现加上 [代码]mix-blend-mode: screen[代码] 混合模式，效果更好，得到头图上面的最终效果如下： [图片] 完整源码在我的 CodePen 上：CodePen Demo – CSS Fire 另外一些效果 当然，掌握了这种方法后，这种生成火焰的技巧也可以迁移到其他效果去。下图是我鼓捣到另外一个小 Demo，当 hover 到元素的时候，产生火焰效果： [图片] CodePen Demo – Hover Fire 嗯，这些其实都是对滤镜及混合模式的一些搭配运用。按照惯例，肯定有人会留言喷了，整这些花里胡哨的有什么用，性能又不好，业务中敢上不把你的腿给打骨折。 [图片] 于我而言，虚心接受各种批评质疑及各种不同的观点，当然我是觉得搞技术一方面是实用，另一方面是兴趣使然，自娱自乐。希望喷子绕道~ 回到正题，了解了这种黏糊糊湿答答的技巧后，还可以折腾出其他很多有意思的效果，当然可能需要更多的去尝试，如下面使用一个标签实现的滴水效果： [图片] CodePen Demo – 单标签实现滴水效果 值得注意的细节点 动画虽然美好，但是具体使用的过程中，仍然有一些需要注意的地方： CSS 滤镜可以给同个元素同时定义多个，例如 [代码]filter: blur(5px) contrast(150%) brightness(1.5)[代码] ，但是滤镜的先后顺序不同产生的效果也是不一样的； 也就是说，使用 [代码]filter: blur(5px) contrast(150%) brightness(1.5)[代码] 和 [代码]filter: brightness(1.5) contrast(150%) blur(5px)[代码] 处理同一张图片，得到的效果是不一样的，原因在于滤镜的色值处理算法对图片处理的先后顺序。 滤镜动画需要大量的计算，不断的重绘页面，属于非常消耗性能的动画，使用时要注意使用场景。记得开启硬件加速及合理使用分层技术； [代码]blur()[代码] 混合 [代码]contrast()[代码] 滤镜效果，设置不同的颜色会产生不同的效果，这个颜色叠加的具体算法暂时没有找到很具体的规则细则，使用时比较好的方法是多尝试不同颜色，观察取最好的效果； 细心的读者会发现上述效果都是基于黑色底色进行的，动手尝试将底色改为白色，效果会大打折扣。 最后 本文只是简单的介绍了整个思路过程，许多 CSS 代码细节，调试过程没有展现出来。主要几个 CSS 属性默认大家已经掌握了大概，阅读后可以自行去了解补充更多细节： [代码]filter[代码] [代码]mix-blend-mode[代码] 更多精彩 CSS 技术文章汇总在我的 Github – iCSS ，持续更新，欢迎点个 star 订阅收藏。 好了，本文到此结束，希望对你有帮助 😃 如果还有什么疑问或者建议，可以多多交流，原创文章，文笔有限，才疏学浅，文中若有不正之处，万望告知。 最后，新开通的公众号求关注，形式希望是更短的篇幅，质量更高一些的技巧类文章，包括但不局限于 CSS： [图片]

     小程序插屏广告指小程序在特定场景切换时以卡片方式弹出的广告形式。当用户触发流量主指定场景时，插屏广告就会自动向用户展现，目前向非游戏类目全量流量主开放，小游戏类目即将启动内测。       此外激励式视频广告也向非游戏类小程序流量主开放，详见《激励式视频广告开通指引》。 [图片] [图片][图片] [图片][图片][图片][图片][图片] [图片] [图片] [图片]

前言 最近一年多一直在做前端的一些测试，从小程序到店铺装修，基本都是纯前端的工作，刚开始从后端测试转为前端测试的时候，对前端东西茫然无感，而且团队内没有人做过纯前端的测试工作，只能一边踩坑一边总结经验，然后将容易出现问题的点形成体系、不断总结摸索，最终形成了目前的一套前端测试解决方案。在此，将有赞的前端质量保障体系进行总结，希望和大家一起交流。 先来全局看下有赞前端的技术架构和针对每个不同的层次，主要做了哪些保障质量的事情： [图片] [图片] 有赞的 Node 技术架构分为业务层、基础框架层、通用组件和基础服务层，我们日常比较关注的是基础框架、通用组件和业务层代码。Node 业务层做了两件事情，一是提供页面渲染的 client 层，用于和 C 端用户交互，包括样式、行为 js 等；二是提供数据服务的 server 层，用于组装后台提供的各种接口，完成面向 C 端的接口封装。 对于每个不同的层，我们都做了一些事情来保障质量，包括： 针对整个业务层的 UI 自动化、核心接口|页面拨测； 针对 client 层的 sentry 报警； 针对 server 层的接口测试、业务报警； 针对基础框架和通用组件的单元测试； 针对通用组件变更的版本变更报警； 针对线上发布的流程规范、用例维护等。 下面就来分别讲一下这几个维度的质量保障工作。 一、UI 自动化 很多人会认为，UI 自动化维护成本高、性价比低，但是为什么在有赞的前端质量保证体系中放在了最前面呢？ 前端重用户交互，单纯的接口测试、单元测试不能真实反映用户的操作路径，并且从以往的经验中总结得出，因为各种不可控因素导致的发布 A 功能而 B 功能无法使用，特别是核心简单场景的不可用时有出现，所以每次发布一个应用前，都会将此应用提供的核心功能执行一遍，那随着业务的不断积累，需要回归的测试场景也越来越多，导致回归的工作量巨大。为了降低人力成本，我们亟需通过自动化手段释放劳动力，所以将核心流程回归的 UI 自动化提到了最核心地位。 当然，UI 自动化的最大痛点确实是维护成本，为降低维护成本，我们将页面分为组件维度、页面维度，并提供统一的包来处理公用组件、特殊页面的通用逻辑，封装通用方法等，例如初始化浏览器信息、环境选择、登录、多网点切换、点击、输入、获取元素内容等等，业务回归用例只需要关注自己的用例操作步骤即可。 1、框架选择 – puppeteer[1]，它是由 Chrome 维护的 Node 库，基于 DevTools 协议来驱动 chrome 或者 chromium 浏览器运行，支持 headless 和 non-headless 两种方式。官网提供了非常丰富的文档，简单易学。 UI 自动化框架有很多种，包括 selenium、phantom；对比后发现 puppeteer 比较轻量，只需要增加一个 npm 包即可使用；它是基于事件驱动的方式，比 selenium 的等待轮询更稳当、性能更佳；另外，它是 chrome 原生支持，能提供所有 chrome 支持的 api，同时我们的业务场景只需要覆盖 chrome，所以它是最好的选择。 – mocha[2] + mochawesome[3]，mocha 是比较主流的测试框架，支持 beforeEach、before、afterEach、after 等钩子函数，assert 断言，测试套件，用例编排等。 mochawesome 是 mocha 测试框架的第三方插件，支持生成漂亮的 html/css 报告。 js 测试框架同样有很多可以选择，mocha、ava、Jtest 等等，选择 mocha 是因为它更灵活，很多配置可以结合第三方库，比如 report 就是结合了 mochawesome 来生成好看的 html 报告；断言可以用 powser-assert 替代。 2、脚本编写 封装基础库 封装 pc 端、h5 端浏览器的初始化过程 封装 pc 端、h5 端登录统一处理 封装页面模型和组件模型 封装上传组件、日期组件、select 组件等的统一操作方法 封装 input、click、hover、tap、scrollTo、hover、isElementShow、isElementExist、getElementVariable 等方法 提供根据 “html 标签>>页面文字” 形式获取页面元素及操作方法的统一支持 封装 baseTest，增加用例开始、结束后的统一操作 封装 assert，增加断言日志记录 业务用例 安装基础库 编排业务用例 3、执行逻辑 分环境执行 增加预上线环境代码变更触发、线上环境自动执行 监控源码变更 增加 gitlab webhook，监控开发源码合并 master 时自动在预上线环境执行 增加 gitlab webhook，监控测试用例变更时自动在生产环境执行 每日定时执行 增加 crontab，每日定时执行线上环境 [图片] [图片] [图片] [图片] 二、接口测试 接口测试主要针对于 Node 的 server 层，根据我们的开发规范，Node 不做复杂的业务逻辑，但是需要将服务化应用提供 dubbo 接口进行一次转换，或将多个 dubbo 接口组合起来，提供一个可供 h5/小程序渲染数据的 http 接口，转化过程就带来了各种数据的获取、组合、转换，形成了新的端到端接口。这个时候单单靠服务化接口的自动化已经不能保障对上层接口的全覆盖，所以我们针对 Node 接口也进行自动化测试。为了使用测试内部统一的测试框架，我们通过 java 去请求 Node 提供的 http 接口，那么当用例都写好之后，该如何评判接口测试的质量？是否完全覆盖了全部业务逻辑呢？此时就需要一个行之有效的方法来获取到测试的覆盖情况，以检查有哪些场景是接口测试中未覆盖的，做到更好的查漏补缺。 – istanbul[4] 是业界比较易用的 js 覆盖率工具，它利用模块加载的钩子计算语句、行、方法和分支覆盖率，以便在执行测试用例时透明的增加覆盖率。它支持所有类型的 js 覆盖率，包括单元测试、服务端功能测试以及浏览器测试。 但是，我们的接口用例写在 Java 代码中，通过 Http 请求的方式到达 Node 服务器，非 js 单测，也非浏览器功能测试，如何才能获取到 Node 接口的覆盖率呢？ 解决办法是增加 cover 参数：–handle-sigint，通过增加 --handle-sigint 参数启动服务，当服务接收到一个 SIGINT 信号（linux 中 SIGINT 关联了 Ctrl+C），会通知 istanbul 生成覆盖率。这个命令非常适合我们，并且因此形成了我们接口覆盖率的一个模型： [代码]1. istanbule --handle-sigint 启动服务 2. 执行测试用例 3. 发送 SIGINT结束istanbule，得到覆盖率 [代码] 最终，解决了我们的 Node 接口覆盖率问题，并通过 jenkins 持续集成来自动构建 [图片] [图片] [图片] 当然，在获取覆盖率的时候有需求文件是不需要统计的，可以通过在根路径下增加 .istanbule.yml 文件的方式，来排除或者指定需要统计覆盖率的文件 [代码]verbose: false instrumentation: root: . extensions: - .js default-excludes: true excludes:['**/common/**','**/app/constants/**','**/lib/**'] embed-source: false variable: __coverage__ compact: true preserve-comments: false complete-copy: false save-baseline: false baseline-file: ./coverage/coverage-baseline.json include-all-sources: false include-pid: false es-modules: false reporting: print: summary reports: - lcov dir: ./coverage watermarks: statements: [50, 80] lines: [50, 80] functions: [50, 80] branches: [50, 80] report-config: clover: {file: clover.xml} cobertura: {file: cobertura-coverage.xml} json: {file: coverage-final.json} json-summary: {file: coverage-summary.json} lcovonly: {file: lcov.info} teamcity: {file: null, blockName: Code Coverage Summary} text: {file: null, maxCols: 0} text-lcov: {file: lcov.info} text-summary: {file: null} hooks: hook-run-in-context: false post-require-hook: null handle-sigint: false check: global: statements: 0 lines: 0 branches: 0 functions: 0 excludes: [] each: statements: 0 lines: 0 branches: 0 functions: 0 excludes: [] [代码] 三、单元测试 单元测试在测试分层中处于金字塔最底层的位置，单元测试做的比较到位的情况下，能过滤掉大部分的问题，并且提早发现 bug，也可以降低 bug 成本。推行一段时间的单测后发现，在有赞的 Node 框架中，业务层的 server 端只做接口组装，client 端面向浏览器，都不太适合做单元测试，所以我们只针对基础框架和通用组件进行单测，保障基础服务可以通过单测排除大部分的问题。比如基础框架中店铺通用信息服务，单测检查店铺信息获取；比如页面级商品组件，单测检查商品组件渲染的 html 是否和原来一致。 单测方案试行了两个框架： Jest[5] ava[6] 比较推荐的是 Jest 方案，它支持 Matchers 方式断言；支持 Snapshot Testing，可测试组件类代码渲染的 html 是否正确；支持多种 mock，包括 mock 方法实现、mock 定时器、mock 依赖的 module 等；支持 istanbule，可以方便的获取覆盖率。 总之，前端的单测方案也越来越成熟，需要前端开发人员更加关注 js 单测，将 bug 扼杀在摇篮中。 四、基础库变更报警 上面我们已经对基础服务和基础组件进行了单元测试，但是单测也不能完全保证基础库的变更完全没有问题，伴随着业务层引入新版本的基础库，bug 会进一步带入到业务层，最终影响 C 端用户的正常使用。那如何保障每次业务层引入新版本的基础库之后能做到全面的回归？如何让业务测试同学对基础库变更更加敏感呢？针对这种情况，我们着手做了一个基础库版本变更的小工具。实现思路如下： [代码]1. 对比一次 master 代码的提交或 merge 请求，判断 package.json 中是否有特定基础库版本变更 2. 将对应基础库的前后两个版本的代码对比发送到测试负责人 3. 根据 changelog 判断此次回归的用例范围 4. 增加 gitlab webhook，只有合并到合并发布分支或者 master 分支的代码才触发检查 [代码] 这个小工具的引入能及时通知测试人员针对什么需求改动了基础组件，以及这次基础组件的升级主要影响了哪些方面，这样能避免相对黑盒的测试。 第一版实现了最简功能，后续再深挖需求，可以做到前端代码变更的精准测试。 [图片] 五、sentry 报警 在刚接触前端测试的时候，js 的报错没有任何追踪，对于排查问题和定位问题有很大困扰。因此我们着手引入了 sentry 报警监控，用于监控线上环境 js 的运行情况。 – sentry[7] 是一款开源的错误追踪工具，它可以帮助开发者实时监控和修复崩溃。 开始我们接入的方式比较简单粗暴，直接全局接入，带来的问题是报警信息非常庞大，全局上报后 info、warn 信息都会打出来。 更改后，使用 sentry 的姿势是： sentry 的全局信息上报，并进行筛选 错误类型: TypeError 或者 ReferenceError 错误出现用户 > 1k 错误出现在 js 文件中 出现错误的店铺 > 2家 增加核心业务异常流程的主动上报 最终将筛选后的错误信息通过邮件的形式发送给告警接收人，在固定的时间集中修复。 [图片] [图片] 六、业务报警 除了 sentry 监控报警，Node 接口层的业务报警同样是必不可少的一部分，它能及时发现 Node 提供的接口中存在的业务异常。这部分是开发和运维同学做的，包括在 Node 框架底层接入日志系统；在业务层正确的上报错误级别、错误内容、错误堆栈信息；在日志系统增加合理的告警策略，超过阈值之后短信、电话告警，以便于及时发现问题、排查问题。 业务告警是最能快速反应生产环境问题的一环，如果某次发布之后发生告警，我们第一时间选择回滚，以保证线上的稳定性。 七、约定规范 除了上述的一些测试和告警手段之外，我们也做了一些流程规范、用例维护等基础建设，包括： 发布规范 多个日常分支合并发布 限制发布时间 规范发布流程 整理自测核心检查要点 基线用例库 不同业务 P0 核心用例定期更新 项目用例定期更新到业务回归用例库 线上问题场景及时更新到回归用例库 目前有赞的前端测试套路基本就是这样，当然有些平时的努力没有完全展开，例如接口测试中增加返回值结构体对比；增加线上接口或页面的拨测[8]；给开发进行自测用例设计培训等等。也还有很多新功能探索中，如接入流量对比引擎，将线上流量导到预上线环境，在代码上线前进行对比测试；增加UI自动化的截图对比；探索小程序的UI自动化等等。 参考链接 [1] https://github.com/GoogleChrome/puppeteer [2] https://www.npmjs.com/package/mocha [3] https://www.npmjs.com/package/mochawesome [4] https://github.com/gotwarlost/istanbul [5] https://github.com/facebook/jest [6] https://github.com/avajs/ava [7] https://docs.sentry.io [8] https://tech.youzan.com/youzan-online-active-testing/

前言 在阿里和腾讯工作了6年，当了3年的前端面试官，把阿里和腾讯常问的面试题与答案汇总在我的Github中。希望对大家有所帮助，助力大家进入自己理想的企业。 项目地址是：https://github.com/airuikun/Weekly-FE-Interview 如果你在阿里和腾讯面试的时候遇到了什么不懂的问题，欢迎给我提issue，我会把答案和考点都列出来，公布在下一期的面试周刊里。 面试题精选 大家如果去阿里和腾讯面试过，就会发现，在网上刷了很多的前端面试题，但是去大厂面试的时候还是一头雾水，那是因为那些在网上一搜就能搜出来的题，大厂的面试官基本看不上，他们都会问一些开放题，在回答开放题的过程中，就能摸清你知识技能的广度和深度，所以本期会加入几道我在面试候选人常用的开放题，供大家学习和思考。 我把下面每道题的难度高低，和对标了阿里和腾讯的多少职级，都写上去了，大家可以参考一下自己是什么职级。 第 1 题：如何劫持https的请求，提供思路 难度：阿里p6+ ~ p7、腾讯t23 ~ t31 很多人在google上搜索“前端面试 + https详解”，把答案倒背如流，但是问到如何劫持https请求的时候就一脸懵逼，是因为还是停留在https理论性阶段。 想告诉大家的是，就算是https，也不是绝对的安全，以下提供一个本地劫持https请求的简单思路。 模拟中间人攻击，以百度为例 先用OpenSSL查看下证书，直接调用openssl库识别目标服务器支持的SSL/TLS cipher suite [代码] openssl s_client -connect www.baidu.com:443 [代码] 用sslcan识别ssl配置错误，过期协议，过时cipher suite和hash算法 [代码] sslscan -tlsall www.baidu.com:443 [代码] 分析证书详细数据 [代码] sslscan -show-certificate --no-ciphersuites www.baidu.com:443 [代码] 生成一个证书 [代码] openssl req -new -x509 -days 1096 -key ca.key -out ca.crt [代码] 开启路由功能 [代码] sysctl -w net.ipv4.ip_forward=1 [代码] 写转发规则，将80、443端口进行转发给8080和8443端口 [代码] iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443 [代码] 最后使用arpspoof进行arp欺骗 如果你有更好的想法或疑问，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/11 第 2 题：前端如何进行seo优化 难度：阿里p5、腾讯t21 合理的title、description、keywords：搜索对着三项的权重逐个减小，title值强调重点即可；description把页面内容高度概括，不可过分堆砌关键词；keywords列举出重要关键词。 语义化的HTML代码，符合W3C规范：语义化代码让搜索引擎容易理解网页 重要内容HTML代码放在最前：搜索引擎抓取HTML顺序是从上到下，保证重要内容一定会被抓取 重要内容不要用js输出：爬虫不会执行js获取内容 少用iframe：搜索引擎不会抓取iframe中的内容 非装饰性图片必须加alt 提高网站速度：网站速度是搜索引擎排序的一个重要指标 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/12 第 3 题：前后端分离的项目如何seo 难度：阿里p6 ~ p6+、腾讯t22 ~ t23 使用prerender。但是回答prerender，面试官肯定会问你，如果不用prerender，让你直接去实现，好的，请看下面的第二个答案。 先去 https://www.baidu.com/robots.txt 找出常见的爬虫，然后在nginx上判断来访问页面用户的User-Agent是否是爬虫，如果是爬虫，就用nginx方向代理到我们自己用nodejs + puppeteer实现的爬虫服务器上，然后用你的爬虫服务器爬自己的前后端分离的前端项目页面，增加扒页面的接收延时，保证异步渲染的接口数据返回，最后得到了页面的数据，返还给来访问的爬虫即可。 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/13 第 4 题：简单实现async/await中的async函数 难度：阿里p6 ~ p6+、腾讯t22 ~ t23 async 函数的实现原理，就是将 Generator 函数和自动执行器，包装在一个函数里 [代码]function spawn(genF) { return new Promise(function(resolve, reject) { const gen = genF(); function step(nextF) { let next; try { next = nextF(); } catch (e) { return reject(e); } if (next.done) { return resolve(next.value); } Promise.resolve(next.value).then( function(v) { step(function() { return gen.next(v); }); }, function(e) { step(function() { return gen.throw(e); }); } ); } step(function() { return gen.next(undefined); }); }); } [代码] 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/14 第 5 题：1000-div问题 难度：阿里p5 ~ p6、腾讯t21 ~ t22 一次性插入1000个div，如何优化插入的性能 使用Fragment [代码] var fragment = document.createDocumentFragment(); fragment.appendChild(elem); [代码] 向1000个并排的div元素中，插入一个平级的div元素，如何优化插入的性能 先display:none 然后插入 再display:block 赋予key，然后使用virtual-dom，先render，然后diff，最后patch 脱离文档流，用GPU去渲染，开启硬件加速 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/15 第 6 题：（开放题）2万小球问题：在浏览器端，用js存储2万个小球的信息，包含小球的大小，位置，颜色等，如何做到对这2万条小球信息进行最优检索和存储 难度：阿里p7、腾讯t31 你面试阿里和腾讯，能否上p7和t31，就看你对开放题能答有多深和多广。 这题目考察你如何在浏览器端中进行大数据的存储优化和检索优化。 如果你仅仅只是答用数组对象存储了2万个小球信息，然后用for循环去遍历进行索引，那是远远不够的。 这题要往深一点走，用特殊的数据结构和算法进行存储和索引。 然后进行存储和速度的一个权衡和对比，最终给出你认为的最优解。 我提供几个能触及阿里p7和腾讯t31级别的思路： 用ArrayBuffer实现极致存储 哈夫曼编码 + 字典查询树实现更优索引 用bit-map实现大数据筛查 用hash索引实现简单快捷的检索 用IndexedDB实现动态存储扩充浏览器端虚拟容量 用iframe的漏洞实现浏览器端localStorage无限存储，实现2千万小球信息存储 这种开放题答案不唯一，也不会要你现场手敲代码去实现，但是思路一定要行得通，并且是能打动面试官的思路，如果大家有更好的idea，欢迎大家到我的github里补充：https://github.com/airuikun/Weekly-FE-Interview/issues/16 第 7 题：（开放题）接上一题如何尽可能流畅的实现这2万小球在浏览器中，以直线运动的动效显示出来 难度：阿里p6+ ~ p7、腾讯t23 ~ t31 这题考察对大数据的动画显示优化，当然方法有很多种。 但是你有没有用到浏览器的高级api？ 你还有没有用到浏览器的专门针对动画的引擎？ 或者你对3D的实践和优化，都可以给面试官展示出来。 提供几个思路： 使用GPU硬件加速 使用webGL 使用assembly辅助计算，然后在浏览器端控制动画帧频 用web worker实现javascript多线程，分块处理小球 用单链表树算法和携程机制，实现任务动态分割和任务暂停、恢复、回滚，动态渲染和处理小球 如果大家有更好的idea，欢迎大家到我的github里补充：https://github.com/airuikun/Weekly-FE-Interview/issues/17 第 8 题：（开放题）100亿排序问题：内存不足，一次只允许你装载和操作1亿条数据，如何对100亿条数据进行排序。 难度：阿里p6+ ~ p7、腾讯t23 ~ t31 这题是考察算法和实际问题结合的一个问题 众所周知，腾讯玩的是社交，用户量极大。很多场景的数据量都是百亿甚至千亿级别。 那么如何对这些数据进行高效的操作呢，可以通过这题考察出来。 以前老听说很多人问，前端学算法没有用，考算法都是垃圾，面不出候选人的能力 其实。。。老哥实话告诉你，当你在做前端需要用到crc32、并查集、字典树、哈夫曼编码、LZ77之类东西的时候 已经是涉及到框架实现和极致优化层面了 那时你就已经到了另外一个前端高阶境界了 所以不要抵触算法，可能只是我们目前的眼界和能力，还没触及到那个层级 我前面已经公布了两道开放题的答案了，相信大家已经有所参悟。我觉得在思考开放题的过程中，会有很多意想不到的成长，所以我建议这道题大家可以尝试自己思考一下。本题答案会在周五公布到我的github上。 对应的github地址为：https://github.com/airuikun/Weekly-FE-Interview/issues/18 第 9 题：（开放题）a.b.c.d和a[‘b’][‘c’][‘d’]，哪个性能更高 难度：阿里p7 ~ p7+、腾讯t31 ~ t32 别看这题，题目上每个字都能看懂，但是里面涉及到的知识，暗藏杀鸡 这题要往深处走，会涉及ast抽象语法树、编译原理、v8内核对原生js实现问题 直接对标阿里p7 ~ p7+和腾讯t31 ~ t32职级，我觉得这个题是这篇文章里最难的一道题，所以我放在了开放题中的最后一题 大家多多思考，本题答案会在周五公布到我的github上 对应的github地址为：https://github.com/airuikun/Weekly-FE-Interview/issues/19 第 10 题：git时光机问题 难度：阿里p5 ~ p6+、腾讯t21 ~ t23 现在大厂，已经全部都是用git了，基本没人使用svn了 很多面试候选人对git只会commit、pull、push 但是有没有使用过reflog、cherry-pick等等，这些都很能体现出来你对代码管理的灵活程度和代码质量管理。 针对git时光机经典问题，我专门写了一个文章，轻松搞笑通俗易懂，大家可以看一下，放松放松，同时也能学到对git的时光机操作《git时光机》 结语 本人还写了一些前端进阶知识的文章，如果觉得不错可以点个star。 blog项目地址是：https://github.com/airuikun/blog 我是小蝌蚪，腾讯高级前端工程师，跟着我一起每周攻克几个前端技术难点。希望在小伙伴前端进阶的路上有所帮助，助力大家进入自己理想的企业。 交流 欢迎关注我的微信公众号，微信扫下面二维码或搜索“前端屌丝”，讲述了一个前端屌丝逆袭的心路历程，共勉。 [图片]

点击查看：小打卡 | 如何基于微信原生构建应用级小程序底层架构（上）装饰模式[图片]                                            可能有朋友会好奇装饰器和我们接下来要做的原生函数扩展有什么关系？ 先看下装饰模式的定义：在不改变原函数的基础上，附加一些额外的功能 方便更好的理解 创建一个函数，然后将存在originF这个变量里，并对它重新赋值，最后执行，最后的执行直接结果是什么？ hello world!! 这样做的好处是什么，我们对函数f添加了一个新的功能，但是我们没有对原函数进行任何的修改 那么对于小程序的应用 照猫画虎一下，同样的将小程序原生的Page函数存起来，再重新赋值，看下结果，发现Page执行的时候每次都会console这句话，我这里有两个未分包的页面，就执行了2次 [图片]                                            回归到刚开始需要解决的问题，“多个页面pv，uv如何监控，不可能每个页面都要手动收集”， pv怎么算，pv的意思是页面浏览量，也就是需要页面生成时，对应到小程序生命周期就是onLoad 刚才我们做到了每个Page执行时添加功能，但是怎么在onLoad时进行数据统计呢？ 同样的可以用装饰函数修饰page里面的函数方法 [图1] 这个data就是我们实际在pages下写的业务逻辑对象，我们先拿到该页面的key名来进行遍历，首先排除掉非函数，拿到onLoad函数，这时候对它进行扩展，这时候每一个页面执行onLoad的时候都会console一次字符串，当然也可以替换为你想要的任何功能 [图2] 其实我们可以再优化一下，比如抽出一个对象，将你想要装饰的函数写入其中，如果原函数存在则进行装饰，如果不存在则直接赋值，这个抽出来的对象其实可以算是另一种继承方式的实现 它的意义在于[图片]                                            帮助我们开辟了一块公有空间，帮助我们扩展Page对象，并且可以劫持任意方法，在不修改原业务函数代码的情况下增加新的逻辑 其次也是最重要的是，我们完全不需要处理历史包袱 一个应用场景[图片]                                            左边是微信原生的分享方法 遇到的一些问题： 不便于扩展，多个分享策略时，代码块过大，并且分享的通用数据需要每个页面单独处理，例如统计回流信息需要的分享页面信息，事件信息 右边是依赖于我们刚刚开辟的公有空间里填写的公共方法，函数很简单，获得参数，获得页面分享策略，执行，顺便还做了obj转url的处理，避免了纯url书写长路径时的尴尬 思考[图片]                                            既然能扩展Page对象，那么App，Component甚至wx全局对象下的方法呢？ 有兴趣的朋友可以下来想一下 跨页面 / 多页面事件通知[图片]                                            我这边简单提一下跨页面通知的问题，这个应该算是很多小程序开发者遇到的通用问题，我问过的一些人，大部分是使用下面这两种方法，一种是getCurrentPages 页面栈队列，二种onShow upData global里的存储的数据，不管哪一种在业务复杂的情况下都会引起一定的问题，比如第一种的多级入口，第二种的话属于无效判断和及时性 小打卡这边用的简版的event Bus，一个只有80行代码的订阅方法， 左图是一个简单的示例，大致上就是分两种角色，订阅者和发布者，中间依靠任务队列联系，每次发布者推送消息，订阅者都会收到通知和相应的数据 [图片]                                            其实单纯的event bus也有很多的问题，比如：业务复杂情况下过于频繁，对业务代码侵入频繁，可以想像一下到处都是on，off, emit场景 解绑需要树立规范，但是人总是会犯错，容易绑定后忘记解绑或重复绑定的问题，比较浪费内存，对性能也有消耗 结合公共空间我们已知可以对生命周期进行扩展的时候怎么去解决这个问题 其实订阅必然是和页面结合，因为在页面不存在的情况下，发送通知也不会有反馈， 如何证明页面存在自然是onLoad 和 onUnload 按照这个逻辑我们只需要在onLoad和onShow做些处理即可 [图1] 先看右侧业务代码，按照策略注册了一个函数集合，在执行onLoad时，自动将业务内的onRss函数遍历，自定绑定订阅，并推到一个缓存数组内 onUnload时遍历缓存，自动解绑 这时订阅与页面的生命周期强绑定，我们不再需要处理解绑事件，也不需要在业务内插入订阅代码，只需要管理好当前页面的订阅策略即可 技术选型[图片]                                            没有哪一种一定正确的方案，在选型的时候可能需要考虑到上面大致6种元素, 总之选择最适合自己团队方案非常重要 一些小贴士：开发要尽量避免过度设计, 应根据实际需求, 比如之前在写现在这个简版的event bus库的时候设计了很多奇奇怪怪的 功能，现在2年过去还没用到  小程序和浏览器，node本质上是相通的，可以多借鉴和参考 The End今天我的分享就到此结束，算是这段时间对小程序开发上的一点心得体会，谢谢 [图片]                                           

wxml 页面的取整(这个方法是有争议的  我一般是这么写   留言区也有许多小伙伴分享了他们的方法  你们也可以参考) [代码]<!-- 后台返回值类型为   1.30  或者1.33  此时你需要  结果为  1 -->[代码]这样书写即可[代码]<[代码][代码]text[代码][代码]>{{1.30|parseInt}}</[代码][代码]text[代码][代码]>[代码][代码]{{前面是后台给的数据|parseInt}}[代码]es6箭头函数  简写 [代码]   onLoad: [代码][代码]function[代码][代码]() {[代码] [代码]   [代码][代码]},[代码] [代码]   [代码][代码]// 也可以这样简写[代码][代码]   [代码][代码]onLoad() {[代码] [代码]   [代码][代码]},[代码] [代码]   [代码][代码]test() {[代码][代码]       [代码][代码]wx.getSystemInfo({[代码][代码]           [代码][代码]success(res) {[代码][代码]               [代码][代码]//导航高度[代码][代码]               [代码][代码]this[代码][代码].data.navHeight = res.statusBarHeight + 46;[代码][代码]           [代码][代码]},[代码][代码]           [代码][代码]fail(err) {[代码][代码]               [代码][代码]console.log(err);[代码][代码]           [代码][代码]}[代码][代码]       [代码][代码]})[代码] [代码]       [代码][代码]// 也可以这样写[代码][代码]       [代码][代码]// 注意   当只有一个参数 res 时候可以这样简写[代码] [代码]       [代码][代码]wx.getSystemInfo({[代码][代码]           [代码][代码]success: res => {[代码][代码]               [代码][代码]//导航高度[代码][代码]               [代码][代码]this[代码][代码].data.navHeight = res.statusBarHeight + 46;[代码][代码]           [代码][代码]},[代码][代码]           [代码][代码]fail(err) {[代码][代码]               [代码][代码]console.log(err);[代码][代码]           [代码][代码]}[代码][代码]       [代码][代码]})[代码][代码]   [代码][代码]}[代码]           3.js中判断条件单一简写        [代码]this[代码][代码].data.refreshTime && clearInterval([代码][代码]this[代码][代码].data.refreshTime);[代码][代码]// 之前需要这样写[代码] [代码]if[代码] [代码]([代码][代码]this[代码][代码].data.refreshTime) {[代码][代码]    [代码][代码]clearInterval([代码][代码]this[代码][代码].data.refreshTime);[代码][代码]}[代码]4.页面渲染优化可以考虑部分使用wxs      官方文档指出：   由于运行环境的差异，在 iOS 设备上小程序内的 WXS 会比 JavaScript 代码快 2 ~ 20 倍。在 android 设备上二者运行效率无差异。 有时候遍历数据修改数据时候可以使用 【写在最后】：希望我的文章能帮助到你

这是之前的发帖，不知道如何追问，所以再发一贴。期待大神解答。https://developers.weixin.qq.com/community/develop/doc/00040609a5c3a0b61c687a6b851400 问题一： 若用户在微信搜索结果页里，看到了关键词，点击之后，用户会直接前往小程序该页面对吧？但是，搜索到的内容理论上并不会出现才对，因为小程序上的文字是依照用户当时的条件从后端返回。 除非微信搜索爬取时，当下是以缓存的方式，把小程序里的内容给存了起来。 问题二： 微信搜索这个服务到了线上环境了吗？我们已经完成了相关配置，但目前使用微信搜索还是无法找到小程序页面的相关关键词。

写在前面 原生小程序插上 JSX 和 Less 的翅膀 mps 是什么？为什么需要 mps？先列举几个现状: 目前小程序开发使用最多的技术依然是原生小程序 原生小程序的 API 在不断完善和进化中 JSX 是表达能力和编程体验最好的 UI 表达式 JSX 可以表达一切想表达的 UI 结构也就能够描述任意 WXML 所以，就有了 mps。 让开发者直接在原生小程序使用 JSX 写 WXML，实时编译，实时预览。 → mps github 地址 [图片] JSX 代替 WXML 书写结构，精简高效 对原生小程序零入侵 支持 JS 和 TS 实时编译，实时预览 输出 WXML 自动美化 支持 Less 输出 WXSS 效果预览 [图片] 立即开始 [代码]$ npm i omi-cli -g $ omi init-mps my-app $ cd my-app $ npm start [代码] 接着把小程序目录设置为 my-app 目录便可以愉快地开始开发调试了！ [代码]npx omi-cli init-mps my-app[代码] 也支持(npm v5.2.0+) 生成的目录和官方的模板一致，只不过多了 JSX 文件，只需要修改 JSX 文件就会实时修改 WXML。 也支持 typescript: [代码]$ omi init-mps-ts my-app [代码] 其他命令一样。 [代码]npx omi-cli init-mps-ts my-app[代码] 也支持(npm v5.2.0+) JSX vs WXML 这里是一个真实的案例说明 JSX 的精巧高效的表达能力: 编译前的 JSX: [代码]<view class='pre language-jsx'> <view class='code'> {tks.map(tk => { return tk.type === 'tag' ? <text class={'token ' + tk.type}>{ tk.content.map(stk => { return stk.deep ? stk.content.map(sstk => { return <text class={'token ' + sstk.type}>{sstk.content || sstk}</text> }) : <text class={'token ' + stk.type}>{stk.content || stk}</text> })}</text> : <text class={'token ' + tk.type}>{tk.content || tk}</text> })} </view> </view> [代码] 编译后 WXML: [代码]<view class="pre language-jsx"> <view class="code"> <block wx:for="{{tks}}" wx:for-item="tk" wx:for-index="_anonIdx4"> <block wx:if="{{tk.type === 'tag'}}" ><text class="{{'token ' + tk.type}}" ><block wx:for="{{tk.content}}" wx:for-item="stk" wx:for-index="_anonIdx2" ><block wx:if="{{stk.deep}}" ><text class="{{'token ' + sstk.type}}" wx:for="{{stk.content}}" wx:for-item="sstk" wx:for-index="_anonIdx3" >{{sstk.content || sstk}}</text > </block> <block wx:else ><text class="{{'token ' + stk.type}}" >{{stk.content || stk}}</text > </block> </block> </text> </block> <block wx:else ><text class="{{'token ' + tk.type}}">{{tk.content || tk}}</text> </block> </block> </view> </view> [代码] 老项目使用 mps 拷贝以下文件到小程序根目录: _scripts 目录所有文件 package.json gulpfile.js .jsx 和 .less 文件 设置 project.config.json 里的 packOptions.ignore 忽略以上的文件，具体的配置可以从这里复制过去，然后: [代码]$ npm install $ npm start [代码] mps 约定 公共的 less 文件必须放在 common-less 目录，@import 使用的时候不需要写路径。 推荐搭配 既然用了原生小程序的方案，所有可以轻松使用 mps + omix 搭配一起使用。 欢迎使用腾讯 Omi 团队集合京东 O2Team 智慧联合打造的 mp-jsx 大幅提高开发效率，Have fun! Github → mps

1. 介绍docker是什么Docker使用go基于linux lxc（linux containers）技术实现的开源容器，诞生于2013年年初，最开始叫dotcloud公司，13年年底改名为docker inc。 2017年下载次数达到了百亿次，估值达13亿美元，通过对应用封装（Packaging）、分发（Distribution）、部署（Deployment）、运行（Runtime）全生命周期管理，达到“一次封装，到处运行” [图片]   为何使用docker?Docker直译码头工人，将各种大小和形状的物品装进船里。这对从事软件行业的人来说，听起来很熟悉，花了大量时间和精力把一个应用放在另一个应用里 [图片]   docker出现之前，对不同环境的安装、配置、维护工作量很多，如部署，配置文件，crontab，依赖等等。 使用docker，无需关心环境，只需要一些配置就能构建镜像，而部署则用一条run命令 [图片]     虚拟机 vs 容器  虚拟机需要有额外的虚拟机管理应用和虚拟机操作系统层，操作系统层不仅占用空间而且运行速度也相对慢 docker容器是在本机操作系统层面上实现虚拟化，因此很轻量，速度接近原生系统速度 [图片]   虚拟机启动速度是分钟级别，性能较弱、内存和硬盘占用大，一个物理机最多跑几十个虚拟机，但它的隔离性比较好。 docker启停都是秒级实现，内存和硬盘占用非常小，单机支持上千个容器，在ibm服务器上可运行上万个容器 容器跟虚机相比，有着巨大的优势   [图片]   docker优点  只关心应用：以往我们需要关心操作系统、软件、项目，有了docker我们可以只关心应用而不是操作系统，docker发展迅速，基于docker的paas平台也层出不穷，使得我们能更方便的使用docker 快速交付：docker可在秒级提供沙箱环境，开发，测试，运维使用完全相同的环境来部署代码 微服务：docker有助于将一个复杂系统分解，让用户用更离散的方式思考服务 离线开发：将服务编排在笔记本中移动办公，使用docker可在本机秒级别启动一个本地开发环境 降低调试成本：在测试和上线时产生无效的类、有问题的依赖、缺少的配置等问题，docker可让一个问题调试和环境重现变得更简单 CD：docker让持续交付实现变得更容易，特别是对于蓝绿部署就更简单。 第一版上线时，需要上第二版新功能，两个版本功能会有冲突，这时用docker实现蓝绿部署就非常方便了 如：可以部署两个版本同时在线，新版本测试没问题了把老版本流量切到新版本就可以了 迁移：可以很快的迁移到其他云或服务器 与传统虚拟机方式相比，容器化方式在很多场景下都是存在极为明显的优势。无论是开发、测试、运维都应该尽快掌握docker，尽早享受其带来的巨大便利   [图片]   容器化方式在很多场景下都有极大的优势。无论是开发、测试、运维都应该尽快掌握docker，尽早享受其带来的巨大便利   [图片]   概念再来了解docker非常关键的概念，这样才能理解docker容器整个生命周期   [图片]   概念—镜像  镜像（类）=文件系统+数据，我常常用开发语言中的类比作镜像，对象比作容器 镜像由多个层加上一些docker元数据组成，容器运行着由镜像定义的系统   [图片]   概念—容器容器（对象）=镜像运行实例 容器是镜像的运行实例，可以使用同一个镜像运行多个实例。如图所示，一个ubuntu docker镜像产生了三个ubuntu容器，docker利用容器运行和隔离应用   [图片]   从读写角度来说，镜像是只读的，容器是在镜像上添加了一层可读写的文件系统   [图片]   [图片]   概念—层层=文件变更集合 像传统虚机应用，每个应用都需要拷贝一份文件副本，运行成百上千上磁盘空间会迅速耗光，而docker采用写时复制来减少磁盘空间，当一个运行中的容器要写入一个文件时，它会把该文件复制到新区域来记录这次的修改，在执行docker提交时将这次修改记录下并产生一个新的层。docker分层解决大规模使用容器时碰到的磁盘和效率问题   [图片] 概念—仓库docker借鉴了大量git优秀的经验。docker仓库分公有库和私有库，最大的公开仓库是docker hub，国内也有很多仓库源 [图片]             2. 创建第一个docker应用通过创建一个docker应用来看看docker是怎么方便使用的 创建docker镜像方式  创建docker有四种方式 [图片]   但最常用的docker命令+手工提交和Dockerfile的方式   [图片]   对于我们来说Dockerfile是最常用也是最有用的 “dockerfile”    [图片]   那创建一个docker应用只需要三步：编写dockerfile、构建镜像、运行容器 编写dockerfile那我们就开始用dockerfile来创建一个应用 Dockerfile是包含一系列命令的文本文件，这个文件包含6条命令 1、FROM是使用php官方镜像，左边是镜像名字，右边是标签名字，标签名字不写默认是latest 2、声明维护人员 3、RUN运行一条linux命令，我们把php代码重定向到/tmp/index.php 4、EXPOSE声明要开放的端口 5、WORKDIR启动容器后默认目录 6、CMD容器启动后，默认执行的命令，相当于应用的入口，用php自带的webserver监听8000 [图片]   构建镜像使用docker build命令生成镜像，—tag指定镜像的名字，左边是名字，右边是标签，最后有个.表示在当前目录查找Dockerfile 可以看到，每个命令都会有个输入输出，输入是命令，输出是给到层的id，所以，基本上每个命令都会产生一个层 最后提示镜像构建成功，并打上镜像标签 [图片]   运行容器第三，使用docker run命令运行镜像，-p将容器的8000端口映射到本机8000端口，—name给容器起个名字 用curl对本机8000端口请求，服务器返回当前时间，说明我们构建的容器运行成功了   [图片]   请求本地8000端口，服务器返回当前时间 [图片]   dockerfile常用命令其实Dockerfile常用命令就5个：from、add、run、workdir、cmd   创建docker应用步骤编写dockerfile 构建镜像 运行容器   使用docker应用步骤拉取镜像 运行容器 dockerfile最佳实践精简镜像用途 尽量让每个镜像的用途单一 选择合适基础镜像 选择以alpine、busybox等基础的镜像 busybox：号称操作系统里的瑞士军刀，只有……这么大，但却有一百多常用命令 如果你的目标是小而精，busybox是首选，因为它已经精简到没有bash，使用的是ash，一个兼容posix的shell [图片]   Alpine：你的目标是小但是又有一些工具的话，可以选择alpine，它是一个面向安全的轻量linux发行版，它关注安全、性能和资源效能，比busybox功能更完善，还提供apk查询和安装软件包，大小只有2-3兆 [图片]   很多官方的镜像都有alpine的镜像，像刚刚使用的php镜像 [图片]   提供维护者信息 正确使用版本 使用明确的版本号，而非依赖于默认的latest，避免环境不一致导致的问题 [图片] 删除临时文件 如安装软件后的安装包，如上图2、3步骤 提高生成速度 如内容不变的指令尽量放在前面，这样可以复用 减少镜像层数 多条命令写在一起，使生成的镜像层数少，如上图2、3步骤 恰当使用multi-stage 保证最终生成镜像最小化   3. 常用命令search想使用一个镜像，用这个命令就可以了，默认按评分排序 official如果是ok表示是官方镜像 Auto标示它是否用dickerfile进行自动化镜像构建 [图片]   pull一旦确定一个镜像，通过对其名称执行docker pull来下载 标签默认是latest，严格来讲，镜像的仓库名还应该添加仓库地址的，默认是registry.hub.docker.com Docker images命令查找下载的镜像 [图片]   run使用docker run运行一个容器，it表示用交互式方式运行，最后表示要执行的命令 [图片]   其实更常用的方式是以后台方式来执行，这时用d参数在后台运行 运行后用exec命令进去到容器   [图片]   tagDocker tag给镜像一个新tag名字 Docker images查看centos镜像，把centos:latest打上centos:yeedomliu，这时再看会有3个centos，latest和yeedomliu的镜像id是相同的 把centos:yeedomliu删除，再查看latest还会存在，最后用rmi命令删除latest就会真正把latest镜像删除掉 如果相同镜像存在多个标签，只有最后一次的rmi命令会真正删除镜像   [图片] psPs可以查看运行中的容器 [图片]   rmi删除一个镜像，同一个镜像id的不同标签的镜像，使用rmi删除最后一个镜像才会真正删除这个镜像 [图片]   rm删除docker容器，如果运行中的容器需要加-f   [图片]   diff容器启动后文件变化情况 [图片]   logs查看容器运行后的日志 [图片]   cp我们想从容器里面拷贝文件到宿主机，或相反的过程就可以用到cp命令 [图片]   container prune随着使用docker时间越长，停止状态下的容器会越来越多，这些都会占据磁盘空间 [图片]   image prune未被打标签的镜像可以用image prune命令清理 [图片]   system prune/df如果你觉得刚刚两条命令执行起来麻烦，可以用docker system prune一条命令搞定 另外用system df查看docker磁盘空间 [图片]   4. 实战了解了docker基础知识后，可进入相对实战的环节 本地开发 常见问题 架构 优化    本地开发 我们的项目使用了很多服务，如redis/mysql/mongodb等等，如果一个个运行起来，还加上配置，容易出手，也比较麻烦   kitematic：与使用命令行管理本地容器相比，你更想使用图形工具对容器管理，官方推出的容器管理工具，通过它可以查找镜像、创建容器、配置、启停容器等管理 [图片] [图片]   这是配置容器端口和宿主机端口，目录，网络等映射界面 [图片]   docker-composecompose定位是“定义和运行多个docker容器的应用”，前身fig，目前仍然兼容fig格式的模板文件。 一条命令可以把一个复杂的应用启动起来 日常工作中，经常碰到多个容器相互完成某项任务 [图片]   docker-compose示例1 默认模板文件名叫docker-compose.yml，结构很简单，每个顶级元素为服务名称，次级信息为配置信息 这里使用了redis/mongodb/mysql/nginx镜像，分别给它们映射了本地目录、端口、密码等信息，nginx镜像需要使用redis/mysql等服务，用links命令连接进来 [图片]   docker-compose示例2 如果在本地开发，每个项目都可以像之前说的那样配置，这里提供了另外一种做法 我把公共的资源在一开始就启动，每个项目里只启动nginx镜像并关联其它的服务即可 公共服务compose [图片]   项目compose [图片]   常见问题 主进程：docker启动第一个进程称主进程，就是id为1的进程，这个进程退出就意味着容器退出，所以想要使docker作为服务使用，这个进程是不能退出的 expose命令是声明暴露的端口，运行时用-P才会生效。一般ports命令是做真正的端口映射，比较常用 架构 安装了docker的主机，一般在一个私有网络上 1、调用docker客户端可以从守护进程获取信息或发送指令 2、docker守护进程使用http协议接收来自docker客户端的请求 3、私有docker注册中心存储docker镜像 4、docker hub是由docker公司运营的最大的公共注册中心 互联网上也存在其他公共的注册中心   调用 Docker客户端可以从守护进程获取信息或给它发送指令。守护进程是一个服务器，它使用 HTTP协议接收来自客户端的请求并返回响应。相应地，它会向其他服务发起请求来发送和接收镜像，使用的同样是 HTTP协议。该服务器将接收来自命令行客户端或被授权连接的任何人的请求。守护进程还负责在幕后处理用户的镜像和容器，而客户端充当的是用户与 REST风格 API之间的媒介。   理解这张图的关键在于，当用户在自己的机器上运行 Docker时，与其进行交互的可能是自己机器上的另一个进程，或者甚至是运行在内部网络或互联网上的服务。 [图片] 优化 使用小镜像：一般来说，使用小的镜像都相对比较优秀，如官方的镜像基本上都有基于alpine的镜像 事后清理：删除镜像里软件包或一些临时文件，减小镜像大小 命令写一行：多个命令尽量写在一起有助于减少层数，也会减少镜像的大小 脚本安装：使用脚本进行初始化时，可以有效减少dockerfile的命令，同时带来另外的问题，可读性不好并且构建镜像时缓存不了 扁平化镜像：构建镜像过程中，可能会涉及到一些敏感信息，或者用了上面的办法镜像依然很大，可以试试这个办法 docker export 容器名或容器id | docker import - 镜像标签 multi-stage：从docker 17.05版本开始，docker支持multi-stage（多阶段构建），特别适合编译型语言，如我在一个镜像下编译，在另外一个很小的系统运行，如下图，go项目在golang环境下编译，在alpine环境下运行 [图片]      

“搜索一直应该是小程序的一个主要流量来源，小程序和APP的一个很大不同，APP是一个个的信息孤岛，互相之间没法交换信息。但小程序是可以被系统统一检索到，是可以直接搜索到小程序里面的内容的。” ——张小龙于2019微信公开课Pro   靴子终于落地。   3月29日，不少小程序开发者在后台收到了一条通知，通知表示，小程序新增页面收录功能，开发者可以设置小程序是否能被收录，或者通过配置实现特定页面被收录。 [图片] 乍一看有些云里雾里，实际上，这项能力在微信安卓7.0.4版中曾灰度测试过，让我们能一睹真容：   只要开启了该功能，小程序每一个页面都能被直接搜索到，比如搜索“计算器”，在内容一栏中就会展示页面中含有“计算器”的小程序，点击之后直达该页面。 [图片] 也就是说，理论上所有小程序页面都能被用户搜索，上百万个小程序的内容全部被打开，连成了一片信息的汪洋大海。 1 小程序SEO时代来了 对于这项能力，有开发者用了“太震撼”三个字来形容，并且认为它的重要性不亚于去年的下拉“小程序桌面”。   为了更深入了解它，我们不妨以搜索巨头百度作为参考。 众所周知，只要在搜索框里输入某个关键词，结果页就会展现出某个网站中含有该关键词的页面，点击直达该页面，这是页面收录功能的基本形式。 [图片] 我们可以小程序比作“网站”，以前只能搜索“整个网站”，现在可以搜索到里面的页面了。   百度小程序前段时间推出了一项能力，就是把小程序拆分为一个个网页，并被搜索引擎抓取。微信此项新能力与此类似，也是通过搜索直达小程序页面。   但百度智能小程序接入搜索的方式比较复杂，需在开发者工具中将小程序Web化，然后上传审核发布。 [图片] 另外，尽管以前微信也推出过搜索直达页面功能，即“服务直达”和“好物圈”，但都需要开发者主动申请配置，对于中小商家而言，有一定的技术门槛。   而这一门槛现已不复存在，因为小程序“页面收录设置”默认开启，所以商家不需要任何操作，就能被收录到微信搜索中。 [图片] 然而，收录仅仅是开始，更重要的是，此后所有商家都能通过对页面结构的优化，使小程序的排名更加靠前，获取更多搜索流量。   正如微信团队给我们的回复所说：“这一体验优化，可以帮助用户缩短寻找服务的路径，提升搜索效率，也可以帮助开发者的小程序获得更多曝光。”   换句话说，小程序SEO时代从这一刻真正到来了。 2 微信搜索是小程序的下一站 不过，在晓程序观察（yinghoo-tech）的调查中，也有商家表示质疑，用户有在微信里搜索的习惯吗？微信搜索的流量大吗？做小程序SEO有意义吗？   商家的疑惑情有可原，毕竟“流量”是所有商家都关心的话题，也是最原始驱动力之一。   确实，我们采访过的案例大都表示“功能直达”、“好物圈”等入口的量并不大，使用习惯尚待养成。   但我们认为，搜索未来必定成为微信小程序的重要入口，理由有两点：   1. 内容才是养成习惯的关键   从用户侧来说，互联网从PC端走到移动端，在交互体验、使用场景上都发生巨大变化，而搜索的习惯却继承了下来，像搜索巨头百度，每日需要响应60亿次的搜索请求，可见搜索依旧是获取信息和服务的重要方式。   并且，搜索行为往往与需求相伴，这与小程序“即用即走，触手可得”的特性也天然契合：需求产生——搜索小程序——使用服务——离开小程序，这条路格外顺畅。   但有人会说，“搜索是日常行为不假，但习惯在微信里搜索的人却不多，抢占搜索流量有意义么？”   我们不妨逆向思考这个问题，许多开发者表示，现在微信搜索最大的问题反倒不是使用习惯，而是缺乏内容，比如搜“羊毛大衣如何清洗”，完全得不到任何结果。 [图片] 但未来小程序页面收录功能全面上线后，所有有关“羊毛大衣如何清洗”的小程序页面都会被抓取到，可能是一篇文章，也可能就是羊毛大衣清洗服务，由此实现了搜—看—买的过程。   所以有理由相信，未来搜索结果的内容丰富度不再是问题，用户习惯的养成也就水到渠成。   2. 搜索将带来下一波流量红利   从商家侧看，搜索将带来下一波微信的流量红利。   以前，微信小程序的社交属性被过度放大，众多运营者们通过各种方式诱导用户转发分享，从而实现数据短时间内的爆炸增长，这对用户体验是巨大伤害。   所以我们发现，微信一直在通过诸如限制跳转数量、收回分享回调等方式，逐步规范小程序的社交裂变行为，2019年第一季度，确实没有再看到现象级小程序的刷屏事件。   有开发者表示，“社交流量带来的第一波红利期已经渐渐褪去，下一个取而代之的流量洼地应该是搜索”。   因为搜索能让所有商家不论大小，都站在同一起跑线上，流量获取更加平等化。   意思是在相同的搜索规则下，小团队开发的小程序通过页面结构的优化，提供更优质的服务，一样有机会排在头部小程序前面。 比如，在除去使用过、好友用过、功能直达等客观因素外，现在搜索“北京天气”，结果页是「墨迹天气」排第一。但在未来大家公平角逐时，「北京天气查询」这样的小程序，也有机会通过页面优化排在最前面，因为提供的服务更加精准。 [图片] 这对于中小开发者而言无疑一大助推。   微信一直在关注如何让优质的小程序被更好的发现，目前来看，让服务与产品质量更高的小程序通过搜索入口自然涌现，这是微信给出的答案。 3 小程序SEO，需要提前这几点 那么，商家如何提前落子，布局微信搜索呢？或许从传统搜索引擎的SEO方法中，可以获得一些思路。   “过去做SEO 的方法是：结合站点属性和需求词数据，根据搜索引擎平台提供的索引规范和页面结构标准指引，不断进行调优化，从而提高索引收录排名的可能性”飞虎商联产品负责人周圣伟说到，他有着多年的建站以及SEO经验。   但目前小程序页面收录能力仍处于内测，没有明确的索引规范，所以我们只能提出一些值得商家注意的地方。 1.先考虑清楚哪些页面允许被收录 需要强调，小程序页面收录开关是全局性的，意思是开启后小程序每个页面都能被搜索到，但有的小程序页面中包含开发者不想暴露的内容。 此时就要选择“关闭收录”，然后单独进行sitemap配置，sitemap配置就是注明哪些页面可以被收录，哪些不能被收录。 [图片] 2.根据索引规范优化页面结构   一般而言，索引规范会说明标题摘要、关键词的相关规则，例如“北京天气如何北京今天天气怎么样”这种关键词堆砌都是在禁止之列。另外，像页面内功能按钮的易用性，音频视频的使用情况，都要考虑在内。 [图片]（百度智能小程序的索引规范） 3.原创保护与抓取周期也要注意 周圣伟告诉我们，格外需要注意的是品牌词与原创保护，比如，现在有许多小程序就是各类公号文章的集合，但这些小程序未来都有可能违反了原创保护，导致权重的下降。   最后，索引的周期性也值得关注，搜索引擎的抓取一般有周期性，如果周期内页面没有更新，就不容易被抓取到，所以及时更新页面就成为一个关键。   当然，上周推出的小程序评测能力，或许也与搜索排名有千丝万缕的联系，还有微信特有的社交关系，相信也是影响权重的重要指标。 [图片] 由此可见，未来小程序SEO将成为一门全新的产业，据我们了解，有很多小程序服务商已经嗅到了商机，都摩拳擦掌等待着在小程序SEO领域大干一场。 当然，更具体的细则以及一些疑问，都要等这项新能力正式上线时才能揭晓。

0. 前言 平时写CSS，感觉有很多多余的代码或者不好实现的方法，于是有了预处理器的解决方案，主旨是write less &do more。其实原生css中，用上css变量也不差，加上bem命名规则只要嵌套不深也能和less、sass的嵌套媲美。在一些动画或者炫酷的特效中，不用js的话可能是用了css动画、svg的animation、过渡，复杂动画实现用了js的话可能用了canvas、直接修改style属性。用js的，然后有没有想过一个问题：“要是canvas那套放在dom上就爽了”。因为复杂的动画频繁操作了dom，违背了倒背如流的“性能优化之一：尽量少操作dom”的规矩，嘴上说着不要，手倒是很诚实地[代码]ele.style.prop = <newProp>[代码]，可是要实现效果这又是无可奈何或者大大减小工作量的方法。 我们都知道，浏览器渲染的流程:解析html和css（parse），样式计算（style calculate），布局（layout），绘制（paint），合并（composite），修改了样式，改的环节越深代价越大。js改变样式，首先是操作dom，整个渲染流程马上重新走，可能走到样式计算到合并环节之间，代价大，性能差。然后痛点就来了，浏览器有没有能直接操作前面这些环节的方法呢而不是依靠js？有没有方法不用js操作dom改变style或者切换class来改变样式呢？ 于是就有CSS Houdini了，它是W3C和那几个顶级公司的工程师组成的小组，让开发者可以通过新api操作CSS引擎，带来更多的自由度，让整个渲染流程都可以被开发者控制。上面的问题，不用js就可以实现曾经需要js的效果，而且只在渲染过程中，就已经按照开发者的代码渲染出结果，而不是渲染完成了再重新用js强行走一遍流程。 关于houdini最近动态可点击这里 上次CSS大会知道了有Houdini的存在，那时候只有cssom，layout和paint api。前几天突然发现，Animation api也有了，不得不说，以后很可能是Houdini遍地开花的时代，现在得进一步了解一下了。一句话：这是css in js到js in css的转变 1. CSS变量 如果你用less、sass只为了人家有变量和嵌套，那用原生css也是差不多的，因为原生css也有变量： 比如定义一个全局变量–color（css变量双横线开头） [代码]:root { --color: #f00; } [代码] 使用的时候只要var一下 [代码].f{ color: var(--color); } [代码] 我们的html： [代码]<div class="f">123</div> [代码] 于是，红色的123就出来了。 css变量还和js变量一样，有作用域的： [代码]:root { --color: #f00; } .f { --color: #aaa } .g{ color: var(--color); } .ft { color: var(--color); } [代码] html： [代码] <div className="f"> <div className="ft">123</div> </div> <div className=""> <div className="g">123</div> </div> [代码] 于是，是什么效果你应该也很容易就猜出来了： [图片] css能搞变量的话，我们就可以做到修改一处牵动多处的变动。比如我们做一个像准星一样的四个方向用准线锁定鼠标位置的效果： [图片] 用css变量的话，比传统一个个元素设置style优雅多了： [代码]<div id="shadow"> <div class="x"></div> <div class="y"></div> <div class="x_"></div> <div class="y_"></div> </div> [代码] [代码] :root{ --x: 0px; --y: 0px; } body{ margin: 0 } #shadow{ width: 50%; height: 600px; border: #000 1px solid; position: relative; margin: 0; } .x, .y, .x_, .y_ { position: absolute; border: #f00 2px solid; } .x { top: 0; left: var(--x); height: 20px; width: 0; } .y { top: var(--y); left: 0; height: 0; width: 20px; } .x_ { top: 600px; left: var(--x); height: 20px; width: 0; } .y_ { top: var(--y); left: 100%; height: 0; width: 20px; } [代码] [代码]const style = document.documentElement.style shadow.addEventListener('mousemove', e => { style.setProperty(`--x`, e.clientX + 'px') style.setProperty(`--y`, e.clientY + 'px') }) [代码] 那么，对于github的404页面这种内容和鼠标位置有关的页面，思路是不是一下子就出来了 2. CSS type OM 都有DOM了，那CSSOM也理所当然存在。我们平时改变css的时候，通常是直接修改style或者切换类，实际上就是操作DOM来间接操作CSSOM，而type om是一种把css的属性和值存在attributeStyleMap对象中，我们只要直接操作这个对象就可以做到之前的js改变css的操作。另外一个很重要的点，attributeStyleMap存的是css的数值而不是字符串，而且支持各种算数以及单位换算，比起操作字符串，性能明显更优。 接下来，基本脱离不了window下的CSS这个属性。在使用的时候，首先，我们可以采取渐进式的做法： [代码]if('CSS' in window){...}[代码] 2.1 单位 [代码]CSS.px(1); // 1px 返回的结果是：CSSUnitValue {value: 1, unit: "px"} CSS.number(0); // 0 比如top：0，也经常用到 CSS.rem(2); //2rem new CSSUnitValue(2, 'percent'); // 还可以用构造函数，这里的结果就是2% // 其他单位同理 [代码] 2.2 数学运算 自己在控制台输入CSSMath，可以看见的提示，就是数学运算 [代码]new CSSMathSum(CSS.rem(10), CSS.px(-1)) // calc(10rem - 1px)，要用new不然报错 new CSSMathMax(CSS.px(1),CSS.px(2)) // 顾名思义，就是较大值，单位不同也可以进行比较 [代码] 2.3 怎么用 既然是新的东西，那就有它的使用规则。 获取值[代码]element.attributeStyleMap.get(attributeName)[代码]，返回一个CSSUnitValue对象 设置值[代码]element.attributeStyleMap.set(attributeName, newValue)[代码]，设置值，传入的值可以是css值字符串或者是CSSUnitValue对象 当然，第一次get是返回null的，因为你都没有set过。“那我还是要用一下getComputedStyle再set咯，这还不是和之前的差不多吗？” 实际上，有一个类似的方法：[代码]element.computedStyleMap[代码]，返回的是CSSUnitValue对象，这就ok了。我们拿前面的第一部分CSS变量的代码测试一波 [代码]document.querySelector('.x').computedStyleMap().get('height') // CSSUnitValue {value: 20, unit: "px"} document.querySelector('.x').computedStyleMap().set('height', CSS.px(0)) // 不见了 [代码] 3. paint API paint、animation、layout API都是以worker的形式工作，具体有几个步骤： 建立一个worker.js，比如我们想用paint API，先在这个js文件注册这个模块registerPaint(‘mypaint’, class)，这个class是一个类下面具体讲到 在html引入CSS.paintWorklet.addModule(‘worker.js’) 在css中使用，background: paint(mypaint) 主要的逻辑，全都写在传入registerPaint的class里面。paint API很像canvas那套，实际上可以当作自己画一个img。既然是img，那么在所有的能用到图片url的地方都适合用paint API，比如我们来自己画一个有点炫酷的背景(满屏随机颜色方块)。有空的话可以想一下js怎么做，再对比一下paint API的方案。 [图片] [代码]// worker.js class RandomColorPainter { // 可以获取的css属性，先写在这里 // 我这里定义宽高和间隔，从css获取 static get inputProperties() { return ['--w', '--h', '--spacing']; } /** * 绘制函数paint，最主要部分 * @param {PaintRenderingContext2D} ctx 类似canvas的ctx * @param {PaintSize} PaintSize 绘制范围大小(px) { width, height } * @param {StylePropertyMapReadOnly} props 前面inputProperties列举的属性，用get获取 */ paint(ctx, PaintSize, props) { const w = (props.get('--w') && +props.get('--w')[0].trim()) || 30; const h = (props.get('--h') && +props.get('--h')[0].trim()) || 30; const spacing = +props.get('--spacing')[0].trim() || 10; for (let x = 0; x < PaintSize.width / w; x++) { for (let y = 0; y < PaintSize.height / h; y++) { ctx.fillStyle = `#${Math.random().toString(16).slice(2, 8)}` ctx.beginPath(); ctx.rect(x * (w + spacing), y * (h + spacing), w, h); ctx.fill(); } } } } registerPaint('randomcolor', RandomColorPainter); [代码] 接着我们需要引入该worker： [代码]CSS && CSS.paintWorklet.addModule('worker.js');[代码] 最后我们在一个class为paint的div应用样式： [代码].paint{ background-image: paint(randomcolor); width: 100%; height: 600px; color: #000; --w: 50; --h: 50; --spacing: 10; } [代码] 再想想用js+div，是不是要先动态生成n个，然后各种计算各种操作dom，想想就可怕。如果是canvas，这可是canvas背景，你又要在上面放一个div，而且还要定位一波。 注意： worker是没有window的，所以想搞动画的就不能内部消化了。不过可以靠外面的css变量，我们用js操作css变量可以解决，也比传统的方法优雅 4. 自定义属性 支持情况 点击这里查看 首先，看一下支持度，目前浏览器并没有完全稳定使用，所以需要跟着它的提示：[代码]Experimental Web Platform features” on chrome://flags[代码]，在chrome地址栏输入[代码]chrome://flags[代码]再找到[代码]Experimental Web Platform features[代码]并开启。 [代码]CSS.registerProperty({ name: '--myprop', //属性名字 syntax: '<length>', // 什么类型的单位，这里是长度 initialValue: '1px', // 默认值 inherits: true // 会不会继承，true为继承父元素 }); [代码] 说到继承，我们回到前面的css变量，已经说了变量是区分作用域的，其实父作用域定义变量，子元素使用该变量实际上是继承的作用。如果[代码]inherits: true[代码]那就是我们看见的作用域的效果，如果不是true则不会被父作用域影响，而且取默认值。 这个自定义属性，精辟在于，可以用永久循环的animation驱动一次性的transform。换句话说，我们如果用了css变量+transform，可以靠js改变这个变量达到花俏的效果。但是，现在不需要js，只要css内部消化，transform成为永动机。 [代码]// 我们先注册几种属性 ['x1','y1','z1','x2','y2','z2'].forEach(p => { CSS.registerProperty({ name: `--${p}`, syntax: '<angle>', inherits: false, initialValue: '0deg' }); }); [代码] 然后写个样式 [代码]#myprop, #myprop1 { width: 200px; border: 2px dashed #000; border-bottom: 10px solid #000; animation:myprop 3000ms alternate infinite ease-in-out; transform: rotateX(var(--x2)) rotateY(var(--y2)) rotateZ(var(--z2)) } [代码] 再来看看我们的动画，为了眼花缭乱，加了第二个改了一点数据的动画 [代码]@keyframes myprop { 25% { --x1: 20deg; --y1: 30deg; --z1: 40deg; } 50% { --x1: -20deg; --z1: -40deg; --y1: -30deg; } 75% { --x2: -200deg; --y2: 130deg; --z2: -350deg; } 100% { --x1: -200deg; --y1: 130deg; --z1: -350deg; } } @keyframes myprop1 { 25% { --x1: 20deg; --y1: 30deg; --z1: 40deg; } 50% { --x2: -200deg; --y2: 130deg; --z2: -350deg; } 75% { --x1: -20deg; --z1: -40deg; --y1: -30deg; } 100% { --x1: -200deg; --y1: 130deg; --z1: -350deg; } } [代码] html就两个div: [代码] <div id="myprop"></div> <div id="myprop1"></div> [代码] 效果是什么呢，自己可以跑一遍看看，反正功能很强大，但是想象力限制了发挥。 自己动手改的时候注意一下，动画关键帧里面，不能只存在1，那样子就不能驱动transform了，做不到永动机的效果，因为我的rotate写的是 rotateX(var(–x2))。接下来随意发挥吧 最后 再啰嗦一次 关于houdini最近动态可点击这里 关于houdini在浏览器的支持情况 ENJOY YOURSELF!!!

项目背景 在海外项目中，为了优化用户体验加入了几处微交互动画，实现方式是设计输出合成的雪碧图，前端通过序列帧实现动画效果： [图片] 序列帧： [图片] 动画效果： [图片] 序列帧： [图片] 帧动画的缺点和局限性比较明显，合成的雪碧图文件大，且在不同屏幕分辨率下可能会失真。经调研发现，Lottie是个简单、高效且性能高的动画方案。 Lottie是可应用于Android, iOS, Web和Windows的库，通过Bodymovin解析AE动画，并导出可在移动端和web端渲染动画的json文件。换言之，设计师用AE把动画效果做出来，再用Bodymovin导出相应地json文件给到前端，前端使用Lottie库就可以实现动画效果。 [图片] Bodymovin插件的安装与使用 关闭AE 下载并安装ZXP installer https://aescripts.com/learn/zxp-installer/ 下载最新版bodymovin插件 https://github.com/airbnb/lottie-web/blob/master/build/extension/bodymovin.zxp 把下载好的bodymovin.zxp拖到ZXP installer [图片] 打开AE，在菜单首选项->常规中勾选☑️允许脚本写入文件和访问网络（否则输出JSON文件时会失败） [图片] 在AE中制作动画，打开菜单窗口->拓展->Bodymovin，勾选要输出的动画，并设置输出文件目录，点击render [图片] 打开输出目录会看到生成的JSON文件，若动画里导入了外部图片，则会在images中存放JSON中引用的图片 前端使用lottie 静态URL https://cdnjs.com/libraries/lottie-web NPM [代码]npm install lottie-web [代码] 调用loadAnimation [代码]lottie.loadAnimation({ container: element, // 容器节点 renderer: 'svg', loop: true, autoplay: true, path: 'data.json' // JSON文件路径 }); [代码] vue-lottie 也可以在vue中使用lottie [代码] import lottie from '../lib/lottie'; import * as favAnmData from '../../raw/fav.json'; export default { props: { options: { type: Object, required: true }, height: Number, width: Number, }, data () { return { style: { width: this.width ? `${this.width}px` : '100%', height: this.height ? `${this.height}px` : '100%', overflow: 'hidden', margin: '0 auto' } } }, mounted () { this.anim = lottie.loadAnimation({ container: this.$refs.lavContainer, renderer: 'svg', loop: this.options.loop !== false, autoplay: this.options.autoplay !== false, animationData: favAnmData, assetsPath: this.options.assetsPath, rendererSettings: this.options.rendererSettings } ); this.$emit('animCreated', this.anim) } } [代码] loadAnimation参数 参数名 描述 container 用于渲染动画的HTML元素，需确保在调用loadAnimation时该元素已存在 renderer 渲染器，可选值为’svg’（默认值）/‘canvas’/‘html’。svg支持的功能最多，但html的性能更好且支持3d图层。各选项值支持的功能列表在此 loop 默认值为true。可传递需要循环的特定次数 autoplay 自动播放 path JSON文件路径 animationData JSON数据，与path互斥 name 传递该参数后，可在之后通过lottie命令引用该动画实例 rendererSettings 可传递给renderer实例的特定设置，具体可看 Lottie动画监听 Lottie提供了用于监听动画执行情况的事件： complete loopComplete enterFrame segmentStart config_ready(初始配置完成) data_ready（所有动画数据加载完成） DOMLoaded（元素已添加到DOM节点） destroy 可使用addEventListener监听事件 [代码]// 动画播放完成触发 anm.addEventListener('complete', anmLoaded); // 当前循环播放完成触发 anm.addEventListener('loopComplete', anmComplete); // 播放一帧动画的时候触发 anm.addEventListener('enterFrame', enterFrame); [代码] 控制动画播放速度和进度 可使用anm.pause和anm.play暂停和播放动画，调用anm.stop则会停止动画播放并回到动画第一帧的画面。 使用anm.setSpeed(speed)可调节动画速度，而anm.goToAndStop(value, isFrame)和anm.goToAndPlay可控制播放特定帧数，也可结合anm.totalFrames控制进度百分比，比如可传anm.totalFrames - 1跳到最后一帧。 [代码]anm.goToAndStop(anm.totalFrames - 1, 1); [代码] 这样的好处是可以把相关联的JSON文件合并，通过anm.goToAndPlay控制动画状态的切换，如下图例中一个JSON文件包含了2个动画状态的数据： [图片] 图片资源 JSON文件里assets设置了对图片的引用： [图片] 若想统一修改静态资源路径或者设置成绝对路径，可在调用loadAnimation时传入assetsPath参数： [代码]lottie.loadAnimation({ container: element, renderer: 'svg', path: 'data.json', assetsPath: 'URL' // 静态资源绝对路径 }); [代码] 功能支持列表 即使用bodymovin成功输出了JSON文件（没有报错），也会出现动效不如预期的情况，比如这是在AE中构建的形象图： [图片] 但在页面中渲染效果是这样的： [图片] 这是因为使用了不支持的Merge Paths功能 [图片] 因此对设计师而言，创建Lottie动画和往常制作AE动画有所不同，此文档记录了Bodymovin支持输出的AE功能列表，动画制作前需跟设计师沟通好，根据动画加载平台来确认可使用的AE功能。 除此之外，尽量遵循官方文档里对设计过程的指导和建议： 动画简单化。创建动画时需时刻记着保持JSON文件的精简，比如尽可能地绑定父子关系，在相似的图层上复制相同的关键帧会增加额外的代码，尽量不使用占用空间最多的路径关键帧动画。诸如自动跟踪描绘、颤动之类的技术会使得JSON文件变得非常大且耗性能。 建立形状图层。将AI、EPS、SVG和PDF等资源转换成形状图层否则无法在Lottie中正常使用，转换好后注意删除该资源以防被导出到JSON文件。 设置尺寸。在AE中可设置合成尺寸为任意大小，但需确保导出时合成尺寸和资源尺寸大小保持一致。 不使用表达式和特效。Lottie暂不支持。 注意遮罩尺寸。若使用alpha遮罩，遮照的大小会对性能产生很大的影响。尽可能地把遮罩尺寸维持到最小。 动画调试。若输出动画破损，通过每次导出特定图层来调试出哪些图层出了问题。然后在github中附上该图层文件提交问题，选择用其他方式重构该图层。 不使用混合模式和亮度蒙版。 不添加图层样式。 全屏动画。设置比想要支持的最宽屏幕更宽的导出尺寸。 设置空白对象。若使用空白对象，需确保勾选可见并设置透明度为0%否则不会被导出到JSON文件。 预览效果 由于以上所说的功能支持问题会导致输出动画效果不确定性，设计师和前端之间有个动画效果联调的过程，为了提高联调效率，设计师可先进行初步的效果预览，再把文件交付给前端。 方法1：输出预览HTML文件 渲染前设置所要渲染的文件 [图片] 勾选☑️Demo选项 [图片] 在输出的文件目录中就可找到可预览的demo.html文件 方法2：LottieFiles分享平台 把生成的JSON文件传到LottieFiles平台，可播放、暂停生成文件的动画效果，可设置图层颜色、动画速度，也可以下载lottie preview客户端在iOS或Android机子上预览。 [图片] LottieFiles平台还提供了很多线上公开的Lottie动画效果，可直接下载JSON文件使用 [图片] 交互hack Lottie的不足之处是没有对应的API操纵动画层，若想做更细化的动画处理，只能直接操作节点来实现。比如当播放完左图动画进入惊讶状态后，若想实现右图随鼠标移动而控制动画层的简单效果： [图片][图片] 开启调试面板可以看到，lottie-web通过使用<g>标签的transform属性来控制动画： [图片] 当元素已添加到DOM节点，找到想要控制的<g>标签，提取其transform属性的矩阵值，并使用rematrix解析矩阵值。 [代码]onIntroDone() { const Gs = this.refs.svg.querySelectorAll('svg > g > g > g'); Gs.forEach((node, i) => { // 过滤需要修改的节点 ... // 获取transform属性值 const styleArr = node.getAttribute('transform').split(','); styleArr[0] = styleArr[0].replace('matrix(', ''); styleArr[5] = styleArr[5].replace(')', ''); const style = `matrix(${styleArr[0]}, ${styleArr[1]}, ${styleArr[2]}, ${styleArr[3]}, ${styleArr[4]}, ${styleArr[5]})`; // 使用Rematrix解析 const transform = Rematrix.parse(style); this.matrices.push({ node, transform, prevTransform: transform }); } } [代码] 监听鼠标移动，设置新的transform属性值。 [代码]onMouseMove = (e) => { this.mouseCoords.x = e.clientX || e.pageX; this.mouseCoords.y = e.clientY || e.pageY; let x = this.mouseCoords.x - (this.props.browser.width / 2); let y = this.mouseCoords.y - (this.props.browser.height / 2); const diffX = (this.mouseCoords.prevX - x); const diffY = (this.mouseCoords.prevY - y); this.mouseCoords.prevX = x; this.mouseCoords.prevY = y; this.matrices.forEach((matrix, i) => { let translate = Rematrix.translate(diffX, diffY); const product = [matrix.prevTransform, translate].reduce(Rematrix.multiply); const css = `matrix(${product[0]}, ${product[1]}, ${product[4]}, ${product[5]}, ${product[12]}, ${product[13]})`; matrix.prevTransform = product; matrix.node.setAttribute('transform', css); }) } [代码] 进一步优化 看到一个方法，在AE中将图层命名为[代码]#id[代码]格式，生成的SVG相应的图层id会被设置为id，命名为[代码].class[代码]格式，相应的图层class会被设置为class [图片] 试了下的确可以，如下图，因此可通过这个方法快速找到需要操作的动画层，进一步简化代码： [图片] 小结 Lottie的缺点在于若在AE动画制作的过程不注意规范，会导致数据文件大、耗内存和性能的问题；Lottie-web的官方文档不够详尽，例如assetsPath参数是在看源码的时候发现的；开放的API不够齐全，无法很灵活地控制动画层。 而优点也很明显，Lottie能帮助提高开发效率，精简代码，易于调试和维护；资源文件小，输出动画效果保真；跨平台——Android, iOS, Web和Windows通用。 总的来说，Lottie的引用可以替代传统的GIF和帧动画，灵活利用好提供的属性和方法可以控制动画的播放，但需注意规范设计和开发的流程，才可以更高效地完成动画的制作与调试。

[图片] 天下武功，唯 (wei) 快(fu) 不(bu) 破(po)。 随着近几年的前端技术的高速发展，越来越多的团队使用 React、Vue 等 SPA 框架作为其主要的技术栈。以 React 应用为例，从性能角度，其最重要的指标可能就是首屏渲染所花费的时间了。那么今天，我们要给大家分享的一个把优化做到极致的故事。 我们的目标是让 H5 的页面也能够拥有 Native 般的体验，如果你还在寻求什么技术能够让老板虎躯一震（拯救你的KPI），那么这篇文章或许能够帮助到你。 企鹅辅导课程详情页是什么 [图片] 课程详情页是腾讯旗下 K12 在线教育产品 企鹅辅导 APP 中最重要页面之一，也是流量最大的页面之一，所以它的打开速度也是至关重要的。 这是一个使用 [代码]React[代码] 编写的 H5 页面，运行于多端，包括： [代码]企鹅辅导APP[代码]、[代码]手机 QQ[代码]、[代码]手机浏览器[代码]。 架构演变 纯异步渲染 我们知道当前主流的 SPA 的应用的默认渲染方式都是这样的： [图片] 在这种情况下，从加载页面到用户看到页面（首屏渲染所花费的时间）就是上图中灰色边框区域所包括的时间。 这是最慢的一种方式，就算 CGI 够快，最少要花费 1S 到 2S 左右的时间了。 接着我们简单优化一下： 把静态资源缓存起来，这样下次用户打开的时候就不用从网络请求了。 第 ④ 步拉取 CGI 这个动作是否可以提前呢？我们可以在请求 HTML 之后，先通过一段 JS 脚本去请求 CGI 数据，后面第 **④ **步的时候，就可以直接拿到数据了，这就是 CGI 预加载。 怎么做到呢？我们的方案是统一封装 Request 请求工具，在用 Webpack 打包的时候，会往页面顶部注入一段 预加载 CGI 的 JS 代码，维护一个CGI 与 DATA 对应 MAP，后面发请求的时候，先去 MAP 里取值，如果有值的话直接拿出来，没有的话则发起HTTP 请求。（具体请查阅我们团队开源的 Preload 工具） [图片] 这种模式还有一些其他的优化的方法： 在 HTML 内实现 Loading 态或者骨架屏； 去掉外联 css； 使用动态 polyfill； 使用 SplitChunksPlugin 拆分公共代码； 正确地使用 Webpack 4.0 的 Tree Shaking； 使用动态 import，切分页面代码，减小首屏 JS 体积； 编译到 ES2015+，提高代码运行效率，减小体积； 使用 lazyload 和 placeholder 提升加载体验。 这种模式的优化不是我们这次讲述的重点，想了解的童鞋可以查看这篇文章。 效果如下图所示： [图片] 直出同构 在异步的模式下，除了上述优化，我们还在端内（企鹅辅导 APP、手机 QQ）内做了离线包缓存（腾讯手Q方面独立研发出来的针对手机端优化的方案，简而言之就是将静态资源缓存在手机 APP 内），经过我们的数据测试，首屏渲染大概能够达到秒开（1s左右) 的效果。 [图片] 但对有着性能极致追求的我们来说，肯定是不会满意的。 继续优化，最容易、最大众的套路肯定就是直出（服务端渲染）了。 [图片] 现在直出的方案已经有很多很多种，这里也不多做介绍了，如果您想了解更多关于服务端渲染的方案，请参考这篇文章。 直出针对首屏时间的优化效果是非常明显的，经过我们的测试，数据大概能够提升**25%**左右。 直出之后的效果如下图： [图片] 可以看到对于首屏来说，没有了**【加载中…】**的等待时间，视觉体验提升了不少。 PWA 直出 [图片] 针对上述、常见的直出应用来说，我们能够优化的点在哪里呢？让我们来详细分析一波，这也是今天我们要给大家分享的重点。 首先看看直出应用各个环节的耗时表 (本地环境 2018款 iMac）： 过程名称 过程花费 Node 内 CGI 拉取 300 ms RenderToString 20 ms 网络耗时 10 ms 前端HTML渲染 30 ms 从上面的表中我们看出，直出渲染的耗时的大头还是在 CGI 接口的拉取上。 我们现在提出两个问题： CGI 接口的数据是否可以缓存 ? HTML 又是否可以缓存 ? 一、接口的动静分离 [图片] 这个页面的接口数据中，有一些数据，是实时变动的, 比如：当前还剩多少个名额、此时此刻课程的价格、用户是否购买过这个课程等。 这些数据的特性决定了这个数据接口不能够被缓存。（假设将其缓存，那么就会存在可能用户进来看到当前还剩下10个名额，其实课程已经卖光了的情况） 为了这个时间耗时的大头，我们做了CGI接口的动静分离。 将与用户态、当前时间没有关联的数据（比如[代码]课程标题[代码]、[代码]课程上课的时间[代码]、[代码]试听模块的地址[代码]等）放在一个接口（静态接口），其他变化的数据放在另一个接口（动态接口）。 那么可以使用静态的接口来做服务端渲染，好处是第一比较快（少了动态的信息，而且后台也可以做缓存），第二 Node 直出可以做缓存了。 二、直出 Redis 缓存 这样我们就可以将那部分静态的、不会经常变动的数据用来直出 HTML，然后将这个 HTML 文件缓存到 Redis 中。 客户端请求此网页，Node 端接受到请求之后，先去 Redis 里拿缓存的 HTML，如果 Redis 缓存没有命中，则拉取静态的 CGI 接口渲染出 HTML存入 Redis。 客户端拿到 HTML 之后，会立刻渲染，然后再用 JS 去请求动态的数据，渲染到相应的地方。 [图片] 做完之后我们可以看到优化效果的提升是非常非常明显的： [图片] 直接从 262ms 提升到了 16ms ！（本地环境），简直飞一般的感觉，妈妈再也不用担心领导看耗时了。 三、PWA 直出缓存 关于什么是 PWA ，以及如何使用，请移步这篇文章。 做了 Node 端直出的 HTML 缓存之后，我们接着优化，接着思考，是否可以在客户端也缓存 HTML，这样连网络延时这部分消耗也省掉呢。 答案就是使用 PWA 在客户端做离线缓存，将我们直出的 HTML 缓存在客户端，每次用户请求的时候，直接从 PWA 离线缓存里取出对应的直出页面（HTML）响应给用户，响应之后紧接着请求 Node 服务更新本地的 PWA 缓存。(如下图所示） [图片] 核心代码： [代码]self.addEventListener("fetch", event => { // TODO other logic (maybe fetch filter) // core logic event.respondWith( caches.open(cacheName).then(function(cache) { return cache.match(cacheCourseUrl).then(function(response) { var fetchPromise = fetch(cacheCourseUrl).then(function( networkResponse ) { if (networkResponse.status === 200) { cache.put(cacheCourseUrl, networkResponse.clone()); } return networkResponse; }); return response || fetchPromise; }); }) ); }); [代码] 废话不多说，先看效果对比 (左 PWA 直出；右 离线包）： [图片] 从上图可以看出，使用了 PWA 直出缓存之后，首屏渲染基本是毫秒开，可以说与 Native 并肩了。 经过我们的数据测试，使用 PWA 直出缓存，首屏渲染的时间最好可以到400ms左右级别： [图片] PWA 直出细节优化 一、防页面跳动 因为对接口进行了动静分离，使用静态接口直出页面，然后在客户端拉取动态数据渲染完。这就可能会导致页面的抖动（比如详情页中的试听模块，是在客户端渲染的）。 [图片] 因为高度改变了，视觉上就会出现抖动（具体可以参考上面章节直出时候的 GIF 截图）。 要去掉页面抖动的情况，就必须保证容器的高度在直出时候已经存在了。 比如这个试听模块，其实这个封面图和试听按钮是可以在服务端渲染出来的，而后面的 Video 模块则必须要在客户度渲染（腾讯云 Tcplayer）。 所以这里可以拆分成：（试听封面 + 按钮 + 时间）服务端渲染 + 底层 Video（客户端渲染）。 有些需要在客户端计算高度的容器（表现为常放在 ComponentDidMount 里计算），如果它们依赖客户端环境（比如依赖当前系统是安卓还是 IOS），就导致他们肯定不能放在服务端直接渲染出来，这又怎么办呢? 这里我们的做法，是将这些计算放在 HTML body 之前，通过内联的脚本嵌入，计算出当前环境，给 body 加上一个特定的类（class），然后在这个特定的类下面的元素，就可以通过 css 给予特定的样式。比如下面代码： [代码]/* * 因为在不同的手机 APP 环境内，页面的 padding 是不一样的。 * 我们要在页面渲染完之前加上相应的 padding */ var REGEXP_FUDAO_APP = /EducationApp/; if ( typeof navigator !== "undefined" && REGEXP_FUDAO_APP.test(navigator.userAgent) ) { if (/Android/i.test(navigator.userAgent)) { document.body.classList.add("androidFudaoApp"); } else if (/iPhone|iPad|iPod|iOS/i.test(navigator.userAgent)) { if (window.screen.width === 375 && window.screen.height === 812) { document.body.classList.add("iphoneXFudaoApp"); } else { document.body.classList.add("iosFudaoApp"); } } } [代码] [代码].androidFudaoApp .tt { padding-top: 48px; background-position-y: 84px; } .iphoneXFudaoApp .tt { padding-top: 88px; background-position-y: 124px; } .iosFudaoApp .tt { padding-top: 64px; background-position-y: 100px; } [代码] 然后把这段代码通过构建插入到页面 body 之前。 [图片] 防抖动优化效果如下 (左优化完，右未优化）： [图片] 二、冷启动预加载 虽然我们做了 PWA 离线缓存，但是对于冷启动来说，客户端里面的 PWA 缓存还是没有的，这样就会导致初次点击页面，渲染速度相对慢一点。 这里我们可以在 APP 启动的时候，用一个预加载的脚本最大限度的拉取用户可能访问的页面。 核心代码如下： [代码]// 预加载页面时， PWA 预缓存课程详情页面的直出 function prefetchCache(fetchUrl) { fetch("https://you preFetch Cgi") .then(data => { return data.json(); }) .then(res => { const { courseInfo = [] } = res.result || {}; courseInfo.forEach(item => { if (item.cid) { caches.open(cacheName).then(function(cache) { fetch(`${courseURL}?course_id=${item.cid}`).then(function( networkResponse ) { if (networkResponse.status === 200) { cache.put( `${courseURL}?course_id=${item.cid}`, networkResponse.clone() ); } // return networkResponse; }); }); } }); }) .catch(err => { // To monitor err }); } [代码] PWA 直出遗留问题 一、兼容性问题 随着 PWA 技术的发展，现今大部分手机以及 PC 环境已经支持对 PWA 进行了支持。经过我们的测试发现：安卓基本上都是支持的，IOS 需要11.3以上才支持。 Service Workers 兼容性图 [图片] 具体的兼容性支持点我查看。 二、IOS 渲染问题 很多的经验告诉我们，外联的 script 标签要放在 body 的后面，因为它会阻塞页面的 DOM 渲染。 经过测试发现，IOS 的 [代码]WebView[代码] ([代码]UIWebView[代码])渲染机制并不会上述一样，而是要等到后面的 JS 执行完之后才渲染页面，如果是这样，我们的直出渲染优化就没有效果了（因为 HTML 并不在最开始渲染），这里可以使用 [代码]script[代码] 标签的 [代码]async[代码] 与 [代码]defer[代码] 属性来达到异步渲染的作用。 升级 WkWebView 之后，情况得到改善，渲染正常。 附录 参考资料 PWA 的探索与最佳实践 亿万级访问量下的前端同构直出实践 React 16 加载性能优化指南 更多基于 PWA 的性能优化实践，请查看 IMWeb 团队刘华的分享。.com/course/16777)。

作为前端的设计师和工程师，我们用 CSS 去做样式、定位并创建出好看的网站。我们经常用 CSS 去添加页面的运动过渡效果甚至动画，但我们经常做的不过如此。 [代码] 动效是一个有助于访客和用户理解我们设计的强有力工具。这里有些原则能最大限度地应用在我们的工作中。 迪士尼经过基础工作练习的长时间累积，在 1981 年出版的 The Illusion of Life: Disney Animation 一书中发表了动画的十二个原则 ([] (https://en.wikipedia.org/wiki/12_basic_principles_of_animation)) 。这些原则描述了动画能怎样用于让观众相信自己沉浸在现实世界中。 [代码] 在本文中，我会逐个介绍这十二个原则，并讨论它们怎样运用在网页中。你能在 Codepen 找到它们[] (https://codepen.io/collection/AxKOdY/)。 挤压和拉伸 (Squash and stretch) [图片] 这是物体存在质量且运动时质量保持不变的概念。当一个球在弹跳时，碰击到地面会变扁，恢复的时间会越来越短。 [代码] 创建对象的时候最有用的方法是参照实物，比如人、时钟和弹性球。 当它和网页元件一起工作时可能会忽略这个原则。DOM 对象不一定和实物相关，它会按需要在屏幕上缩放。例如，一个按钮会变大并变成一个信息框，或者错误信息会出现和消失。 尽管如此，挤压和伸缩效果可以为一个对象增加实物的感觉。甚至一些形状上的小变化就可以创造出细微但抢眼的效果。 HTML [代码] [代码] <h1>Principle 1: Squash and stretch</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle one"> <div class="shape"></div> <div class="surface"></div> </article> [代码] CSS [代码].one .shape { animation: one 4s infinite ease-out; } .one .surface { background: #000; height: 10em; width: 1em; position: absolute; top: calc(50% - 4em); left: calc(50% + 10em); } @keyframes one { 0%, 15% { opacity: 0; } 15%, 25% { transform: none; animation-timing-function: cubic-bezier(1,-1.92,.95,.89); width: 4em; height: 4em; top: calc(50% - 2em); left: calc(50% - 2em); opacity: 1; } 35%, 45% { transform: translateX(8em); height: 6em; width: 2em; top: calc(50% - 3em); animation-timing-function: linear; opacity: 1; } 70%, 100% { transform: translateX(8em) translateY(5em); height: 6em; width: 2em; top: calc(50% - 3em); opacity: 0; } } body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 预备动作 (Anticipation) [图片] 运动不倾向于突然发生。在现实生活中，无论是一个球在掉到桌子前就开始滚动，或是一个人屈膝准备起跳，运动通常有着某种事先的累积。 [代码] 我们能用它去让我们的过渡动画显得更逼真。预备动作可以是一个细微的反弹，帮人们理解什么对象将在屏幕中发生变化并留下痕迹。 例如，悬停在一个元件上时可以在它变大前稍微缩小，在初始列表中添加额外的条目来介绍其它条目的移除方法。 [代码] HTML [代码]<h1>Principle 2: Anticipation</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle two"> <div class="shape"></div> <div class="surface"></div> </article> [代码] CSS [代码].two .shape { animation: two 5s infinite ease-out; transform-origin: 50% 7em; } .two .surface { background: #000; width: 8em; height: 1em; position: absolute; top: calc(50% + 4em); left: calc(50% - 3em); } @keyframes two { 0%, 15% { opacity: 0; transform: none; } 15%, 25% { opacity: 1; transform: none; animation-timing-function: cubic-bezier(.5,.05,.91,.47); } 28%, 38% { transform: translateX(-2em); } 40%, 45% { transform: translateX(-4em); } 50%, 52% { transform: translateX(-4em) rotateZ(-20deg); } 70%, 75% { transform: translateX(-4em) rotateZ(-10deg); } 78% { transform: translateX(-4em) rotateZ(-24deg); opacity: 1; } 86%, 100% { transform: translateX(-6em) translateY(4em) rotateZ(-90deg); opacity: 0; } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 演出布局 (Staging) [图片] 演出布局是确保对象在场景中得以聚焦，让场景中的其它对象和视觉在主动画发生的地方让位。这意味着要么把主动画放到突出的位置，要么模糊其它元件来让用户专注于看他们需要看的东西。 [代码] 在网页方面，一种方法是用 model 覆盖在某些内容上。在现有页面添加一个遮罩并把那些主要关注的内容前置展示。 另一种方法是用动作。当很多对象在运动，你很难知道哪些值得关注。如果其它所有的动作停止，只留一个在运动，即使动得很微弱，这都可以让对象更容易被察觉。 [代码] 还有一种方法是做一个晃动和闪烁的按钮来简单地建议用户比如他们可能要保存文档。屏幕保持静态，所以再细微的动作也会突显出来。 HTML [代码]<h1>Principle 3: Staging</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle three"> <div class="shape a"></div> <div class="shape b"></div> <div class="shape c"></div> </article> [代码] CSS [代码].three .shape.a { transform: translateX(-12em); } .three .shape.c { transform: translateX(12em); } .three .shape.b { animation: three 5s infinite ease-out; transform-origin: 0 6em; } .three .shape.a, .three .shape.c { animation: threeb 5s infinite linear; } @keyframes three { 0%, 10% { transform: none; animation-timing-function: cubic-bezier(.57,-0.5,.43,1.53); } 26%, 30% { transform: rotateZ(-40deg); } 32.5% { transform: rotateZ(-38deg); } 35% { transform: rotateZ(-42deg); } 37.5% { transform: rotateZ(-38deg); } 40% { transform: rotateZ(-40deg); } 42.5% { transform: rotateZ(-38deg); } 45% { transform: rotateZ(-42deg); } 47.5% { transform: rotateZ(-38deg); animation-timing-function: cubic-bezier(.57,-0.5,.43,1.53); } 58%, 100% { transform: none; } } @keyframes threeb { 0%, 20% { filter: none; } 40%, 50% { filter: blur(5px); } 65%, 100% { filter: none; } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 连续运动和姿态对应 (Straight-Ahead Action and Pose-to-Pose) [图片] 连续运动是绘制动画的每一帧，姿态对应是通常由一个 assistant 在定义一系列关键帧后填充间隔。 [代码] 大多数网页动画用的是姿态对应：关键帧之间的过渡可以通过浏览器在每个关键帧之间的插入尽可能多的帧使动画流畅。 [代码] 有一个例外是定时功能step。通过这个功能，浏览器 “steps” 可以把尽可能多的无序帧串清晰。你可以用这种方式绘制一系列图片并让浏览器按顺序显示出来，这开创了一种逐帧动画的风格。 HTML [代码]<h1>Principle 4: Straight Ahead Action and Pose to Pose</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle four"> <div class="shape a"></div> <div class="shape b"></div> </article> [代码] CSS [代码].four .shape.a { left: calc(50% - 8em); animation: four 6s infinite cubic-bezier(.57,-0.5,.43,1.53); } .four .shape.b { left: calc(50% + 8em); animation: four 6s infinite steps(1); } @keyframes four { 0%, 10% { transform: none; } 26%, 30% { transform: rotateZ(-45deg) scale(1.25); } 40% { transform: rotateZ(-45deg) translate(2em, -2em) scale(1.8); } 50%, 75% { transform: rotateZ(-45deg) scale(1.1); } 90%, 100% { transform: none; } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 跟随和重叠动作 (Follow Through and Overlapping Action) [图片] 事情并不总在同一时间发生。当一辆车从急刹到停下，车子会向前倾、有烟从轮胎冒出来、车里的司机继续向前冲。 [代码] 这些细节是跟随和重叠动作的例子。它们在网页中能被用作帮助强调什么东西被停止，并不会被遗忘。例如一个条目可能在滑动时稍滑微远了些，但它自己会纠正到正确位置。 要创造一个重叠动作的感觉，我们可以让元件以稍微不同的速度移动到每处。这是一种在 iOS 系统的视窗 (View) 过渡中被运用得很好的方法。一些按钮和元件以不同速率运动，整体效果会比全部东西以相同速率运动要更逼真，并留出时间让访客去适当理解变化。 [代码] 在网页方面，这可能意味着让过渡或动画的效果以不同速度来运行。 HTML [代码]<h1>Principle 5: Follow Through and Overlapping Action</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle five"> <div class="shape-container"> <div class="shape"></div> </div> </article> [代码] CSS [代码].five .shape { animation: five 4s infinite cubic-bezier(.64,-0.36,.1,1); position: relative; left: auto; top: auto; } .five .shape-container { animation: five-container 4s infinite cubic-bezier(.64,-0.36,.1,2); position: absolute; left: calc(50% - 4em); top: calc(50% - 4em); } @keyframes five { 0%, 15% { opacity: 0; transform: translateX(-12em); } 15%, 25% { transform: translateX(-12em); opacity: 1; } 85%, 90% { transform: translateX(12em); opacity: 1; } 100% { transform: translateX(12em); opacity: 0; } } @keyframes five-container { 0%, 35% { transform: none; } 50%, 60% { transform: skewX(20deg); } 90%, 100% { transform: none; } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 缓入缓出 (Slow In and Slow Out) [图片] 对象很少从静止状态一下子加速到最大速度，它们往往是逐步加速并在停止前变慢。没有加速和减速，动画感觉就像机器人。 [代码] 在 CSS 方面，缓入缓出很容易被理解，在一个动画过程中计时功能是一种描述变化速率的方式。 [代码] 使用计时功能，动画可以由慢加速 (ease-in)、由快减速 (ease-out)，或者用贝塞尔曲线做出更复杂的效果。 HTML [代码]<h1>Principle 6: Slow in and Slow out</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle six"> <div class="shape a"></div> </article> [代码] CSS [代码].six .shape { animation: six 3s infinite cubic-bezier(0.5,0,0.5,1); } @keyframes six { 0%, 5% { transform: translate(-12em); } 45%, 55% { transform: translate(12em); } 95%, 100% { transform: translate(-12em); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 弧线运动 (Arc) [图片] 虽然对象是更逼真了，当它们遵循「缓入缓出」的时候它们很少沿直线运动——它们倾向于沿弧线运动。 我们有几种 CSS 的方式来实现弧线运动。一种是结合多个动画，比如在弹力球动画里，可以让球上下移动的同时让它右移，这时候球的显示效果就是沿弧线运动。 HTML [代码]<h1>Principle 7: Arc (1)</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle sevena"> <div class="shape-container"> <div class="shape a"></div> </div> </article> [代码] CSS [代码].sevena .shape-container { animation: move-right 6s infinite cubic-bezier(.37,.55,.49,.67); position: absolute; left: calc(50% - 4em); top: calc(50% - 4em); } .sevena .shape { animation: bounce 6s infinite linear; border-radius: 50%; position: relative; left: auto; top: auto; } @keyframes move-right { 0% { transform: translateX(-20em); opacity: 1; } 80% { opacity: 1; } 90%, 100% { transform: translateX(20em); opacity: 0; } } @keyframes bounce { 0% { transform: translateY(-8em); animation-timing-function: cubic-bezier(.51,.01,.79,.02); } 15% { transform: translateY(8em); animation-timing-function: cubic-bezier(.19,1,.7,1); } 25% { transform: translateY(-4em); animation-timing-function: cubic-bezier(.51,.01,.79,.02); } 32.5% { transform: translateY(8em); animation-timing-function: cubic-bezier(.19,1,.7,1); } 40% { transform: translateY(0em); animation-timing-function: cubic-bezier(.51,.01,.79,.02); } 45% { transform: translateY(8em); animation-timing-function: cubic-bezier(.19,1,.7,1); } 50% { transform: translateY(3em); animation-timing-function: cubic-bezier(.51,.01,.79,.02); } 56% { transform: translateY(8em); animation-timing-function: cubic-bezier(.19,1,.7,1); } 60% { transform: translateY(6em); animation-timing-function: cubic-bezier(.51,.01,.79,.02); } 64% { transform: translateY(8em); animation-timing-function: cubic-bezier(.19,1,.7,1); } 66% { transform: translateY(7.5em); animation-timing-function: cubic-bezier(.51,.01,.79,.02); } 70%, 100% { transform: translateY(8em); animation-timing-function: cubic-bezier(.19,1,.7,1); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] [图片] 另外一种是旋转元件，我们可以设置一个在对象之外的原点来作为它的旋转中心。当我们旋转这个对象，它看上去就是沿着弧线运动。 HTML [代码]<h1>Principle 7: Arc (2)</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle sevenb"> <div class="shape a"></div> <div class="shape b"></div> </article> [代码] CSS [代码].sevenb .shape.a { animation: sevenb 3s infinite linear; top: calc(50% - 2em); left: calc(50% - 9em); transform-origin: 10em 50%; } .sevenb .shape.b { animation: sevenb 6s infinite linear reverse; background-color: yellow; width: 2em; height: 2em; left: calc(50% - 1em); top: calc(50% - 1em); } @keyframes sevenb { 100% { transform: rotateZ(360deg); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 次要动作 (Secondary Action) [图片] 虽然主动画正在发生，次要动作可以增强它的效果。这就好比某人在走路的时候摆动手臂和倾斜脑袋，或者弹性球弹起的时候扬起一些灰尘。 在网页方面，当主要焦点出现的时候就可以开始执行次要动作，比如拖拽一个条目到列表中间。 HTML [代码]<h1>Principle 8: Secondary Action</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle eight"> <div class="shape a"></div> <div class="shape b"></div> <div class="shape c"></div> </article> [代码] CSS [代码].eight .shape.a { transform: translateX(-6em); animation: eight-shape-a 4s cubic-bezier(.57,-0.5,.43,1.53) infinite; } .eight .shape.b { top: calc(50% + 6em); opacity: 0; animation: eight-shape-b 4s linear infinite; } .eight .shape.c { transform: translateX(6em); animation: eight-shape-c 4s cubic-bezier(.57,-0.5,.43,1.53) infinite; } @keyframes eight-shape-a { 0%, 50% { transform: translateX(-5.5em); } 70%, 100% { transform: translateX(-10em); } } @keyframes eight-shape-b { 0% { transform: none; } 20%, 30% { transform: translateY(-1.5em); opacity: 1; animation-timing-function: cubic-bezier(.57,-0.5,.43,1.53); } 32% { transform: translateY(-1.25em); opacity: 1; } 34% { transform: translateY(-1.75em); opacity: 1; } 36%, 38% { transform: translateY(-1.25em); opacity: 1; } 42%, 60% { transform: translateY(-1.5em); opacity: 1; } 75%, 100% { transform: translateY(-8em); opacity: 1; } } @keyframes eight-shape-c { 0%, 50% { transform: translateX(5.5em); } 70%, 100% { transform: translateX(10em); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 时间节奏 (Timing) [图片] 动画的时间节奏是需要多久去完成，它可以被用来让看起来很重的对象做很重的动画，或者用在添加字符的动画中。 [代码] 这在网页上可能只要简单调整 animation-duration 或 transition-duration 值。 [代码] 这很容易让动画消耗更多时间，但调整时间节奏可以帮动画的内容和交互方式变得更出众。 HTML [代码]<h1>Principle 9: Timing</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle nine"> <div class="shape a"></div> <div class="shape b"></div> </article> [代码] CSS [代码].nine .shape.a { animation: nine 4s infinite cubic-bezier(.93,0,.67,1.21); left: calc(50% - 12em); transform-origin: 100% 6em; } .nine .shape.b { animation: nine 2s infinite cubic-bezier(1,-0.97,.23,1.84); left: calc(50% + 2em); transform-origin: 100% 100%; } @keyframes nine { 0%, 10% { transform: translateX(0); } 40%, 60% { transform: rotateZ(90deg); } 90%, 100% { transform: translateX(0); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 夸张手法 (Exaggeration) [图片] 夸张手法在漫画中是最常用来为某些动作刻画吸引力和增加戏剧性的，比如一只狼试图把自己的喉咙张得更开地去咬东西可能会表现出更恐怖或者幽默的效果。 在网页中，对象可以通过上下滑动去强调和刻画吸引力，比如在填充表单的时候生动部分会比收缩和变淡的部分更突出。 HTML [代码]<h1>Principle 10: Exaggeration</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle ten"> <div class="shape"></div> </article> [代码] CSS [代码].ten .shape { animation: ten 4s infinite linear; transform-origin: 50% 8em; top: calc(50% - 6em); } @keyframes ten { 0%, 10% { transform: none; animation-timing-function: cubic-bezier(.87,-1.05,.66,1.31); } 40% { transform: rotateZ(-45deg) scale(2); animation-timing-function: cubic-bezier(.16,.54,0,1.38); } 70%, 100% { transform: rotateZ(360deg) scale(1); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 扎实的描绘 (Solid drawing) [图片] 当动画对象在三维中应该加倍注意确保它们遵循透视原则。因为人们习惯了生活在三维世界里，如果对象表现得与实际不符，会让它看起来很糟糕。 如今浏览器对三维变换的支持已经不错，这意味着我们可以在场景里旋转和放置三维对象，浏览器能自动控制它们的转换。 HTML [代码]<h1>Principle 11: Solid drawing</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle eleven"> <div class="shape"> <div class="container"> <span class="front"></span> <span class="back"></span> <span class="left"></span> <span class="right"></span> <span class="top"></span> <span class="bottom"></span> </div> </div> </article> [代码] CSS [代码].eleven .shape { background: none; border: none; perspective: 400px; perspective-origin: center; } .eleven .shape .container { animation: eleven 4s infinite cubic-bezier(.6,-0.44,.37,1.44); transform-style: preserve-3d; } .eleven .shape span { display: block; position: absolute; opacity: 1; width: 4em; height: 4em; border: 1em solid #fff; background: #2d97db; } .eleven .shape span.front { transform: translateZ(3em); } .eleven .shape span.back { transform: translateZ(-3em); } .eleven .shape span.left { transform: rotateY(-90deg) translateZ(-3em); } .eleven .shape span.right { transform: rotateY(-90deg) translateZ(3em); } .eleven .shape span.top { transform: rotateX(-90deg) translateZ(-3em); } .eleven .shape span.bottom { transform: rotateX(-90deg) translateZ(3em); } @keyframes eleven { 0% { opacity: 0; } 10%, 40% { transform: none; opacity: 1; } 60%, 75% { transform: rotateX(-20deg) rotateY(-45deg) translateY(4em); animation-timing-function: cubic-bezier(1,-0.05,.43,-0.16); opacity: 1; } 100% { transform: translateZ(-180em) translateX(20em); opacity: 0; } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码] 吸引力 (Appeal) [图片] 吸引力是艺术作品的特质，让我们与艺术家的想法连接起来。就像一个演员身上的魅力，是注重细节和动作相结合而打造吸引性的结果。 [代码] 精心制作网页上的动画可以打造出吸引力，例如 Stripe 这样的公司用了大量的动画去增加它们结账流程的可靠性。 [代码] HTML [代码]<h1>Principle 12: Appeal</h1> <h2><a href="https://cssanimation.rocks/principles/" target="_parent">Animation Principles for the Web</h2> <article class="principle twelve"> <div class="shape"> <div class="container"> <span class="item one"></span> <span class="item two"></span> <span class="item three"></span> <span class="item four"></span> </div> </div> </article> [代码] CSS [代码].twelve .shape { background: none; border: none; perspective: 400px; perspective-origin: center; } .twelve .shape .container { animation: show-container 8s infinite cubic-bezier(.6,-0.44,.37,1.44); transform-style: preserve-3d; width: 4em; height: 4em; border: 1em solid #fff; background: #2d97db; position: relative; } .twelve .item { background-color: #1f7bb6; position: absolute; } .twelve .item.one { animation: show-text 8s 0.1s infinite ease-out; height: 6%; width: 30%; top: 15%; left: 25%; } .twelve .item.two { animation: show-text 8s 0.2s infinite ease-out; height: 6%; width: 20%; top: 30%; left: 25%; } .twelve .item.three { animation: show-text 8s 0.3s infinite ease-out; height: 6%; width: 50%; top: 45%; left: 25%; } .twelve .item.four { animation: show-button 8s infinite cubic-bezier(.64,-0.36,.1,1.43); height: 20%; width: 40%; top: 65%; left: 30%; } @keyframes show-container { 0% { opacity: 0; transform: rotateX(-90deg); } 10% { opacity: 1; transform: none; width: 4em; height: 4em; } 15%, 90% { width: 12em; height: 12em; transform: translate(-4em, -4em); opacity: 1; } 100% { opacity: 0; transform: rotateX(-90deg); width: 4em; height: 4em; } } @keyframes show-text { 0%, 15% { transform: translateY(1em); opacity: 0; } 20%, 85% { opacity: 1; transform: none; } 88%, 100% { opacity: 0; transform: translateY(-1em); animation-timing-function: cubic-bezier(.64,-0.36,.1,1.43); } } @keyframes show-button { 0%, 25% { transform: scale(0); opacity: 0; } 35%, 80% { transform: none; opacity: 1; } 90%, 100% { opacity: 0; transform: scale(0); } } /* General styling */ body { margin: 0; background: #e9b59f; font-family: HelveticaNeue, Arial, Sans-serif; color: #fff; } h1 { position: absolute; top: 0; left: 0; right: 0; text-align: center; font-weight: 300; } h2 { font-size: 0.75em; position: absolute; bottom: 0; left: 0; right: 0; text-align: center; } a { text-decoration: none; color: #333; } .principle { width: 100%; height: 100vh; position: relative; } .shape { background: #2d97db; border: 1em solid #fff; width: 4em; height: 4em; position: absolute; top: calc(50% - 2em); left: calc(50% - 2em); } [代码]

用navigator 跳转另一小程序带参数，走不走被打开的小程序的app。js里面的方法吗/

希望能够有动画相关的钩子

- 当前 Bug 的表现（可附上截图） wifi，ios网络环境，安卓wifi环境都是可以正常访问服务器的，但是就是有一种奇葩的问题就是电信4g（部分手机的移动也不行）无法访问我们的服务器（咨询阿里客服，dns，ipv6,ipv4都能ping通）。这个问题你说是我小程序代码有问题那安卓wifi环境下怎么能正常访问，问服务器证书，dns都检查了一遍都没问题。请问是哪出了问题？？？这TM头一回遇见这种无法定位的问题 - 预期表现 - 复现路径 - 提供一个最简复现 Demo

- 临时登录凭证code的作用机制到底是怎样的？直接获取微信用户id的做法有什么问题呢 教程中专门阐述了这个问题，https://developers.weixin.qq.com/ebook?action=get_post_info&token=935589521&volumn=1&lang=zh_CN&book=miniprogram&docid=000cc48f96c5989b0086ddc7e56c0a#_ftn5，但是不能很好地帮助理解，特别是： 如果直接通过wx.login获取微信用户id。假设现在我们有个接口，通过wx.request请求 https://test.com/getUserInfo?id=1拉取到微信用户id为1在我们业务侧的个人信息，那么黑客就可以通过遍历所有的id，把整个业务侧的个人信息数据全部拉走。 这个临时身份证5分钟后会过期，如果黑客要冒充一个用户的话，那他就必须在5分钟内穷举所有的身份证id，然后去开发者服务器换取真实的用户身份。显然，黑客要付出非常大的成本才能获取到一个用户信息。 怎么遍历、穷举?是穷举openid吗？ 所谓冒充一个用户是怎么冒充？ 按这个意思就是5分钟之内要拿这个code去一遍又一遍地换取openid，拿什么去换？肯定是要登录一个微信才能去操作啊。 比较混乱，希望有专业清晰的解答。

大家好，在我司的小程序里，已经实现通过WebSocket发送文本消息。请问，能发送语音消息吗？

为了优化用户的使用体验，平台将回收“使用 wx.getUserInfo 接口直接弹出授权框”以及“使用 wx.authorize 接口直接申请提前授权用户信息”的能力，开发者需要使用组件方式唤起登录授权弹窗。 2018年10月10日后发布新版本的小程序，将无法在线上版本中使用接口直接弹出授权框。开发者可结合平台设计建议，提前做好兼容，合理使用微信登录能力。 能力调整背景 怎么合理使用微信登录能力 小程序登录流程设计建议 01 能力调整背景 推出微信登录能力的初衷是希望：当用户使用小程序时，可以便捷地使用微信身份登录小程序。但在实际使用场景中，我们发现：很多开发者在打开小程序时直接弹出授权框，如果用户点击拒绝授权，无法使用小程序。 在用户无法获知当前小程序服务内容的情况下，很多用户就会选择拒绝授权并离开当前小程序。所以“一进入小程序就要求用户授权”的做法打断了用户正常使用小程序的流程，同时也不利于小程序获取新用户。 所以平台调整登录接口，回收“使用 wx.getUserInfo 接口直接弹出授权框”以及“使用 wx.authorize 接口直接申请提前授权用户信息”的能力，并鼓励开发者参照以下指引合理改造小程序内的登录流程。 02 怎么合理使用微信登录能力 平台分别提供多种方式实现微信登录： 1. 调用wx.login接口，静默获取openid 适用场景：无需使用用户头像、昵称、Unionid信息 2. 使用 open-data （小程序）或者开放数据域（小游戏）的方式展示用户信息（无需用户授权） 适用场景：需要在前端“展示”用户头像、昵称信息，但不需要获取Unionid 3.使用button（小程序）或UserInfoButton（小游戏）组件，用户点击后弹窗请求用户授权 适用场景：需要获取用户头像、昵称、Unionid等基本信息 开发建议 第一步：获取openID 当用户访问小程序时，先通过wx.login，获取用户openID 。这时无需弹框授权，开发者拿到 openID 可以建立自身的帐号 ID。 第二步： 使用open-data方式或开放数据域方式展示头像昵称 如需要在前端展示用户头像、昵称信息， 使用open-data 方式或者开放数据域的方式展示用户信息 第三步：根据实际使用场景，使用组件，引导用户登录 在关键操作中，如必须获取用户头像、昵称、UnionID信息，可根据第一步获取的openID判断是新用户还是旧用户：     如果是旧用户，可以直接登录，也可定期使用wx.getUserInfo更新用户的信息；     如果是新用户，使用button（小程序）或UserInfoButton（小游戏）组件，在用户点击后弹窗请求获取用户基本信息。 03 小程序登录流程设计建议 a. 在必须用到登录信息的环节引导用户登录 在用户必须登录时才引导用户登录（如：购买前需要获取会员信息，用于同步积分数据），而不是用户一进入小程序就弹窗要求用户授权。如只需要在前端展示用户头像、昵称，无需要求用户授权，可直接展示。 [图片] b.清晰、准确地引导用户登录 在登录页面中，清晰、准确地告知用户当前操作是登录，说明获取登录信息的目的（如：用于同步会员积分数据等） [图片] c. 不强制用户必须登录后才能使用小程序服务 提供游客模式，不强制用户必须登录后才能进入小程序。如要求必须授权头像昵称等信息才能继续使用小程序，会导致某些用户放弃使用该小程序。 [图片]

文件系统能力 文件系统能力可便于用户在客户端保存文件资源，并在下次启动客户端之后可以使用已保存的文件。 只要用户不主动删除小程序或小游戏，并保持一定的使用频率，文件都可以一直被保留。 合理的使用文件系统能力来缓存资源文件，可以给开发者更好的使用体验。 今天，我们来分享文件系统能力的小故事。 1 文件系统的演进历史 小程序在最早发布的版本中就已提供了最基础的文件存储和删除接口：wx.saveFile、 wx.removeSavedFile ； 对于绝大部分的小程序来说，这两个接口已经能够满足开发者的需求。但对于小游戏来说，需要更完整的能力来做支撑。 因此，发布小游戏的时候我们便提供了一套更完整的文件管理系统：FileSystemManager，其中主要包含了目录管理、文件内容读写等能力。 2 文件系统的设计背景 文件系统能力是应小游戏开发需求的迭代而逐步增强的。在小程序的场景下，很多时候只是需要把一个图片或视频资源缓存起来便可继续使用，文件内容与文件存储的目录结构都不是开发者所关心的。 但是在小游戏场景下情况则不同—— 一方面，小游戏除了有图片和视频文件、还有游戏引擎生成的配置文件，游戏需要能够去读取并理解配置文件的具体内容； 另一方面，游戏使用的资源文件会比普通小程序更多，若没有内容目录管理的功能，维护成本会变高。 除此之外，由于小游戏代码包大小限制只有4MB (加上分包最多8MB)，对于一些偏重的游戏，资源甚至容易超100MB。 因此在此大背景下，我们给文件系统主要增加了目录管理、文件内容读写等两项接口—— 目录管理的需求场景是在使用游戏引擎时需要按目录来管理资源文件，文件内容读写的需求场景是在使用游戏引擎时需要读取配置文件；同时，我们对小游戏类目的本地存储容量的规范限制扩容到50MB。 开发者可能会疑惑，为什么在小程序的文件系统中会有一些功能相接近的接口？例如，想缓存一个文件，可以用 saveFile 或 copyFile ；再比如 removeSavedFile和 unlink 都可以用来删除一个文件。 上述情况的原因是我们在早期便提供了基础的文件存储接口 saveFile 和removeFile ，但不提供自定义目录相关的能力，开发者调用 saveFile 之后只能得到微信返回到的一个随机文件名。 小游戏应运而生的同时也增强了对文件系统能力扩展的需求，为了保证向后兼容，我们保留了这批基础接口，并在这个基础上增加了目录管理接口以及对应的文件操作接口。因此，便出现了上述一些相似接口的情况。 3 文件系统的优势—存储隔离 有不少开发者询问过关于文件存储的问题，他们担心文件内容被其他小程序读取到，也担心多个登录用户之间的文件内容会互相影响。为了保证用户的隐私安全，也为了保证小程序的数据安全，本地文件存储的一个重要规则便是保证隔离。 文件被存储到本地后，会以小程序账号和用户账号两个不同的维度来区分和隔离。即：同个微信用户使用不同小程序之间的文件存储会互相隔离；不同微信用户（在同一台手机中）使用同个小程序时，不同用户间的文件存储也会互相隔离。 [图片] 4 适当的存储容量 考虑到存储的问题，我们规范了小游戏文件存储的容量。普通小程序是10MB，小游戏则是50MB，当文件存储超出限制时，写入的文件会失败。 功能上线以后，我们曾收到过若干宝贵意见与反馈，希望能提高容量限制。但在经过反复论证与评估后，我们认为如果将文件存储的容量再往上提，就会有用户新增需要管理或清理手机存储空间的需求，小程序和小游戏将会变得不再“小”了。对于资源文件超过上述标准限制的小程序与小游戏，应该合理地管理本地文件，及时清理不常用的文件，这样在大多数情况下，手机存储空间便能保证顺畅。 更多关于小程序文件系统能力的信息，可查阅 接口文档 。

有时候我们使用一个小程序会遇到以下情形： 我们打开一个小程序，就看见提示“分享到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 以上的环境受影响。 开发者需要注意，近期提交审核的版本都需要考虑兼容上述调整带来的影响，请各位开发者及时调整分享能力。

开发者在开发小程序的时候可能会碰到一些这样的问题： 问题1  开发者工具上看效果没问题，但是在真机上测试不行？ 问题2  有用户遇到小程序功能无法使用的问题，但无法快速定位解决？ 今天我们的小故事与大家分享一些真机定位的技巧，可以解决上面两个问题。 1 vConsole开发利器和远程调试功能 针对问题1，我们提供了 vConsole 开发利器和远程调试功能，可以协助开发者在定位真机上的问题。 vConsole 的有四个Tab面板，可以先看下 Log 面板，看是否有异常信息，异常类型 thirdScriptError 是框架捕捉到的开发者的代码执行的异常，可以优先处理异常信息看是否可以解决问题。Log 面板可以看到异常出现的文件和行数。 [图片] 除了异常日志，开发者还可以通过 console.log 接口在一些关键执行路径上打日志来定位问题，这些日志会呈现在 Log 面板上。 vConsole 默认是不开启的，可以通过下面2个方法来开启： 1 开发版和体验版可以点击小程序页面右上角的...按钮打开的菜单项“打开调试”来开启 vConsole。 2 正式版没有“打开调试”的菜单项，可以先通过开发版和体验版来开启 vConsole，然后再打开正式版。或者可以预埋一个隐藏操作，比如连续点击某个 Button 多次，然后调用 API 接口 wx.setEnableDebug 来打开。 vConsole 虽然强大，但在手机上查看大量的日志信息不方便，此外，vConsole 没有断点调试、无法修改样式，定位复杂问题需要花费比较多的时间。 小程序的业务逻辑运行在 AppService 层，页面渲染在 WebView 运行，并通过微信客户端通信，因此，我们想到了可以让 AppService 运行在开发者工具，页面渲染还是在手机 WebView，两者通过网络来通信，这样借助开发者工具的调试能力，就可以实现远程调试功能。 远程调试窗口通过手机客户端扫描开发者工具上生成的二维码来打开，无需像普通手机 H5 页面调试一样，需要在手机端进行一些设置。 [图片] 打开的远程调试界面和开发者工具的模拟器的调试界面很像，需要注意的是，要在 Console 里对小程序进行调试，需要将调试的上下文切换到 VM Context 1 。 [图片] 更多的远程调试的使用方法请参考使用文档。 2 意见反馈能力 对于问题2，小程序的使用反馈来自用户投诉，这种情况用户无法联系到开发者。我们遇见过有小程序功能出现问题，用户无法使用，但投诉无门的情况，而这些问题，开发者也没有途径去收集以及处理，这就导致了小程序服务质量下降，用户流失。 为此，我们开发了“意见反馈”功能，当出现问题时，开发者可以引导用户使用“意见反馈”进行反馈，并上传日志来辅助开发者定位问题。操作过程如下： 引导用户进入小程序帐号详情页面，具体可以在小程序界面点击右上角...按钮，选择关于菜单。接着在帐号详情页面点击右上角...按钮，选择意见反馈菜单进入页面。页面可以上传图片和日志，建议用户上传异常情况的截图，以及勾选允许开发者使用小程序日志选项上传日志，反馈信息越详细，越有助于定位问题。 [图片] [图片] 如果觉得上面的操作步骤太麻烦，开发者可以通过在页面 WXML 添加下面的按钮，用户点击按钮可以直接打开“意见反馈”页面。 [图片] 开发者需要定时处理用户的反馈，这样才能保证小程序的质量。开发者可以登录小程序管理后台，进入左侧菜单客服反馈，就可以看到用户的反馈内容以及下载日志来辅助定位问题。 [图片] 为了保证日志信息足够详细，开发者需要用下面的接口在代码的关键执行路径上写日志。 [图片] wx.getLogManager 接口的更详细使用请参考文档。 希望通过这些小技巧，可以帮助大家顺畅地开发小程序。

《跳一跳》小游戏在 2017年12月28日正式发布，一周内 DAU 突破一亿，为小游戏开放生态赢得口碑。它操作简单，节奏轻快，凭借着快速复活机制以及强大的社交属性掀起了一股全民潮流。 其实，这个小游戏里仅有两个元素，黑色小人和各色基座。游戏规则也很简单，起跳前，小黑人压缩自己的身体来蓄力，根据蓄力时间决定距离来跳到下一个基座上。 今天的小故事，想要跟大家分享小游戏的渲染能力，我们以跳一跳唱片机为例，简要介绍一下如何展现一个三维物体~ ( 3D渲染引擎选用 Three.js ) [图片] 步骤一 创建一个场景 Scene 游戏的容器，用来放置光源，照相机和唱片机。 let scene = new THREE.Scene() 步骤二 选择合适的照相机 Camera 抽象来说，照相机定义了三维空间到二维屏幕的投影方式。 因投影方式不同，相机又分为透视投影相机和正交投影相机。 透视投影中的四棱柱和正交投影中的立方体被称为视景体，它是三维世界里屏幕上可见的区域，也就是照相机的视野。 视景体外的物体会被剪裁掉不参与渲染。透视投影更接近真实世界，有近大远小的感觉。而正交投影将物体以原比例平行投影到近剪裁面上，不会有大小缩放。 在跳一跳中我们使用了正交投影相机。 [图片] let camera = new THREE.OrthographicCamera( width / - 2, width / 2, height / 2, height / - 2, near, far ) 步骤三 创建光源 light let ambientLight = new THREE.AmbientLight(0xffffff, 0.8); let directionalLight = new THREE.DirectionalLight(0xffffff, 0.28); 创建一个环境光和直射光, 环境光没有特定光源，它将光线均匀照射在场景中。直射光模拟真实世界太阳光。 步骤四 定义几何体 Geometry， 材质 Material，合成 Mesh Geometry 几何体，定义了一个物体的形状，包含顶点，线，面和法向量等信息。 let boxGeometry = new THREE.BoxGeometry(2, 2, 2) 对于唱片机我们创建了三个几何体，两个长方体和一个圆柱体。 [图片] Material 材质，定义了一个物体的外观，例如颜色，透明度，光照属性，融合模式。 顶部透明盖子，底座和唱片的使用的Lambert材质，这种材质只考虑漫反射而不考虑镜面反射, 通常用于创建较暗淡无高光的物体, 其中 texture 是纹理贴图，我们通过纹理映射将这个二维图像贴到三维的方块上。 let transparentMaterial = new THREE.MeshLambertMaterial({ color: ‘white’, transparent: true, opacity: 0.5, map: texture }) 最后我们通过 Mesh 我们将材质应用到几何体上。 let box = new THREE.Mesh(boxGeometry, transparentMaterial) 步骤五 使用渲染器 Renderer 渲染整个场景 最后我们将 box，camera 设置合适的位置后加入到场景中，再使用 Three.js 的渲染器 renderer 之后就可以看到音乐盒了~ renderer.render(scene, camera) 至此，我们完成了一个 3D 场景渲染到 2D 屏幕的渲染流水线中的应用程序阶段，这个阶段我们将渲染所需的几何信息（点，线，面，法线等信息）传递到渲染流水线的后续阶段。后续的小故事我们会介绍调用渲染器 render 方法后 GPU 是如何处理几何信息并最终渲染图像到屏幕上的。 QA&共性问题 Q   一般的 3D 游戏 HUD 层（平视显示器）采用 DOM 来显示，例如排行榜，交互按钮。或者使用另一个 canvas 叠在游戏 canvas 上。但是小游戏只支持一个可见 canvas，并且不支持 DOM。这种情况在小游戏里面，应该如何处理呢？ A   可以封装 HUD 层并将其放在游戏 canvas 中，将整个HUD画在了一张离屏 canvas 中，然后将该 canvas 转化为纹理贴图，再将其贴在游戏的 3D 平面模型上。 后续的小故事会介绍如何将 HUD 分解为 3D 组件的形式来开发。

当前有页面 A，引用了自定义组件 Z ,现在需要在自定义组件 Z 中调用 A 页面中的 B 方法来实现 A 页面的数据刷新。 自定义组件是由开发者自己编写的，能按需求实现相同功能即可。求各位大佬给个解决办法，谢谢！

在A点，通过wx.getLocation获取位置后，移动到另外一个位置B，再次wx.getLocation()，获取到的位置是A附近的位置，用wx.openLocation()打开地图，过一会儿(有时几秒、有时几十秒)后，又直接移到正确位置上去了；相应的getLocatoin的数据也成正确的了 整体感觉：位置移动后，getLocation返回的数据不对，要等一会儿，或者用openLocation打开一次地图再等一会儿，再次调用才返回正确的数据 备注： (1)A点和B点相差3公里以上，开车移动，出现此问题的概率比较大，自己测试了5次，有3次不对，客户反馈错误率90% (2)如果有几十米或一二百米误差，都能接受，现在误差是几公里 (3)静止不动，getLocation可以返回正常的数据，误差几十米到一二百米不等，可以接受 (4)测试手机：小米5s、iPhone7Plus 问下，wx.getLocation()，如何能保证每次获取的都是当前位置的信息？而且是第一次调用时 有小误差可以接受 [代码]wx.getLocation({[代码] [代码]    [代码][代码]type: [代码][代码]'gcj02'[代码][代码], [代码] [代码]    [代码][代码]success: [代码][代码]function[代码] [代码](res) {[代码] [代码]    [代码][代码]    [代码][代码]var[代码] [代码]latitude = res.latitude[代码] [代码]    [代码][代码]    [代码][代码]var[代码] [代码]longitude = res.longitude[代码] [代码]    [代码][代码]    wx.openLocation({[代码] [代码]    [代码][代码]        latitude: latitude,[代码] [代码]    [代码][代码]        longitude: longitude,[代码] [代码]    [代码][代码]        scale: [代码][代码]28[代码] [代码]    [代码][代码]    })[代码] [代码]    [代码][代码]}[代码] [代码]})[代码]

代码片段： wechatide://minicode/ROIdcdmz712p 代码片段中 canvas 绘制开发工具下可一直保持流畅（我运行了 5-6 分钟），同样的代码在 web（微信浏览器）流畅运行。 真机下，大概 10 秒就会降到 30 fps，然后大概1分钟不到就会降到 1-2 fps。 虽说可以通过 canvasToTempFilePath 保存已经绘制的内容再重绘图片来降低卡顿，但是操作起来会很麻烦，而且可能会造成绘制丢失 所以想了解下这是什么问题，有没有更好的解决方法？ 另外有个小疑惑，原生 canvas 为什么比 web 要卡，用原生 canvas 实现有什么意义？ Thanks for your time!

小程序审核突然没通过，理由如下： [图片] 这个问题开发过程中自己确实遇到过，几率性的，一般第一次不行，第二次肯定可以了，但是不是一开始写小程序就有的，不知道什么时候开始就这样了，验证的逻辑都是按照官方的，从来没有改变过。然后上社区一搜，很多类似的问题，如下图所示。 [图片] 看了下这个问题，第一次验证签名如下： [图片] 小程序端通过wx.login成功后获取的code rawdata，这个我都是同一用户登录，前后信息没啥变化 通过1中的code，后端调用api获得的session data，其中openid肯定同一用户每次也都一样的，session_key如果过期，那么第一次和第二次理论应该是不一样的。（但实际情况前后两次是一致的，具体可参见下图） 小程序端获取到的用户的签名 后端通过session key校验出来的签名。 很明显，4和5不一致，校验失败。接下来是第二次交验： [图片] 还是同样的逻辑顺序。 小程序端通过wx.login成功后获取的code。很明显，code跟第一次是不一样的，另外根据官方文档描述，因为又重新调用了wx.login，会导致session_key过期。（这似乎说明code发生变化也是对的，因为按推测，seesionkey应该也发生了变化，否则怎么叫“被更新”）请看下图官方文档说明：[图片] rawdata，这个我都是同一用户登录，前后信息没啥变化 根据1中的官方描述，奇怪的现象就发生了，在后端根据新的code，获取的session data，很明显session key还是第一次是一样的，也就是说，我重新调用了wx.login, code是变了，但是session key却和第一次保持一致的。 小程序端获取到的用户的签名 后端通过session key校验出来的签名。因为用的是同样的rawdata，同样的session key，所以两次校验的结果是一样的，但是第二次4中，小程序端获取的签名是跟此次校验结果是一致的。 所以问题就来了，这问题到底出在什么地方？似乎官方文档描述的就有问题，还是我本身的逻辑顺序有问题？请官方指教，谢谢。

有个项目对接了第三方，小程序跳对方的h5，结果对方页面又需要跳芝麻信用的页面。这个芝麻信用我总不能配业务域名呀，灵机一动，尝试了用iframe内嵌第三方业务域名，希望可以正常跳转，结果用真机测试了一下还真行了！！！，这个兴奋啊，这不快上线了，发现居然是安卓可以，ios不行，这真是五雷轰顶啊！！！！这算是bug吗，我该怎么办？微信什么时候能把业务域名这个鬼解决一下？？

求官方给解答，我们的小程序被现象级的抄袭，除了功能一样以外，整个UI设计交互及日签设计的板式都是一模一样。 前端是这样子的： [图片] [图片] 后台代码是这样子的： [图片] * 这份代码由2018年9月3日鲜炖日记微信小程序反编译而来，大家可以从现有版本进行反编译验证。 * 从反编辑的代码中可以看出，鲜炖日记完全使用了燕窝大学的代码及设计师设计的图片。 * 错误的拼写，同样的按钮配置，相似度100% 本次仅取部分代码作为截图证据，如果需要可以公开更多内容，希望官方能够帮忙处理这件事