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

我们在开发小程序时，一个列表里难免会有很多条数据，比如我们一个列表有1000条数据，我们一下加载出来，而不做分页，将会严重影响性能。所以这一节，我们来讲讲小程序分页加载数据的实现。 老规矩，先看效果图 [图片] 可以看到我们每页显示10条数据，当滑动到底部时，会加载第二页的数据，再往下滑动，就加载第三页的数据。由于我们一共21条数据，所以第三页加载完以后，会有一个“已加载全部数据”的提示。 本节知识点 1，小程序分页加载 2，小程序列表显示 3，云数据库的使用 4，云数据库分页请求数据的实现 一，先定义数据 我们做分页数据加载，肯定要先准备好数据，数据已经给大家准备好，如下图，文章末尾会贴出数据源和本节课源码的下载地址。 [图片] 然后把数据导入到我们的云开发的数据库里，关于数据如何导入，这里不再讲解，不知道的同学，请看下面这篇文章。或者去老师历史文章里找一下。 《小程序云开发入门—云数据库数据源的导入与导出》 下面给大家看下我们的数据源，长什么样。其实很简单，就是简单的定义21条数据。 [图片] 然后在看导入到数据库的样子。 [图片] 二，分页请求数据 我们第一步准备好了数据以后，接下来就来讲讲如何在js里做分页加载数据。 首先我们这里用到了小程序云开发数据库的知识点 1，get方法：获取云数据库数据 2，skip方法：跳过前面几条数据，请求后面的数据 3，limit方法：请求多少条数据。 比如下面这段代码,就是跳过前5条，请求从第6条开始往后的10条数据，就是请求6～15的数据，我们做分页加载也就是基于这个原理。 [代码] wx.cloud.database().collection("list") .skip(5) //从第几个数据开始 .limit(10) [代码] 下面把我们index.js的完整代码贴给大家。 [代码]//老师微信：2501902696 let currentPage = 0 // 当前第几页,0代表第一页 let pageSize = 10 //每页显示多少数据 Page({ data: { dataList: [], //放置返回数据的数组 loadMore: false, //"上拉加载"的变量，默认false，隐藏 loadAll: false //“没有数据”的变量，默认false，隐藏 }, //页面显示的事件 onShow() { this.getData() }, //页面上拉触底事件的处理函数 onReachBottom: function() { console.log("上拉触底事件") let that = this if (!that.data.loadMore) { that.setData({ loadMore: true, //加载中 loadAll: false //是否加载完所有数据 }); //加载更多，这里做下延时加载 setTimeout(function() { that.getData() }, 2000) } }, //访问网络,请求数据 getData() { let that = this; //第一次加载数据 if (currentPage == 1) { this.setData({ loadMore: true, //把"上拉加载"的变量设为true，显示 loadAll: false //把“没有数据”设为false，隐藏 }) } //云数据的请求 wx.cloud.database().collection("list") .skip(currentPage * pageSize) //从第几个数据开始 .limit(pageSize) .get({ success(res) { if (res.data && res.data.length > 0) { console.log("请求成功", res.data) currentPage++ //把新请求到的数据添加到dataList里 let list = that.data.dataList.concat(res.data) that.setData({ dataList: list, //获取数据数组 loadMore: false //把"上拉加载"的变量设为false，显示 }); if (res.data.length < pageSize) { that.setData({ loadMore: false, //隐藏加载中。。 loadAll: true //所有数据都加载完了 }); } } else { that.setData({ loadAll: true, //把“没有数据”设为true，显示 loadMore: false //把"上拉加载"的变量设为false，隐藏 }); } }, fail(res) { console.log("请求失败", res) that.setData({ loadAll: false, loadMore: false }); } }) }, }) [代码] 上面的代码就是我们实现分页加载的所有逻辑代码。简单说下代码 1，我们首先进页面时会请求前10条内容 2，10条内容请求成功以后，我们会把请求到的内容加入dataList数组，然后把dataList里的数据显示到页面上。并将currentPage加一，用于请求第二页数据。 3，当用户滑动到底部时，会触发onReachBottom事件，在这个事件里做第二页到请求。然后第二页数据请求成功以后。继续将currentPage加1，这里要记住一定，一定要请求成功以后才将currentPage +1。 三，列表布局和样式 其实index.wxml和index.wxss的代码很简单，给大家把代码贴出来。 1，index.wxml [代码]<scroll-view scroll-y="true" bindscrolltolower="searchScrollLower"> <view class="result-item" wx:for="{{dataList}}" wx:key="item"> <text class="title">{{item.content}}</text> </view> <view class="loading" hidden="{{!loadMore}}">正在载入更多...</view> <view class="loading" hidden="{{!loadAll}}">已加载全部</view> </scroll-view> [代码] 2,index.wxss [代码]page { display: flex; flex-direction: column; height: 100%; } .result-item { display: flex; flex-direction: column; padding: 20rpx 0 20rpx 110rpx; overflow: hidden; border-bottom: 2rpx solid #e5e5e5; } .title { height: 110rpx; } .loading { position: relative; bottom: 5rpx; padding: 10rpx; text-align: center; } [代码] 到这里我们就完整的实现里分页加载功能了。 [图片] 源码和数据源，已经给大家放到网盘里了，有需要的同学请在文章底部留言，或者私信老师。 视频讲解：https://edu.csdn.net/course/detail/9604

