*碎碎念 咱们说说蓝牙模块的一些常见的问题，大部分文档能找到的。有些文档有标注！但是发现有部分开发者没出坑，我会在下文提出！！！ 1.部分机型蓝牙模块需要开启定位 蓝牙和定位有啥关系？ 不知道，非要一个答案就是和系统有关！ (再问就自闭了orz....) 2.蓝牙不支持直连 如果你不通过接口搜索到蓝牙，从而直接去连接的话，你会发现 wx.getBluetoothDevices 获取不到已经连接的设备。不过在你搜索过之后你就可以直接连接了！！ 3.蓝牙连接失败 在调用蓝牙连接的时候，我们通常碰到蓝牙给我们返回 10003 / 10012 错误，通常是系统吐出来的（通常而不是所有的）。我们需要重新去连接，所以我们把蓝牙连接放进一个循环里面！！如: async createBLEConnection(deviceID) { [代码] // 进行连接蓝牙 let count = 8 let ress = null while (count > 0) { count -= 1 let err, res [err, res] = await to(wepy.createBLEConnection({ discoverServiceType: 1, deviceId: deviceID, timeout: 3 * 1000 })) ress = res if ((res && res.errCode === 0) || (err && err.errCode === -1)) { this.connet = 0 return true } await this.closeBLEConnection() if (!this.ble.opened) { tip.alert('蓝牙未开启！') this.connet = 0 return } // 间隔2秒后 再次获取 await Time.sleep(2) tip.loading('蓝牙连接中...') this.connet = 0 } if (ress && ress.errMsg.indexOf('createBLEConnection:ok') >= 0) { this.connet = 0 return true } tip.loaded() return false } [代码] 以上是我用wepy框架写的！不建议直接复制 4.搜索成功后记得关闭蓝牙搜索 在通过startBluetoothDevicesDiscovery搜索成功之后记得调用 wx.stopBluetoothDevicesDiscovery 关闭搜索，如果不关闭手机性能差的会无比卡！对。。。 5. Android 上获取到的deviceId为设备 MAC 地址，iOS 是设备 uuid 哈哈！所以你需要搜索到设备的name或者localname去连接 ，localname有的手机是没有的！ *补充一些 想了想！干脆把文档里面一些已经提出还会有人提的问题也 碎叨一下 1.蓝牙需要成对调用 以下接口需要成对调用 createBLEConnection 和 closeBLEConnection startBluetoothDevicesDiscovery 与 stopBluetoothDevicesDiscovery 在关闭蓝牙的时候 closeBLEConnection 和 stopBluetoothDevicesDiscovery 2.小程序只支持低功耗蓝牙 哈哈低功耗蓝牙是啥？？百度吧！！ *最后 以上就是蓝牙常见的一些问题，多看文档是可以解决很多小坑，深坑的话就来社区发帖吧！咱们下篇文章见

手机戳这里： 分享一个图片拖拽排序组件 电脑直接看下边吧

开发文档：https://mp.weixin.qq.com/wxopen/plugindevdoc?appid=wx069ba97219f66d99&token=61191740&lang=zh_CN 插件功能 语音转文字 语音合成 文本翻译 具体使用案例可以查看面对面翻译小程序开源项目：  https://github.com/Tencent/Face2FaceTranslator                   简单DEMO实现： step 1：添加插件 在使用前，需要登录官网 设置 → 第三方服务 → 添加插件 搜索 【微信同声传译】并添加 [图片] 在需要使用插件的小程序 app.json 中指明需要使用的插件版本等信息 [代码]// app.json {  ...  "plugins": {    ...    "WechatSI": {      "version": "0.0.6",      "provider": "wx069ba97219f66d99"  } }[代码] 接下来，在index.js引入插件，获取全局唯一的语音识别管理器recordRecoManager [代码]// index.js const plugin = requirePlugin("WechatSI") const manager = plugin.getRecordRecognitionManager() [代码] step 2：语音输入 希望做到的效果是按住某个按钮，开始识别语音，松开按钮就结束识别 [代码][代码][代码]<view  catchtouchstart="streamRecord" catchtouchend="endStreamRecord">中文view> [代码] [代码]// index.js Page({  data: {},  streamRecord: function() {    manager.start({      lang: 'zh_CN',    })  },  streamRecordEnd: function() {    manager.stop()  } }) [代码] step 3：绑定录音回调事件 [代码][代码][代码] <view>语音识别内容：{{currentText}}view> [代码] [代码]// page.js Page({  data: {    currentText: '',  },  initRecord: function() {    //有新的识别内容返回，则会调用此事件    manager.onRecognize = (res) => {      let text = res.result      this.setData({        currentText: text,      })    }    // 识别结束事件    manager.onStop = (res) => {      let text = res.result      if(text == '') {        // 用户没有说话，可以做一下提示处理...        return      }      this.setData({        currentText: text,      })      // 得到完整识别内容就可以去翻译了      this.translateTextAction()    }  },  translateTextAction: function() {},  onLoad: function() {    this.initRecord()  } }) [代码] step 4：文本翻译 [代码][代码][代码]<view>翻译结果：{{translateText}}view> [代码] [代码]// page.js Page({  data: {    currentText: '',    translateText: '',  },  translateTextAction: function() {    let lfrom =  'zh_CN'    let lto = 'en_US'    plugin.translate({      lfrom: lfrom,      lto: lto,      content: this.data.currentText,      tts: true, // 需要合成语音      success: (resTrans)=>{        // 翻译可以得到 翻译文本，翻译文本的合成语音，合成语音的过期时间        let text = resTrans.result        this.setData({          translateText: text,        })        // 得到合成语音让它自动播放出来        wx.playBackgroundAudio({          dataUrl: resTrans.filename,          title: '',        })      },    })  }, }) [代码] step 5：语音合成 plugin.translate得到的语音文件是有过期时间，可以download到本地使用。 如果像面对面翻译一样需要存比较多历史记录的话，也可以选择过期之后调用plugin.textToSpeech接口再去重新合成一次。 [代码]  plugin.textToSpeech({    lang: 'zh_CN',    content: '我想重新进行语音合成',    success: resTrans => {      // 可以重新得到语音合成文件和过期时间    }, }) [代码]

自己封装了一个 custom 模式下的导航组件，欢迎 star

小程序刻度尺组件

小程序即时通讯模板，目前已提供WebSocket通信功能示例。 [图片]

效果图如下： [图片]

       研发同学在端内既追求h5的灵活性，也要追求性能趋近于原生。 面对入口扩张，主端、独立端、微信小程序、支付宝小程序、百度小程序、Android厂商联盟快应用，单一功能在各平台都要重复实现，开发和维护成本成倍增加。迫切需要维护一套代码可以构建多入口的解决方案，历经近20个月打磨，滴滴跨端解决方案Chameleon终于发布。真正专注于让一套代码运行多端。 项目官网：https://cmljs.org 快速上手简易教程：https://cmljs.org/doc/example/main.html 项目介绍文章：https://mp.weixin.qq.com/s/cnglsbGuE81ovL10Sy47nA

写在前面的话 大家看到这个文章时一定会感觉这是在炒剩饭，社区中已经有那么多分享自定义导航适配的文章了，为什么我还要再写一个呢？ 主要原因就是，社区中大部分的适配方案中给出的大小是不精确的，并不能完美适配各种场景。 社区中大部分文章给到的值是 iOS -> 44px , Android -> 48px 思路 正常来讲，iOS和Android下的胶囊按钮的位置以及大小都是相同且不变的，我们可以通过胶囊按钮的位置和大小再配合 wx.getSystemInfo 或者 wx.getSystemInfoSync 中得到的 [代码]statusBarHeight[代码] 来计算出导航栏的位置和大小。 小程序提供了一个获取菜单按钮（右上角胶囊按钮）的布局位置信息的API，可以通过这个API获取到胶囊按钮的位置信息，但是经过实际测试，这个接口目前存在BUG，得到的值经常是错误的（通过特殊手段可以偶尔拿到正确的值），这个接口目前是无法使用的，等待官方修复吧。 下面是我经过实际测试得到的准确数据： 真机和开发者工具模拟器上的胶囊按钮不一样 [代码]# iOS top 4px right 7px width 87px height 32px # Android top 8px right 10px width 95px height 32px # 开发者工具模拟器（iOS） top 6px right 10px width 87px height 32px # 开发者工具模拟器（Android） top 8px right 10px width 87px height 32px [代码] [代码]top[代码] 的值是从 [代码]statusBarHeight[代码] 作为原点开始计算的。 使用上面数据中胶囊按钮的高度加 [代码]top[代码] * 2 上再加上 [代码]statusBarHeight[代码] 的高度就可以得到整个导航栏的高度了。 为什么 [代码]top[代码] * 2 ？因为胶囊按钮是垂直居中在 title 那一栏中的，上下都要有边距。 扩展 通过胶囊按钮的 [代码]right[代码] 可以准确的算出自定义导航的 [代码]左边距[代码]。 通过胶囊按钮的 [代码]right[代码] + [代码]width[代码] 可以准确的算出自定义导航的 [代码]右边距[代码] 。 通过 wx.getSystemInfo 或者 wx.getSystemInfoSync 中得到的 [代码]windowWidth[代码] - 胶囊按钮的 [代码]right[代码] + [代码]width[代码] 可以准确的算出自定义导航的 [代码]width[代码] 。 再扩展 wx.getSystemInfo 或者 wx.getSystemInfoSync 中得到的 [代码]statusBarHeight[代码] 每个机型都不一样，刘海屏得到的数据也是准确的。 如果是自定义整个页面，iPhone X系列的刘海屏，底部要留 [代码]68px[代码] ，不要问我为什么！ 代码片段 https://developers.weixin.qq.com/s/Q79g6kmo7w5J

为什么要做性能优化？ 一切性能优化都是为了体验优化 1. 使用小程序时，是否会经常遇到如下问题？ 打开是一直白屏 打开是loading态，转好几圈 我的页面点了怎么跳转这么慢？ 我的列表怎么越滑越卡？ 2. 我们优化的方向有哪些？ 启动加载性能 渲染性能 3. 启动加载性能 1. 首次加载 你是否见过小程序首次加载时是这样的图？ [图片] 这张图中的三种状态对应的都是什么呢？ 小程序启动时，微信会为小程序展示一个固定的启动界面，界面内包含小程序的图标、名称和加载提示图标。此时，微信会在背后完成几项工作：[代码]下载小程序代码包[代码]、[代码]加载小程序代码包[代码]、[代码]初始化小程序首页[代码]。下载到的小程序代码包不是小程序的源代码，而是编译、压缩、打包之后的代码包。 2. 加载顺序 小程序加载的顺序是如何？ 微信会在小程序启动前为小程序准备好通用的运行环境。这个运行环境包括几个供小程序使用的线程，并在其中完成小程序基础库的初始化，预先执行通用逻辑，尽可能做好小程序的启动准备。这样可以显著减少小程序的启动时间。 [图片] 通过2，我们知道了，问题1中第一张图是[代码]资源准备[代码]（代码包下载）；第二张图是[代码]业务代码的注入以及落地页首次渲染[代码]；第三张图是[代码]落地页数据请求时的loading态[代码]（部分小程序存在） 3. 控制包大小 提升体验最直接的方法是控制小程序包的大小，这是最显而易见的 勾选开发者工具中“上传代码时，压缩代码”选项； 及时清理无用的代码和资源文件（包括无用的日志代码） 减少资源包中的图片等资源的数量和大小（理论上除了小icon，其他图片资源从网络下载），图片资源压缩率有限 从开发者的角度看，控制代码包大小有助于减少小程序的启动时间。对低于1MB的代码包，其下载时间可以控制在929ms（iOS）、1500ms（Android）内。 4. 采用分包加载机制 根据业务场景，将用户访问率高的页面放在主包里，将访问率低的页面放入子包里，按需加载； [图片] 使用分包时需要注意代码和资源文件目录的划分。启动时需要访问的页面及其依赖的资源文件应放在主包中。 5 采用分包预加载技术 在4的基础上，当用户点击到子包的目录时，还是有一个代码包下载的过程，这会感觉到明显的卡顿，所以子包也不建议拆的太大，当然我们可以采用子包预加载技术，并不需要等到用户点击到子包页面后在下载子包，而是可以根据后期数据，做子包预加载，将用户在当先页可能点击的子包页面先加载，当用户点击后直接跳转； [图片] 这种基于配置的子包预加载技术，是可以根据用户网络类型来判断的，当用户处于网络条件好时才预加载；是灵活可控的 6. 采用独立分包技术 目前很多小程序[代码]主包+子包[代码]（2M+6M）的方式，但是在做很多运营活动时，我们会发现活动（红包）是在子包里，但是运营、产品投放的落地页链接是子包链接，这是的用户在直达落地时，必须先下载主包内容（一般比较大），在下载子包内容（相对主包，较小），这使得在用户停留时间比较短的小程序场景中，用户体验不是很好，而且浪费了很大部分流量； [图片] 可以采用独立分包技术，区别于子包，和主包之间是无关的，在功能比较独立的子包里，使用户只需下载分包资源； 7. 首屏加载的优化建议 7.1 提前请求 异步请求可以在页面onLoad就加载，不需要等页面ready后在异步请求数据；当然，如果能在前置页面点击跳转时预请求当前页的核心异步请求，效果会更好； 7.2 利用缓存 利用storage API, 对变动频率比较低的异步数据进行缓存，二次启动时，先利用缓存数据进行初始化渲染，然后后台进行异步数据的更新，这不仅优化了性能，在无网环境下，用户也能很顺畅的使用到关键服务； 7.3 避免白屏 可以在前置页面将一些有用的字段带到当前页，进行首次渲染（列表页的某些数据–> 详情页），没有数据的模块可以进行骨架屏的占位，使用户不会等待的很焦虑，甚至走了； 7.4 及时反馈 及时的对需要用户等待的交互操作进行反馈，避免用户以为小程序卡了，无响应 渲染性能优化 1. 小程序渲染原理 双线程下的界面渲染，小程序的逻辑层和渲染层是分开的两个线程。在渲染层，宿主环境会把WXML转化成对应的JS对象，在逻辑层发生数据变更的时候，我们需要通过宿主环境提供的setData方法把数据从逻辑层传递到渲染层，再经过对比前后差异，把差异应用在原来的Dom树上，渲染出正确的UI界面。 [图片] 分析这个流程不难得知：页面初始化的时间大致由页面初始数据通信时间和初始渲染时间两部分构成。其中，数据通信的时间指数据从逻辑层开始组织数据到视图层完全接收完毕的时间，数据量小于64KB时总时长可以控制在30ms内。传输时间与数据量大体上呈现正相关关系，传输过大的数据将使这一时间显著增加。因而减少传输数据量是降低数据传输时间的有效方式。 [图片] 2. 避免使用不当setData 在数据传输时，逻辑层会执行一次[代码]JSON.stringify[代码]来去除掉[代码]setData[代码]数据中不可传输的部分，之后将数据发送给视图层。同时，逻辑层还会将[代码]setData[代码]所设置的数据字段与[代码]data[代码]合并，使开发者可以用[代码]this.data[代码]读取到变更后的数据。因此，为了提升数据更新的性能，开发者在执行[代码]setData[代码]调用时，最好遵循以下原则： 2.1 不要过于频繁调用setData，应考虑将多次setData合并成一次setData调用； [图片] 2.2 数据通信的性能与数据量正相关，因而如果有一些数据字段不在界面中展示且数据结构比较复杂或包含长字符串，则不应使用[代码]setData[代码]来设置这些数据； [图片] 2.3 与界面渲染无关的数据最好不要设置在data中，可以考虑设置在page对象的其他字段下 [图片] 提升数据更新性能方式的代码示例 [代码]Page({ onShow: function() { // 不要频繁调用setData this.setData({ a: 1 }) this.setData({ b: 2 }) // 绝大多数时候可优化为 this.setData({ a: 1, b: 2 }) // 不要设置不在界面渲染时使用的数据，并将界面无关的数据放在data外 this.setData({ myData: { a: '这个字符串在WXML中用到了', b: '这个字符串未在WXML中用到，而且它很长…………………………' } }) // 可以优化为 this.setData({ 'myData.a': '这个字符串在WXML中用到了' }) this._myData = { b: '这个字符串未在WXML中用到，而且它很长…………………………' } } }) [代码] 利用setData进行列表局部刷新 在一个列表中，有[代码]n[代码]条数据，采用上拉加载更多的方式，假如这个时候想对其中某一个数据进行点赞操作，还能及时看到点赞的效果 解决方法 1、可以采用setData全局刷新，点赞完成之后，重新获取数据，再次进行全局重新渲染，这样做的优点是：方便，快捷！缺点是：用户体验极其不好，当用户刷量100多条数据后，重新渲染量大会出现空白期（没有渲染过来） 2、说到重点了，就是利用[代码]setData[代码]局部刷新 [代码]> a.将点赞的`id`传过去，知道点的是那一条数据, 将点赞的`id`传过去，知道点的是那一条数据 [代码] [代码]<view wx:if="{{!item.status}}" class="btn" data-id="{{index}}" bindtap="couponTap">立即领取</view> [代码] [代码]> b.重新获取数据，查找相对应id的那条数据的下标（`index`是不会改变的） > c.用setData进行局部刷新 [代码] [代码]this.setData({ list[index] = newList[index] }) [代码] 其实这个小操作对刚刚接触到微信小程序的人来说应该是不容易发现的，不理解setData还有这样的写法。 2.4 切勿在后台页面进行setData 在一些页面会进行一些操作，而到页面跳转后，代码逻辑还在执行，此时多个[代码]webview[代码]是共享一个js进程；后台的[代码]setData[代码]操作会抢占前台页面的渲染资源； [图片] [图片] 3. 用户事件使用不当 视图层将事件反馈给逻辑层时，同样需要一个通信过程，通信的方向是从视图层到逻辑层。因为这个通信过程是异步的，会产生一定的延迟，延迟时间同样与传输的数据量正相关，数据量小于64KB时在30ms内。降低延迟时间的方法主要有两个。 1.去掉不必要的事件绑定（WXML中的[代码]bind[代码]和[代码]catch[代码]），从而减少通信的数据量和次数； 2.事件绑定时需要传输[代码]target[代码]和[代码]currentTarget[代码]的[代码]dataset[代码]，因而不要在节点的[代码]data[代码]前缀属性中放置过大的数据。 [图片] 4. 视图层渲染原理 4.1首次渲染 初始渲染发生在页面刚刚创建时。初始渲染时，将初始数据套用在对应的WXML片段上生成节点树。节点树也就是在开发者工具WXML面板中看到的页面树结构，它包含页面内所有组件节点的名称、属性值和事件回调函数等信息。最后根据节点树包含的各个节点，在界面上依次创建出各个组件。 [图片] 在这整个流程中，时间开销大体上与节点树中节点的总量成正比例关系。因而减少WXML中节点的数量可以有效降低初始渲染和重渲染的时间开销，提升渲染性能。 简化WXML代码的例子 [代码]<view data-my-data="{{myData}}"> <!-- 这个 view 和下一行的 view 可以合并 --> <view class="my-class" data-my-data="{{myData}}" bindtap="onTap"> <text> <!-- 这个 text 通常是没必要的 --> {{myText}} </text> </view> </view> <!-- 可以简化为 --> <view class="my-class" data-my-data="{{myData}}" bindtap="onTap"> {{myText}} </view> [代码] 4.2 重渲染 初始渲染完毕后，视图层可以多次应用[代码]setData[代码]的数据。每次应用[代码]setData[代码]数据时，都会执行重渲染来更新界面。初始渲染中得到的data和当前节点树会保留下来用于重渲染。每次重渲染时，将[代码]data[代码]和[代码]setData[代码]数据套用在WXML片段上，得到一个新节点树。然后将新节点树与当前节点树进行比较，这样可以得到哪些节点的哪些属性需要更新、哪些节点需要添加或移除。最后，将[代码]setData[代码]数据合并到[代码]data[代码]中，并用新节点树替换旧节点树，用于下一次重渲染。 [图片] 在进行当前节点树与新节点树的比较时，会着重比较[代码]setData[代码]数据影响到的节点属性。因而，去掉不必要设置的数据、减少[代码]setData[代码]的数据量也有助于提升这一个步骤的性能。 5. 使用自定义组件 自定义组件的更新只在组件内部进行，不受页面其他不能分内容的影响；比如一些运营活动的定时模块可以单独抽出来，做成一个定时组件，定时组件的更新并不会影响页面上其他元素的更新；各个组件也将具有各自独立的逻辑空间。每个组件都分别拥有自己的独立的数据、setData调用。 [图片] 6. 避免不当的使用onPageScroll 每一次事件监听都是一次视图到逻辑的通信过程，所以只在必要的时候监听pageSrcoll [图片] 总结 小程序启动加载性能 控制代码包的大小 分包加载 首屏体验（预请求，利用缓存，避免白屏，及时反馈 小程序渲染性能 避免不当的使用setData 合理利用事件通信 避免不当的使用onPageScroll 优化视图节点 使用自定义组件

2018年12月，腾讯相册累计用户量突破[代码]1亿[代码]，月活1200万，阿拉丁指数排行 [代码]Top 30[代码]，已经成为小程序生态的重量级玩家。 三个多月来，腾讯相册围绕【在微信分享相册照片】这一核心场景，快速优化和新增一系列社交化功能，配合适当的运营，实现累计用户量突破[代码]1亿[代码]，大大超过预期。 [图片] (腾讯相册用户量破亿) 可是，谁曾想到，这样一个亿级体量的小程序，竟然是一个开发做出来的？他又是有哪般“绝技”，可以一个人撑起一个用户过亿的小程序？ 后台人力紧缺，怎么办？ 当我第一次见到腾讯相册小程序的开发David（化名）时，他显得忧心忡忡。 “年底的目标是要过千万的用户，但现在只有几位前端和后台开发。不仅如此，我们的后台开发还不是百分百能够投入到这个项目，大部分时间要抽身支援其它项目，人力非常紧缺。此外，原有后台系统有不少历史包袱，在原有架构上做新的社交化功能开发是不现实的。怎么办？ “要不试试’小程序·云开发’吧，只需要前端就可以把小程序搞起，正好解决我们缺后台的难题。” 于是，David作为腾讯相册前端开发团队的骨干，担当起用小程序·云开发实现腾讯相册小程序社交化功能的重任。 “第一次接触到’小程序·云开发‘时，觉得这个东西（小程序·云开发）理念挺新颖的———小程序无服务开发模式。在一般的小程序开发中，有三大功能小程序开无法绕开后台的帮助，它门分别是数据读取、文件管理以及敏感逻辑的处理（如权限）。因此，传统的开发模式，在小程序端都必须发送请求到后台进行鉴权，并且处理相关的文件或者数据。即使使用 Node 来搭建后端服务，也需要耗费不少的搭基础架构、后期运维的工作量。” [图片] “而小程序·云开发则释放了小程序开发者的手脚，赋予了开发者安全、稳定读取数据、上传文件和控制权限的能力，其它的负载、容灾、监控等，我们小程序开发者只需要关注业务逻辑，专注写好业务逻辑即可，其他的事情完全可以不用操心了！本来我还一筹莫展，了解完’小程序·云开发‘的产品原理以后，我瞬间心里有谱了。” 二维码扫不出来了 [图片] 道路总是不平坦的 ，在腾讯相册小程序通往用户破亿的道路上，困难重重。 由于腾讯相册的二维码需要带上的信息量过大，因此它的二维码显得密密麻麻。这种密集的二维码在某些Android机型下，容易出现无法识别小程序的问题。 这严重制约了腾讯相册小程序分享获客的能力。 [图片] (需要存储name, ownerid, page等大量信息) 这个事情的解决并不难，只需后台开发把数据先存储到数据库中，然后把数据id放到分享链接上，这样，链接便可以转化成32个字符的短链接，让二维码看起来没有那么密集了。 但由于后台人力不足，于是前端开发David利用小程序· 云开发的数据库存储能力，通过调用db.collection(‘qr’).add接口，快速实现数据在数据库中的存储。 [图片] (云开发数据库，格式类似MongoDB) [图片] (云开发数据库索引，可加快数据读取) [图片] 此外，腾讯相册还借住小程序·云开发的云函数能力，生成辨识度更高的小程序码（小程序码文档），用以在朋友圈里传播分享。 [图片] (生成小程序码的云函数逻辑) [图片] (优化后的分享图片和小程序码) 2天上线评论点赞功能 [图片] (评论与点赞功能) 腾讯相册在微信端的核心应用场景是“在微信做分享相册照片”，为了增强腾讯相册用户在微信里的互动，提升用户粘性和留存，腾讯相册决定新增评论与点赞功能，并且把聊天评论就直接在微信聊天窗口里面实现。 在这里，腾讯相册的David面临了两个选择，一是按原开发模式（前台开发-后台开发-前后台联调）做这个功能，面临的问题便是开发周期长、缺后台、迭代速度慢；另一个就是借助云开发的能力，亲自上阵。 为了加快产品迭代速度，David决定采取云开发的开发方式。评论、点赞通过云开发的数据库插入和查询接口，如db.collection(‘comment’).add，很快就实现了。 但遇到棘手的问题是，对于一些敏感的操作比如删除和编辑评论、点赞这些敏感操作，还需要到用户的鉴权操作，而这些鉴权信息，都在原有的后台。此时，云函数的路由功能便发挥出作用了。 [图片] (评论点赞逻辑) 用户进行评论点赞的时候，会在小程序端发起请求调用云函数并带上 [代码]openid[代码]，云函数用 [代码]openid[代码] 查询原有的后台服务看看该用户是否有权限进行操作，如果用户具有权限，则把评论和点赞的数据都写入云开发的数据库中。 就这样，借住小程序·云开发的能力，腾讯相册仅用2天时间，完成了在传统开发模式下需要1周多工作量的开发工作。 ​ 原有开发模式 云开发全栈开发 工作量 后台1周(微信登录态校验+业务逻辑server开发)+ 前后台联调1天 1 - 2天，无需联调 什么是小程序·云开发？ 小程序·云开发是基于腾讯云研发的全新 云开发 Tencent Cloud Base（简称 TCB） 服务，腾讯云与微信力推的这套云开发服务的诞生，恰逢其时地帮助腾讯相册走出开发效率的瓶颈。 [图片] (基于腾讯云的云开发) 小程序云目前提供三大基础能力支持： 云函数：充当了后台的角色，开发者可以在上面用 Node （后续还会支持 PHP, Python 等）写后台逻辑，跟微信私有协议天然鉴权，可以云函数里直接获取 [代码]appid[代码], [代码]openid[代码], [代码]unionid[代码] 等重要鉴权信息，大大简化了小程序后台的开发工作量。 数据库：一个既可在小程序前端操作，也能在云函数中读写的文档型数据库，提供控制台可视化管理 文件存储：在小程序前端和云函数里都可以直接上传/下载云端文件，提供控制台可视化管理 如果你是全新开发的小程序，架构非常轻量简单，如下图。 [图片] 如果你是已有的小程序，部份需要跟原有后台交互的功能，完全可把云函数作为路由，节省获取openid 等用户信息的逻辑，如下图： [图片] 相关资料 小程序·云开发解决方案 小程序·云开发文档