​ 前言 我们都知道，JS是单线程执行的，天生异步。在开发的过程中会遇到很多异步的场景，只用回调来处理简单的异步逻辑，当然是可以，但是逻辑逐渐复杂起来，回调的处理方式显得力不从心。 接下来会介绍js中处理异步的方式，通过对比了解各自的原理以及优缺点，帮助我们更好的使用这些强大的异步处理方式。 回调 基本用法 回调函数作为参数传进方法中，在合适的时机被调用。 比如调用ajax，或是使用定时器： [代码] // ajax请求 $.ajax({ url: '/ajax/hdportal_h.jsp?cmd=xxx', error: function(err) { console.log(err) }, success: function(data) { console.log(data) } }) // 定时器的回调 setTimeout(function callback() { console.log('hi') }, 1000) [代码] 回调的问题 1. 回调地狱 过深的嵌套，形成回调地狱 使得代码难以阅读和调试 层层嵌套，代码间耦合严重，牵一发而动全身 2.信任缺失，错误处理无法保证 控制反转，回调函数的调用是在请求函数内部，无法保证回调函数一定会被正确调用，回调本身没有错误处理机制，需要额外设计。 可能存在以下问题： 调用回调过早 调用回调过晚 调用回调次数太多或者太少 未能把所需的参数成功传给你的回调函数 吞掉可能出现的错误或异常 Promise 基本用法 Promise对象的状态不受外界影响。Promise对象代表一个异步操作，有三种状态：pending（进行中）、fulfilled（已成功）和rejected（已失败） 一旦状态改变，就不会再变，任何时候都可以得到这个结果。Promise对象的状态改变，只有两种可能：从pending变为fulfilled和从pending变为rejected。 [代码] new Promise((resovle, reject) => { setTimeout(() => { resovle('hello promise') }, 1000) }).then(res => { console.log(res) }).catch(err => { console.log(err) }) [代码] Promise与回调的区别 Promise 不是对回调的替代。 Promise 在回调代码和将要执行这个任务的异步代码之间提供了一种可靠的中间机制来管理回调 Promise 并没有完全摆脱回调。它们只是改变了传递回调的位置。我们并不是把回调传递给处理函数，而是从处理函数得到Promise，然后把回调传给这个Promise Promise 保证了行为的一致性，使其变得可信任，我们传递的回调会被正确的执行 Promise如何解决信任缺失问题？ 调用时机上，不会调用过早，也不会调用过晚 根据PromiseA+规范，then中的回调会在 then 方法被调用的那一轮事件循环之后的新执行栈中执行。 这个事件队列可以采用“宏任务（macro-task）”机制或者“微任务（micro-task）”机制来实现。 所以提供给then的回调也总会在JavaScript事件队列的当前运行完成后，再被调用，即异步调用。 [代码] var p = Promise.resolve('p'); console.log('A'); p.then(function () { p.then(function () { console.log('E'); }); console.log('C'); }) .then(function () { console.log('D'); }); console.log('B'); [代码] 运行这段代码，会依次打印出ABCED 这里要注意两个点： 会先执行同步代码，再执行then中的代码 then执行回调时，打印D的代码晚于打印E的代码 调用次数上，不会出现回调未调用，也不会出现调用次数太多或者太少 一个Promise注册了一个成功回调和拒绝回调，那么Promise在决议的时候总会调用其中一个。 即使是在决议后调用then注册的回调函数，也会被正确调用，所以不会出现回调未调用的情况。 Promise只能被决议一次。如果处于多种原因，Promise创建代码试图调用多次resolve(…)或reject(…)，或者试图两者都调用，那么这个Promise将只会接受第一次决议，忽略任何后续调用，所以调用次数不会太多也不会太少。 错误处理上，不会吞掉可能出现的错误或异常 如果在Promise的创建过程中或在查看其决议结果的过程中的任何时间点上，出现了一个JavaScript异常错误，比如一个TypeError或ReferenceError，这个异常都会被捕捉，并且会使这个Promise被拒绝。 [代码] var p = new Promise(function (resolve, reject) { foo.bar(); // foo未定义 resolve(2); }); p.then(function (data) { console.log(data); // 永远也不会到达这里 }, function (err) { console.log('出错了', err); // err将会是一个TypeError异常对象来自foo.bar()这一行 }); [代码] Promise中的then then方法的设计是promise中最重要的部分之一，可以看promise/A+规范中对then方法的描述 then方法会返回一个新的promise，因此可以链式调用，下面的代码会打印出6 [代码] var p = Promise.resolve(0); p.then(function (data) { return 1; }).then(function (data) { return data + 2; }).then(function (data) { return data + 3; }).then(function (data) { console.log(data); }); [代码] 如果在then中主动返回一个promise，依旧会返回一个新的promise，只是这个promise的状态“跟随”主动返回的pormise [代码] var p1 = new Promise(function (resolve, reject) { resolve('p1'); }); var p2 = new Promise(function (resolve, reject) { resolve('p2'); }); var p3 = p2.then(function (data) { return p1; }); console.log(p3 === p1); // false p3.then(function (data) { console.log(data); // p1 }); [代码] 静态方法 Promise.resolve() Promise.resolve(value)方法返回一个以给定值解析后的 Promise 对象。 但如果这个值是个 thenable（即带有 then 方法），返回的 promise 会“跟随”这个 thenable的对象，采用它的最终状态；否则以该值为成功状态返回 promise 对象。 Promise.reject() Promise.reject(reason)方法返回一个用reason拒绝的Promise。 [代码] // 以下两个 promise 是等价的 var p1 = new Promise( (resolve,reject) => { resolve( "Oops" ); }); var p2 = Promise.resolve( "Oops" ); var p1 = new Promise( (resolve,reject) => { reject( "Oops" ); }); var p2 = Promise.reject( "Oops" ); [代码] Promise.all() Promise.all方法用于将多个 Promise 实例，包装成一个新的 Promise 实例 [代码] const p = Promise.all([p1, p2, p3]); p.then(function (posts) { // ... }).catch(function(reason){ // ... }); [代码] p的状态由p1、p2、p3决定，分成两种情况。 （1）只有p1、p2、p3的状态都变成fulfilled，p的状态才会变成fulfilled，此时p1、p2、p3的返回值组成一个数组，传递给p的回调函数。 （2）只要p1、p2、p3之中有一个被rejected，p的状态就变成rejected，此时第一个被reject的实例的返回值，会传递给p的回调函数。 Promise.race() Promise.race方法同样是将多个 Promise 实例，包装成一个新的 Promise 实例。 [代码] const p = Promise.race([p1, p2, p3]); p.then(function (posts) { // ... }).catch(function(reason){ // ... }); [代码] 只要p1、p2、p3之中有一个实例率先改变状态，p的状态就跟着改变。那个率先改变的 Promise 实例的返回值，就传递给p的回调函数 Generator 名词解释 迭代器 (Iterator) 迭代器是一种对象，它具有一些专门为迭代过程设计的专有接口，所有迭代器对象都有一个 next 方法，每次调用都返回一个结果对象。 结果对象有两个属性，一个是 value，表示下一个将要返回的值；另一个是 done，它是一个布尔类型的值，当没有更多可返回数据时返回 true。 迭代器还会保存一个内部指针，用来指向当前集合中值的位置，每调用一次 next() 方法，都会返回下一个可用的值。 可迭代对象 (Iterable) 可迭代对象具有 Symbol.iterator 属性，是一种与迭代器密切相关的对象。 Symbol.iterator 通过指定的函数可以返回一个作用于附属对象的迭代器。 在 ECMCScript 6 中，所有的集合对象（数组、Set、及 Map 集合）和字符串都是可迭代对象，这些对象中都有默认的迭代器。 生成器 (Generator) 生成器是一种返回迭代器的函数，通过 function 关键字后的 * 号来表示。 此外，由于生成器会默认为 Symbol.iterator 属性赋值，因此所有通过生成器创建的迭代器都是可迭代对象。 for-of 循环 for-of 循环每执行一次都会调用可迭代对象的迭代器接口的 next() 方法，并将迭代器返回的结果对象的 value 属性储存在一个变量中，循环将持续执行这一过程直到返回对象的属性值为 true。 生成器的一般使用形式 [代码] function *foo() { var x = yield 2 var y = x * (yield x + 1) console.log( x, y ) return x + y } var it = foo() it.next() // {value: 2, done: false} it.next(3) // {value: 4, done: false} it.next(3) // 3 9, {value: 12, done: true} [代码] 遍历器对象的next方法的运行逻辑如下： （1）遇到yield表达式，就暂停执行后面的操作，并将紧跟在yield后面的那个表达式的值，作为返回的对象的value属性值。 （2）下一次调用next方法时，再继续往下执行，直到遇到下一个yield表达式。 （3）如果没有再遇到新的yield表达式，就一直运行到函数结束，直到return语句为止，并将return语句后面的表达式的值，作为返回的对象的value属性值。 （4）如果该函数没有return语句，则返回的对象的value属性值为undefined。 需要注意的是，yield表达式后面的表达式，只有当调用next方法、内部指针指向该语句时才会执行，因此等于为 JavaScript 提供了手动的“惰性求值”（Lazy Evaluation）的语法功能。 异步迭代生成器 [代码] function foo() { setTimeout(() => { it.next('success') // 恢复*main() // it.throw('error') // 向*main()抛出一个错误 }, 2000); } function *main() { try { var data = yield foo() console.log(data) } catch(e) { console.log(e) } } var it = main() it.next() // 这里启动！ [代码] 本例中我们在 *main() 中发起 foo() 请求，之后暂停；又在 foo() 中相应数据恢复 *mian() 继续运行，并将 foo() 的运行结果通过 next() 传递出来。 我们在生成器内部有了看似完全同步的代码（除了 yield 关键字本身），但隐藏在背后的是，在 foo(…)内的运行可以完全异步。并且在异步代码中实现看似同步的错误处理（通过try…catch）在可读性和合理性方面也都是一个巨大的进步。 Generator + Promise 通过promise来管理异步流程 [代码] function foo() { return new Promise(function(resolve, reject){ setTimeout(() => { resolve('fai'); }, 2000); }); } function *main() { try { var data = yield foo() console.log(data) } catch(e) { console.error(e) } } var it = main(); var p = it.next().value; // p 的值是 foo() // 等待 promise p 决议 p.then( function(data) { it.next(data); // 将 data 赋值给 yield }, function(err) { it.throw(err); } ) [代码] *mian() 中执行 foo() 发起请求，返回promise 根据promise 决议结果，根据结果选择继续运行迭代器或抛出错误 如何执行有多处yield的Generator 函数？ [代码] function foo(name) { return new Promise(function(resolve, reject){ setTimeout(() => { resolve('hello ' + name); }, 2000); }); } var gen = function* (){ var r1 = yield foo('jarvis'); var r2 = yield foo('hth'); console.log(r1); console.log(r2); }; var g = gen(); // 手动执行 g.next().value.then(function(data){ g.next(data).value.then(function(data){ g.next(data); }); }); [代码] 手动执行的方式，其实就是用then方法，层层添加回调函数。理解了这一点，就可以写出一个自动执行器 自动执行Generator 函数 [代码] function foo(name) { return new Promise(function(resolve, reject){ setTimeout(() => { resolve('hello ' + name); }, 2000); }); } var gen = function* (){ var r1 = yield foo('jarvis'); var r2 = yield foo('hth'); console.log(r1); console.log(r2); }; function run(gen){ var g = gen(); function next(data){ var result = g.next(data); if (result.done) return result.value; result.value.then(function(data){ next(data); }); } next(); } run(gen); [代码] 只要保证yield后面总是返回promise，就能用run函数自动执行Generator 函数 Async/Await async 函数的一般使用形式 async 函数是什么？ 其实就是 promise+自动执行的Generator 函数的语法糖。类似于我们上面的实现 [代码] function foo(p) { return fetch('http://my.data?p=' + p) } async function main(p) { try { var data = await foo(p) return data } catch(e) { console.error(e) } } main(1).then(data => console.log(data)) [代码] 与 Generator 函数不同是，* 变成了async、yeild变成了await，同时我们也不用再定义 run(…) 函数来实现 Promise 与 Generator 的结合。 async 函数执行的时候，一旦遇到 await 就会先返回，等到异步操作完成，再接着执行函数体内后面的语句，并且最终返回一个 Promise 对象。 正常情况下，await 命令后面是一个 Promise 对象。如果不是，会被转成一个立即 resolve 的 Promise 对象。 await 命令后面的 Promise 对象如果变为 reject 状态，则 reject 的参数会被 catch 方法的回调函数接收到。 async 函数的使用注意点 前面已经说过，await 命令后面的 Promise 对象，运行结果可能是 rejected，所以最好把 await 命令放在 try…catch 代码块中。 多个 await 命令后面的异步操作，如果不存在继发关系，最好让它们同时触发。 await 命令只能用在 async 函数之中，如果用在普通函数，就会报错。 [代码] //getFoo 与 getBar 是两个互相独立、互不依赖的异步操作 // 错误写法 let foo = await getFoo(); let bar = await getBar(); // 正确写法一 let [foo, bar] = await Promise.all([getFoo(), getBar()]); // 正确写法二 let fooPromise = getFoo(); let barPromise = getBar(); let foo = await fooPromise; let bar = await barPromise; [代码] async 函数比Promise好在哪？ 类同步写法，使得在写复杂逻辑时，可以用一种顺序的方式来书写，大大降低了理解的难度。 错误处理上，可以用try catch来捕获，同时处理同步和异步错误。 总结 JavaScript异步编程的发展历程有以下四个阶段： 回调函数: 有两个问题，回调地狱和信任缺失，回调地狱的坏处主要是代码阅读性和可维护性差，同时不好对异步逻辑进行封装。信任缺失主要体现在调用的时机，调用的次数，对异常的处理上缺乏一致性。 Promise 基于PromiseA+规范的实现解决了控制反转带来的信任问题。 Generator 使用生成器函数Generator，我们得以用同步的方式来书写异步的代码，解决了顺序性的问题，这是一种重大的突破。但是使用比较繁琐，需要手动去调用next(…)去控制流程和传参。 Async/Await Async/Await结合了Promise和Generator，并实现了自动执行生成器函数逻辑。使得使用者通添加少量关键字就可以用同步的方式书写异步代码，大大提高了开发效率和代码可维护性。 可以看到，目前Async/Await方式可以说是处理异步的终极解决方案，在项目中应该优先使用这种方式。

摘要： 小程序开发必备技能啊… 原文：小程序如何生成海报分享朋友圈 作者：小白 Fundebug经授权转载，版权归原作者所有。 项目需求写完有一段时间了，但是还是想回过来总结一下，一是对项目的回顾优化等，二是对坑的地方做个记录，避免以后遇到类似的问题。 需求 利用微信强大的社交能力通过小程序达到裂变的目的，拉取新用户。 生成的海报如下： [图片] 需求分析 1、利用小程序官方提供的api可以直接分享转发到微信群打开小程序 2、利用小程序生成海报保存图片到相册分享到朋友圈，用户长按识别二维码关注公众号或者打开小程序来达到裂变的目的 实现方案 一、分析如何实现 相信大家应该都会有类似的迷惑，就是如何按照产品设计的那样绘制成海报，其实当时我也是不知道如何下手，认真想了下得通过canvas绘制成图片，这样用户保存这个图片到相册，就可以分享到朋友圈了。但是要绘制的图片上面不仅有文字还有数字、图片、二维码等且都是活的，这个要怎么动态生成呢。认真想了下，需要一点一点的将文字和数字，背景图绘制到画布上去，这样通过api最终合成一个图片导出到手机相册中。 二、需要解决的问题 二维码的动态获取和绘制（包括如何生成小程序二维码、公众号二维码、打开网页二维码） 背景图如何绘制，获取图片信息 将绘制完成的图片保存到本地相册 处理用户是否取消授权保存到相册 三、实现步骤 这里我具体写下围绕上面所提出的问题，描述大概实现的过程 ①首先创建canvas画布,我把画布定位设成负的,是为了不让它显示在页面上,是因为我尝试把canvas通过判断条件动态的显示和隐藏,在绘制的时候会出现问题,所以采用了这种方法，这里还有一定要设置画布的大小。 [代码]<canvas canvas-id="myCanvas" style="width: 690px;height:1085px;position: fixed;top: -10000px;"></canvas> [代码] ②创建好画布之后，先绘制背景图，因为背景图我是放在本地，所以获取 <canvas> 组件 canvas-id 属性，通过createCanvasContext创建canvas的绘图上下文 CanvasContext 对象。使用drawImage绘制图像到画布，第一个参数是图片的本地地址，后面两个参数是图像相对画布左上角位置的x轴和y轴，最后两个参数是设置图像的宽高。 [代码]const ctx = wx.createCanvasContext('myCanvas') ctx.drawImage('/img/study/shareimg.png', 0, 0, 690, 1085) [代码] ③创建好背景图后，在背景图上绘制头像，文字和数字。通过getImageInfo获取头像的信息，这里需要注意下在获取的网络图片要先配置download域名才能生效，具体在小程序后台设置里配置。 获取头像地址，首先量取头像在画布中的大小，和x轴Y轴的坐标，这里的result[0]是我用promise封装返回的一个图片地址 [代码]let headImg = new Promise(function (resolve) { wx.getImageInfo({ src: `${app.globalData.baseUrl2}${that.data.currentChildren.headImg}`, success: function (res) { resolve(res.path) }, fail: function (err) { console.log(err) wx.showToast({ title: '网络错误请重试', icon: 'loading' }) } }) }) let avatarurl_width = 60, //绘制的头像宽度 avatarurl_heigth = 60, //绘制的头像高度 avatarurl_x = 28, //绘制的头像在画布上的位置 avatarurl_y = 36; //绘制的头像在画布上的位置 ctx.save(); // 先保存状态 已便于画完圆再用 ctx.beginPath(); //开始绘制 //先画个圆 前两个参数确定了圆心 （x,y） 坐标 第三个参数是圆的半径 四参数是绘图方向 默认是false，即顺时针 ctx.arc(avatarurl_width / 2 + avatarurl_x, avatarurl_heigth / 2 + avatarurl_y, avatarurl_width / 2, 0, Math.PI * 2, false); ctx.clip(); //画了圆 再剪切 原始画布中剪切任意形状和尺寸。一旦剪切了某个区域，则所有之后的绘图都会被限制在被剪切的区域内 ctx.drawImage(result[0], avatarurl_x, avatarurl_y, avatarurl_width, avatarurl_heigth); // 推进去图片 [代码] 这里举个例子说下如何绘制文字，比如我要绘制如下这个“字”，需要动态获取前面字数的总宽度，这样才能设置“字”的x轴坐标，这里我本来是想通过measureText来测量字体的宽度，但是在iOS端第一次获取的宽度值不对，关于这个问题，我还在微信开发者社区提了bug，所以我想用另一个方法来实现，就是先获取正常情况下一个字的宽度值，然后乘以总字数就获得了总宽度，亲试是可以的。 [图片] [代码]let allReading = 97 / 6 / app.globalData.ratio * wordNumber.toString().length + 325; ctx.font = 'normal normal 30px sans-serif'; ctx.setFillStyle('#ffffff') ctx.fillText('字', allReading, 150); [代码] ④绘制公众号二维码，和获取头像是一样的，也是先通过接口返回图片网络地址，然后再通过getImageInfo获取公众号二维码图片信息 ⑤如何绘制小程序码，具体官网文档也给出生成无限小程序码接口，通过生成的小程序可以打开任意一个小程序页面，并且二维码永久有效，具体调用哪个小程序二维码接口有不同的应用场景，具体可以看下官方文档怎么说的，也就是说前端通过传递参数调取后端接口返回的小程序码，然后绘制在画布上（和上面写的绘制头像和公众号二维码一样的） [代码]ctx.drawImage('小程序码的本地地址', x轴, Y轴, 宽, 高) [代码] ⑥最终绘制完把canvas画布转成图片并返回图片地址 [代码] wx.canvasToTempFilePath({ canvasId: 'myCanvas', success: function (res) { canvasToTempFilePath = res.tempFilePath // 返回的图片地址保存到一个全局变量里 that.setData({ showShareImg: true }) wx.showToast({ title: '绘制成功', }) }, fail: function () { wx.showToast({ title: '绘制失败', }) }, complete: function () { wx.hideLoading() wx.hideToast() } }) [代码] ⑦保存到系统相册；先判断用户是否开启用户授权相册，处理不同情况下的结果。比如用户如果按照正常逻辑授权是没问题的，但是有的用户如果点击了取消授权该如何处理，如果不处理会出现一定的问题。所以当用户点击取消授权之后，来个弹框提示，当它再次点击的时候，主动跳到设置引导用户去开启授权，从而达到保存到相册分享朋友圈的目的。 [代码]// 获取用户是否开启用户授权相册 if (!openStatus) { wx.openSetting({ success: (result) => { if (result) { if (result.authSetting["scope.writePhotosAlbum"] === true) { openStatus = true; wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } } }, fail: () => { }, complete: () => { } }); } else { wx.getSetting({ success(res) { // 如果没有则获取授权 if (!res.authSetting['scope.writePhotosAlbum']) { wx.authorize({ scope: 'scope.writePhotosAlbum', success() { openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) }, fail() { // 如果用户拒绝过或没有授权，则再次打开授权窗口 openStatus = false console.log('请设置允许访问相册') wx.showToast({ title: '请设置允许访问相册', icon: 'none' }) } }) } else { // 有则直接保存 openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } }, fail(err) { console.log(err) } }) } [代码] 总结 至此所有的步骤都已实现，在绘制的时候会遇到一些异步请求后台返回的数据，所以我用promise和async和await进行了封装，确保导出的图片信息是完整的。在绘制的过程确实遇到一些坑的地方。比如初开始导出的图片比例大小不对，还有用measureText测量文字宽度不对，多次绘制（可能受网络原因）有时导出的图片上的文字颜色会有误差等。如果你也遇到一些比较坑的地方可以一起探讨下做个记录，下面附下完整的代码 [代码]import regeneratorRuntime from '../../utils/runtime.js' // 引入模块 const app = getApp(), api = require('../../service/http.js'); var ctx = null, // 创建canvas对象 canvasToTempFilePath = null, // 保存最终生成的导出的图片地址 openStatus = true; // 声明一个全局变量判断是否授权保存到相册 // 获取微信公众号二维码 getCode: function () { return new Promise(function (resolve, reject) { api.fetch('/wechat/open/getQRCodeNormal', 'GET').then(res => { console.log(res, '获取微信公众号二维码') if (res.code == 200) { console.log(res.content, 'codeUrl') resolve(res.content) } }).catch(err => { console.log(err) }) }) }, // 生成海报 async createCanvasImage() { let that = this; // 点击生成海报数据埋点 that.setData({ generateId: '点击生成海报' }) if (!ctx) { let codeUrl = await that.getCode() wx.showLoading({ title: '绘制中...' }) let code = new Promise(function (resolve) { wx.getImageInfo({ src: codeUrl, success: function (res) { resolve(res.path) }, fail: function (err) { console.log(err) wx.showToast({ title: '网络错误请重试', icon: 'loading' }) } }) }) let headImg = new Promise(function (resolve) { wx.getImageInfo({ src: `${app.globalData.baseUrl2}${that.data.currentChildren.headImg}`, success: function (res) { resolve(res.path) }, fail: function (err) { console.log(err) wx.showToast({ title: '网络错误请重试', icon: 'loading' }) } }) }) Promise.all([headImg, code]).then(function (result) { const ctx = wx.createCanvasContext('myCanvas') console.log(ctx, app.globalData.ratio, 'ctx') let canvasWidthPx = 690 * app.globalData.ratio, canvasHeightPx = 1085 * app.globalData.ratio, avatarurl_width = 60, //绘制的头像宽度 avatarurl_heigth = 60, //绘制的头像高度 avatarurl_x = 28, //绘制的头像在画布上的位置 avatarurl_y = 36, //绘制的头像在画布上的位置 codeurl_width = 80, //绘制的二维码宽度 codeurl_heigth = 80, //绘制的二维码高度 codeurl_x = 588, //绘制的二维码在画布上的位置 codeurl_y = 984, //绘制的二维码在画布上的位置 wordNumber = that.data.wordNumber, // 获取总阅读字数 // nameWidth = ctx.measureText(that.data.wordNumber).width, // 获取总阅读字数的宽度 // allReading = ((nameWidth + 375) - 325) * 2 + 380; // allReading = nameWidth / app.globalData.ratio + 325; allReading = 97 / 6 / app.globalData.ratio * wordNumber.toString().length + 325; console.log(wordNumber, wordNumber.toString().length, allReading, '获取总阅读字数的宽度') ctx.drawImage('/img/study/shareimg.png', 0, 0, 690, 1085) ctx.save(); // 先保存状态 已便于画完圆再用 ctx.beginPath(); //开始绘制 //先画个圆 前两个参数确定了圆心 （x,y） 坐标 第三个参数是圆的半径 四参数是绘图方向 默认是false，即顺时针 ctx.arc(avatarurl_width / 2 + avatarurl_x, avatarurl_heigth / 2 + avatarurl_y, avatarurl_width / 2, 0, Math.PI * 2, false); ctx.clip(); //画了圆 再剪切 原始画布中剪切任意形状和尺寸。一旦剪切了某个区域，则所有之后的绘图都会被限制在被剪切的区域内 ctx.drawImage(result[0], avatarurl_x, avatarurl_y, avatarurl_width, avatarurl_heigth); // 推进去图片 ctx.restore(); //恢复之前保存的绘图上下文状态 可以继续绘制 ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.setFontSize(28); // 文字字号 ctx.fillText(that.data.currentChildren.name, 103, 78); // 绘制文字 ctx.font = 'normal bold 44px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText(wordNumber, 325, 153); // 绘制文字 ctx.font = 'normal normal 30px sans-serif'; ctx.setFillStyle('#ffffff') ctx.fillText('字', allReading, 150); ctx.font = 'normal normal 24px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText('打败了全国', 26, 190); // 绘制文字 ctx.font = 'normal normal 24px sans-serif'; ctx.setFillStyle('#faed15'); // 文字颜色 ctx.fillText(that.data.percent, 154, 190); // 绘制孩子百分比 ctx.font = 'normal normal 24px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText('的小朋友', 205, 190); // 绘制孩子百分比 ctx.font = 'normal bold 32px sans-serif'; ctx.setFillStyle('#333333'); // 文字颜色 ctx.fillText(that.data.singIn, 50, 290); // 签到天数 ctx.fillText(that.data.reading, 280, 290); // 阅读时长 ctx.fillText(that.data.reading, 508, 290); // 听书时长 // 书籍阅读结构 ctx.font = 'normal normal 28px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText(that.data.bookInfo[0].count, 260, 510); ctx.fillText(that.data.bookInfo[1].count, 420, 532); ctx.fillText(that.data.bookInfo[2].count, 520, 594); ctx.fillText(that.data.bookInfo[3].count, 515, 710); ctx.fillText(that.data.bookInfo[4].count, 492, 828); ctx.fillText(that.data.bookInfo[5].count, 348, 858); ctx.fillText(that.data.bookInfo[6].count, 212, 828); ctx.fillText(that.data.bookInfo[7].count, 148, 726); ctx.fillText(that.data.bookInfo[8].count, 158, 600); ctx.font = 'normal normal 18px sans-serif'; ctx.setFillStyle('#ffffff'); // 文字颜色 ctx.fillText(that.data.bookInfo[0].name, 232, 530); ctx.fillText(that.data.bookInfo[1].name, 394, 552); ctx.fillText(that.data.bookInfo[2].name, 496, 614); ctx.fillText(that.data.bookInfo[3].name, 490, 730); ctx.fillText(that.data.bookInfo[4].name, 466, 850); ctx.fillText(that.data.bookInfo[5].name, 323, 878); ctx.fillText(that.data.bookInfo[6].name, 184, 850); ctx.fillText(that.data.bookInfo[7].name, 117, 746); ctx.fillText(that.data.bookInfo[8].name, 130, 621); ctx.drawImage(result[1], codeurl_x, codeurl_y, codeurl_width, codeurl_heigth); // 绘制头像 ctx.draw(false, function () { // canvas画布转成图片并返回图片地址 wx.canvasToTempFilePath({ canvasId: 'myCanvas', success: function (res) { canvasToTempFilePath = res.tempFilePath that.setData({ showShareImg: true }) console.log(res.tempFilePath, 'canvasToTempFilePath') wx.showToast({ title: '绘制成功', }) }, fail: function () { wx.showToast({ title: '绘制失败', }) }, complete: function () { wx.hideLoading() wx.hideToast() } }) }) }) } }, // 保存到系统相册 saveShareImg: function () { let that = this; // 数据埋点点击保存学情海报 that.setData({ saveId: '保存学情海报' }) // 获取用户是否开启用户授权相册 if (!openStatus) { wx.openSetting({ success: (result) => { if (result) { if (result.authSetting["scope.writePhotosAlbum"] === true) { openStatus = true; wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } } }, fail: () => { }, complete: () => { } }); } else { wx.getSetting({ success(res) { // 如果没有则获取授权 if (!res.authSetting['scope.writePhotosAlbum']) { wx.authorize({ scope: 'scope.writePhotosAlbum', success() { openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) }, fail() { // 如果用户拒绝过或没有授权，则再次打开授权窗口 openStatus = false console.log('请设置允许访问相册') wx.showToast({ title: '请设置允许访问相册', icon: 'none' }) } }) } else { // 有则直接保存 openStatus = true wx.saveImageToPhotosAlbum({ filePath: canvasToTempFilePath, success() { that.setData({ showShareImg: false }) wx.showToast({ title: '图片保存成功，快去分享到朋友圈吧~', icon: 'none', duration: 2000 }) }, fail() { wx.showToast({ title: '保存失败', icon: 'none' }) } }) } }, fail(err) { console.log(err) } }) } }, [代码]

开篇 我第一次接触小程序时，还清楚的记得是在2017年的春节期间。当我升级最新版的微信后，开始摸索着新的功能变化。在发现页有一个叫小程序的入口，点进去有一列的“应用”。当我打开一个叫“亲戚关系计算器”的小程序后，简单的使用，然后退出，再去寻找其他的小程序，猫眼电影，自选股，滴滴出行…… 当我尝试着去探索更多小程序的过程中，我突然发现，微信正在发展为一个超级的应用流量入口。而微信中的小程序也可以轻松的坐拥10亿的可用用户人群。 那时候过年，我做的唯一一件事情就是细细的读了小程序的开发文档，心想他可以具有多大的活力与动力，能够引发多大的改变。而我能不能适应他，去随着他的发展，带动自己的腾飞。 很遗憾，当时的小程序并不对个人开发者开放，没有办法注册一个小程序，只能在开发者工具上写一些小的应用，去熟悉小程序的开发。 3月27日，小程序重要更新，其中之一就是支持个人开发者注册小程序。那时候的我，在学校上大一，用一个运营公众号的微信号注册了第一个小程序，并做了一些实验性的开发，并上线。 从这个过程中，我开始细细的体会小程序的优势以及不足，小程序适用于那些领域，小程序适合怎么推广。小程序适合那些行业领域的应用。现在看来，其实从小程序提供的能力，就可以依稀端详出小程序所致力的场景与应用领域。 2018年1月，在我历经半年多的思考和衡量下，做出第一款真正属于自己的小程序——GS比赛计分。去尝试探索线上小程序和线下场景的交融，在这过程中有顾虑，有大胆创新，但都为我更深层次理解小程序有很大的帮助。 目前，自己已经做过10余款小程序，除了GS比赛计分开发时间很长，其他的小程序都是一个月左右的时间完工。比如2019年2月的高校课程助手；2019年3月的数据查询助手；2019年4月的数据汇总助手。 我接下来会从小程序的需求分析与应用设计，小程序的开发，小程序的运营3篇来讲述我对于微信小程序的独自见解与经验。希望能为更多的学生开发者有所启发和借鉴。 需求分析与应用设计 要清楚的认识到小程序对自己需求的最大赋能，需要从最初去理解小程序的定位，微信团队对于小程序的定义是这样的： 微信小程序是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。 通过对小程序提供能力的分析，不难看出。小程序相对于APP来说，在降低开发门槛的同时能够满足最普遍的应用需求，适合生活服务类线下商铺以及非刚需低频应用领域。使得微信通过小程序作为生态的建立者和维护者，赋能商家和应用者。以一种生态触角的状态来迅速的捕捉最大化生态红利。 当清楚的理解小程序的定位后，那么就需要合理的筛选需求并进行应用的功能设计。我将会使用【GS比赛计分】作为例子进行分析说明。 1.用实质的问题引出明确需求，并确定解决问题的功能边界 首先思考的是，自己需要做的功能都有哪些，使用人群是谁？使用场景是什么？需要数据的实时性吗？ 一开始设计【GS比赛计分】的时候，目的是为了解决现在的中小型比赛使用人工计分的失效性差，出错率高，人工和时间成本昂贵的问题。程序的目的是将比赛计分的相关人员用互联网工具联系起来，以提升计分效率。 [图片] 当明晰了产品目标后，开始考虑使用人群。一般来看，大多数的比赛计分都是由两种角色构成的，一个是评委（分数确定者），另一个是工作人员（分数汇总者）。 传统的计分过程是通过现场工作人员将评委的分数以纸质的形式送达计分人员。在这一过程中就有大量的成本浪费了（一个是人力成本，另一个是时间成本）。另外，计分人员以Excel或计算器和笔记的形式进行比分汇总，在这一过程中又存在大量的成本浪费（人力成本和时间成本甚至还有错误风险）。 [图片] 所以横观所有的主观评分的线下比赛，无一例外都存在比赛结束后有长时间的节目或视频热场环节，其实这都是在为人工计分的缓慢争取时间。 所以，【GS比赛计分】的使用人群和使用场景就确定下来了，与传统人工计分的过程类似，只不过需要互联网赋能，解决时间和人力成本。需要数据的实时交互。 【GS比赛计分】作为解决现象问题的工具，首先需要做的就是不要违背现象中事件的发生次序。所以功能完全参照比赛计分过程来设计。具体功能如下，提交成绩，撤回成绩，弃权处理，实时的选手分数，实时的选手名次，清楚评委数据，解绑评委，重启比赛，结束比赛，比赛内置会话。 2.对程序平台进行横向比对，明确小程序的优势和劣势 当程序的功能确定好后，不要着急着手界面设计，功能模块的组合，交互设计这些过程。当你在进行这些过程之前，需要认真的去考虑你的应用是不是适合在小程序上开发。 小程序的火爆，注定有许多人盲目的进入这一领域，但不是所有的应用都适合小程序的推广模式，也不是所有应用都能吃得起小程序的运行效率的。所以在确定开发小程序之前，正确的认识的合适与不合适，避免让自己的成本白白的付出。 如何确定适不适合用小程序来做呢？我们可以让小程序作为一个互联网平台，把应用带入到互联网的每一个平台中去，进行横向的对比，去找出各自的优点与不足，当做出客观的判断后，应用在小程序上相比于其他平台有没有优势就很明显了。 还是以【GS比赛计分】举例。我所横向对比平台包括PC、原生APP、Web平台、轻应用、小程序。首先从满足功能来说，比赛计分需要很稳定的实时性，所以我将Web平台排除（因为复杂的比赛环境，不同的设备浏览器难免会有问题）。 然后将剩下的平台做分析。PC平台使用可能性太小（原因：比赛现场成本太高昂，租借笔记本可能都不是现实的）；原生APP不适合（原因：评委评分前需要下载APP，比赛结束后没什么用了，需要把这个APP卸载。而且IOS和安卓两大平台增加了研发成本）；轻应用有阻碍（原因：百度轻应用由于装机量小，覆盖人群不多。支付宝小程序没有社交关系链，无法有效的推送给需要的人。产业联盟轻应用，苹果用户怎么考虑？） [图片] 经过一系列的对比，很明显。对于【GS比赛计分】来讲，微信小程序是最好的应用平台。同时微信小程序仍然可以和不同的平台进行联系，所以可扩展性，功能延展性都是最佳的。 3.应用设计要满足即用即走的理念 当确定小程序是最理想的应用平台时，我们需要对小程序进行便利化的设计。这就需要抛弃一部分原生应用开发或Web开发的一些设计理念。追求“极致、简约”的风格设计。 在【GS比赛计分】的详细设计时，我考虑到，以个人账户的形式去下发比赛的流程是行不通的，既然服务于比赛，那么就以比赛为最基本的账户组成单元，明确一个比赛ID。而同一个比赛的不同角色，以不同的IK进行区别，而角色的设置包含在比赛设计中，由比赛创建者在创建比赛时自行创建。 那么小程序的使用场景就出来了。以比赛现场的告知或者微信聊天的分享，告知比赛参与角色其ID和IK，就可以让角色快速的进入绑定角色并使用程序。免去注册的一系列烦恼。 同时在微信用户面前，这个账户体系是平权的，任何用户在得知ID和IK的情况下都可以进入（账户绑定情况下不可以进入），一定程度上免除密码和忘记密码，注销账户这一系列的麻烦。 当完成比赛后，程序已经完成了自己所有的任务时，使用者可以直接退出程序，不需要注销比赛等操作。真正做到即走。 在使用过程中，要清楚的考虑用户的使用过程，从而做一些保险机制。微信小程序运行在微信上，微信是社交工具，就免不了用户会退出小程序甚至微信去做一些其他的事情。所以【GS比赛计分】在设计时要保证用户回来要用到自己想要的，在程序设计中有中间状态界面能够保证用户可以迅速进入使用状态。 4.对于很大的系统，要把最适合小程序部分拿出来，而不是全部 现在的【GS比赛计分】其实是一个大的生态系统，结合有线下的网络接口，展示接口，线上小程序，web平台。每一个部分都承载着自己独特的应用价值。 比如Web平台就承载比赛管理的任务，创建比赛，上传比赛文件，选手图片，设置选手（名称、介绍、手机号、图片、出场顺序），设置评分项（名称、权值、预置分数），设置评委（名称、权值，IK）。从实际的分析来看，比赛管理最适合在PC端进行，不管是文件还是图片，公认都是PC上传比较容易。 在最初设计的时候，我错误的把系统分成了多个小程序进行系统搭建，在实际使用过程中造成了重大的缺陷和用户流失。最大的表现是，我开发了【GS比赛创建】小程序，作为比赛的入口程序。从而造成比赛数量增速缓慢，大的使用场景无法突破，老用户意见上升等一系列问题。不得不注销了【GS比赛创建】小程序，并进行很大的架构调整。【GS比赛计分】暂停使用，造成大量的用户流失。 [图片] 所以，当设计多场景，前后联动性很强的应用时，需要将功能进行使用划分，每一个划分需要找最适合的平台。最适合小程序的部分，就做好与其他平台的无缝结合。 5.小程序的应用场景和机会 目前来看，小程序的应用场景主要包括支付场景，比如扫码支付、快消餐饮、移动购物、交通出行等等，工具类小程序能更碎片化、垂直化地满足细分的应用场景需求。 根据微信的最近更新变化来看，公众号和小程序的协同作用将越发明显，公众号的作用也将进一步放大，因此未来发展的机会可能在这几方面。 内容营销，小程序能通过更完善更精准的服务进而提高用户黏性。具体来看包括各大知识付费的小程序以及在教育风口上的小程序。当然，这些小程序也可同时开发APP（按微信对小程序的开发步骤来看）从而实现用户沉淀。 具有支付场景的各类商家。包括传统的已有一定客户群的商家提供更方便的服务或者实现线上线下联动以及新零售。 工具类小程序。包括共享经济领域，这类小程序即用即走，轻量化，便捷化。 天生具有社交属性的小程序。比如抽奖、互赠礼品、拼团减价、社交性的小游戏以及帮拿快递等。 小程序的开发经验 1. 微信小程序开发文档是最好的学习文档 很多同学喜欢看视频教程，或者买一本小程序开发书来学习。觉得这么学会加深理解更加容易上手，而官方文档干巴巴不好学。现在的微信小程序能力更新速度很快，当一个教程或书出来的时候，其实已经过时了。建议同学去微信公开课中学习微信小程序的入门教程，开发入门后，根据自己的开发需要，自行阅读官方文档来学习。 [图片] 2. 必须了解小程序的运行原理 微信小程序是运行在微信中的，所以运行速度并不能和原生媲美。但是在开发小程序的过程中，可以用良好的编程思路来追求程序的高效运行水平。但前提是，你需要对小程序的运行环境有所理解，需要知道在开发环境和真实环境（IOS和Android）下的运行差别。大部分的开发坑都是因为不同运行环境造成的。 官方的声明：微信小程序运行在三端：iOS、Android 和 用于调试的开发者工具；在 iOS 上，小程序的 javascript代码是运行在JavaScriptCore中；在Android上，小程序的javascript代码是通过 X5 内核来解析；在开发工具上，小程序的javascript代码是运行在nwjs（chrome内核）中。 微信小程序的运行环境类似 ReactNative ，而不是纯 Html5。两者最大的不同在于，ReactNative 的界面是由原生控件渲染出来的，而 Html5 的界面是由浏览器内核渲染出来的。两者在性能上有较大的差异，从而表现出来微信小程序要比h5页面好很多。 3.安利小程序云开发 云开发为开发者提供完整的云端支持，弱化后端和运维概念，无需搭建服务器，使用平台提供的 API 进行核心业务开发，即可实现快速上线和迭代，同时这一能力，同开发者已经使用的云服务相互兼容，并不互斥。目前提供三大基础能力支持： 云函数：在云端运行的代码，微信私有协议天然鉴权，开发者只需编写自身业务逻辑代码 数据库：一个既可在小程序前端操作，也能在云函数中读写的 JSON 数据库 存储：在小程序前端直接上传/下载云端文件，在云开发控制台可视化管理 云开发使得小程序开发门槛进一步降低，甚至偏前端的开发人员也可以独立开发小程序了。另外，云开发中云函数支持去请求第三方服务接口。所以云开发最大程度上提供了小程序所需基本API的构建，另外可以通过第三方服务请求能力扩展API能力。 [图片] 而且云开发的数据库和存储完全可以与云函数构建一个小型的后端平台。并发能力中等，适合大部分的小程序业务API的构建。 4. 养成良好的小程序代码习惯 微信小程序的代码文件分为4种，WXML、WXSS、JS、JSON。 JSON文件是小程序的配置文件，APP.JSON是小程序全局配置，另外每个页面也会有配置文件。建议页面中的JSON文件只填写页面需要配置的（比如页面标题），而不变化的不要写到里面（比如标题风格，背景颜色等等）。 JS主要是javascript语法，建议以模块的形式对通用的方法进行封装，尽可能的利用好代码，不要有大量重复的方法语句。如果多个页面需要，可以单独建立js文件，在需要的页面进行引入。 WXSS是样式文件，遵从css的编写规则，尽可能的少些样式表，多多利用已经写过的样式，如果多个页面需要，可以单独建立wxss或者写到app.wxss中 WXML是页面结构文件。如果多个页面中有相同的结构，可以单独封装为模块，而模块中的逻辑方面也尽可能遵从代码最大效益化。 总之，开发代码简洁，会使得编译后的小程序包很小，使加载速度更加快速。 5. 小程序填坑总结： 首先，微信开发者社区是好的小程序开发交流平台，从中可以获得大多数问题的解决方法： https://developers.weixin.qq.com/community/develop/question 另外，许多人常用搜索引擎来直接搜索问题的解决方法，一般大部分的错误或者问题都会在开发文档上写的很清楚，只不过很少有人去注意到，推荐几个小程序填坑的集合文章： https://blog.csdn.net/weixin_42448956/article/details/82414225 https://www.cnblogs.com/shaoting/p/6051261.html https://www.imooc.com/article/36148 https://www.cnblogs.com/wangking/p/6946438.html https://www.jianshu.com/p/4362e52f5c49 小程序的运营 小程序运营属于软件产品运营的一种类别。从产品生命期来看，小程序运营分别为研发期、种子期、成长期、成熟期、衰退期。另外由于小程序在运行模式和定位的不同，表现在推广形式上与平常的软件产品有很大的差别。接下来，我会用【GS比赛计分】【数据查询助手】小程序为例子佐证分享小程序的运营经验。 1. 小程序研发期，搞清楚产品的定位以及目标用户 当你不是运营小程序的产品策划者，你需要首先要搞清楚产品的定位以及目标用户。（这也是多数互联网公司将产品策划和运营作为一个岗位的原因）。在整个产品的研发期，需要跟进产品的每一个细微功能点，要明晰产品的使用用户；还要时刻去观察产品的领域有没有竞品的出现，用户习惯有什么改变；要时刻去衡量产品的竞争优势，为之后的发布运营做好准备。 【数据查询助手】是提供自定义信息查询服务的小程序。任何微信用户均可以上传自定义的数据（报表，成绩单等任何表格数据）建立查询。 [图片] 当在产品研发的一个月，我不断的探索小程序领域，APP领域，Web领域有没有相同的功能产品或服务。甚至将问卷系统（腾讯问卷、问卷星、问卷网）作为潜在的竞争对手。 另外我还制作了web版和原生APP的Demo去体验他们与小程序体验的不同。去确定微信小程序是很好的适应平台。从而为之后的运营做足了准备，提升了自己的信心。 2. 小程序种子期，要充分利用体验版过程 小程序体验版相当于其他应用平台的内测版。体验版可以更高层次的模仿真实的用户环境。在这一阶段更容易发现用户间连接要求高的应用缺陷。同时可以在安全的范围内去聆听用户的真是使用反馈。 【GS比赛计分】开展了长达1个月的体验版。邀请了20个核心用户去体验。由于应用需要与服务端建立实时连接。用户不同的设备，不同网络环境对程序的稳定性做出了很大的考验。在这一阶段修复了不少场景不同导致的错误或者效率低下问题。 另外一开始推出的小程序界面设计只遵从了功能设计，没有很好的考虑真实的使用场景。所以在这一阶段，我最大程度上听取体验用户的建议，对整个界面进行改版，使交互更加的亲近用户。 3. 小程序成长期，明晰获取用户的手段和推广手段，最大化的成长： 当小程序功能稳定后，到了成长阶段，用户使用是最核心的任务。获取用户的时候，必须先让对方了解自己的产品，建立认知，将产品介绍给用户，让用户进入小程序之后，想方设法让产品与用户产生交互，让用户不断体验产品，让活动始终覆盖用户，让用户对产品认可，要完成产品与用户的关系构建。 从现在许多小程序的运营手段来看，基本上都围绕着社交裂变和线下推广的方式来提升小程序的获客表现。而小程序由于较低的开发成本，较快的更新速度，以及较低的试错成本，使得多数很强势的小程序都采用功能矩阵发展模式，快速实现功能及迭代。 小程序获取用户的手段主要由下： 朋友圈分享（包括图片二维码、广告直接进入）； 聊天好友推荐转发； 线下二维码（包含商家推广、广告推广）； 微信搜索（一般由其他社交平台或者用户需求引起）； 线上识别二维码（线上推广，文章推广，或其他社交平台的推广）； 其他小程序的跳转（互相推荐） 公众号跳转（公众号运营推广） APP跳转（一般是APP延展的简洁功能推广，或者轻量级触达用户形式的推广） 小程序发掘社交推广的手段主要由下： 社交立减金，实现社交裂变； 社交比拼玩法，引导社交裂变； 互动加入分享按钮，提醒用户转发； 设计同伴环境，鼓励社群传播； 设计任务玩法，领取奖励； 设计福利，鼓励好友助力； 聚焦核心功能，促进口碑传播； 【数据查询助手】从产品定位上就自带社交裂变的元素，当查询创建者创建了一个查询后，他可以根据要分享的人群情况选择多种分享方法。如果是企业微信或者微信工作群，那么可以直接分享小程序到聊天窗口。其他的用户可以直接进入小程序进行查询。如果是线下的查询（推广会，现场发布等），可以通过小程序二维码的方式进入查询界面查询。对于其他社交平台来讲，可以用二维码来做分享，如果是常用用户（添加到我饿小程序或者桌面作为常用工具的用户），可以直接通过复制文字（含查询码）然后进入应用的方式快速开始查询。 同时每一个查询者，都可能是潜在的查询创建者和程序推广者。所以要在这一阶段不断的优化体验流程，尽可能做更多事情覆盖多场景的查询（比如微信搜一搜直接搜索查询码，直接查询），去吸引用户，留住用户。 由于小程序用完即走的理念，导致许多工具类小程序（不含深度融合线下和社交的）用户的留存普遍较低。既然工具类就是服务用户，那么就把小程序慢慢的做成一种用户习惯，从习惯的养成变为行业应用的转化。从转化中寻找切入点，进而挖掘可以创造价值的功能产品。 所以，做小程序不要过分贪图大规模的使用率，大批量的用户。他本身是一种服务理念的触达和养成，你需要在用户心里养成使用习惯，而不要上来糖衣炮弹把用户打蒙，甚至反感。这样小程序的生态就被搞乱了。 4. 小程序成熟期，稳定期最重要的就是小版本的迭代更新： 刚才讲到，小程序有较低的开发成本，较快的更新速度，以及较低的试错成本。所以在小程序成熟期需要根据用户数据不断的去更正调整功能，去保持较高的运营分数。在产品功能中，适时的进行用户付费转化。 付费转化一方面可以拉开用户层次，对小程序的用户是一种活水作用，提升用户的使用粘性，容易过滤最核心的用户，提供更加好的产品服务。如果在成长期很好的进行用户习惯的养成，这个过程会更加自然。反之，应用将会更快的进入衰退期。 付费转化的方式主要由几类： 电商类：主要靠活动、优惠刺激（现实抢购、秒杀、预约、限时满减、显示商品库存和抢购人数）； 游戏类：游戏道具（向朋友求助、每日签到、社区活动等方式免费获得，但数量有限，且都是一些级别较低的道具）高价值道具付费、皮肤售卖、游戏币购买； 内容类：付费文章、阅读币购买、付费课程； 5.小程序衰退期：适时舍弃，进行新产品开始推出 小程序开发周期短，很多时候应用分析不够透彻，更多的是一些商业或推广试错。导致许多小程序还没有进入成长期就进入晚期了。这一类小程序直接舍弃就好，不需要什么转化了，这也不算小程序的衰退期（没有盛何来衰）。 对于经历过成熟期的产品主要有几个原因导致进入衰退期： 市场中有新的创新型产品，导致冲击衰退。 自身功能设计有缺陷，导致用户流失。 对用户了解不透彻，付费转化失败，用户迁移到同类产品。 产品质量下降，不能适应用户行为的变化。 由于运营组织的原因，产品运营出现危机。 在这一阶段，运营已经无能为力。那么就进行产品的复盘，积极的去投入到新产品或者新领域的探究上面去。小程序的开发成本较低，所以可以有很多机会去重新塑造一个好的产品。 6.总结，谈谈自己的想法： 现在多种多样的互联网产品不断产生，产品竞争异常激烈。互联网产品的运营手段也是推陈出新，花样繁多。在这里我不给大家分享一些运营花样，因为每个小程序都是独特的，应该有自己独特的运营手段，具体是什么，希望产品者和运营者本身用热爱小程序的心去发现和实践。 永远保持对产品的尊重，对用户的尊敬是每个产品人最重要的事情。如果对应用足够热爱，你会厌恶他被污染，他被别人嫌弃；你会尽自己的可能让他变得更加本真，你会合理的去运营突破，去帮助产品走向更高的位置。 如果你没有爱你的产品，再出色的产品也只是昙花一现而已，并不能给你带来任何长远的意义。 这是最好的小程序运营指南：https://developers.weixin.qq.com/miniprogram/product。 [图片]