小程序-登录
unionid和openid
了解小程序登陆之前,我们写了解下小程序/公众号登录涉及到两个最关键的用户标识:
OpenId
是一个用户对于一个小程序/公众号的标识,开发者可以通过这个标识识别出用户。UnionId
是一个用户对于同主体微信小程序/公众号/APP的标识,开发者需要在微信开放平台下绑定相同账号的主体。开发者可通过UnionId,实现多个小程序、公众号、甚至APP 之间的数据互通了。关键Api
wx.login
官方提供的登录能力wx.checkSession
校验用户当前的session_key是否有效wx.authorize
提前向用户发起授权请求wx.getUserInfo
获取用户基本信息
登录流程设计
以下从笔者接触过的几种登录流程来做阐述:利用现有登录体系
直接复用现有系统的登录体系,只需要在小程序端设计用户名,密码/验证码输入页面,便可以简便的实现登录,只需要保持良好的用户体验即可。利用OpenId 创建用户体系
👆提过,OpenId
是一个小程序对于一个用户的标识,利用这一点我们可以轻松的实现一套基于小程序的用户体系,值得一提的是这种用户体系对用户的打扰最低,可以实现静默登录。具体步骤如下:
- 小程序客户端通过
wx.login
获取 code - 传递 code 向服务端,服务端拿到 code 调用微信登录凭证校验接口,微信服务器返回
openid
和会话密钥session_key
,此时开发者服务端便可以利用openid
生成用户入库,再向小程序客户端返回自定义登录态 小程序客户端缓存 (通过
storage
)自定义登录态(token),后续调用接口时携带该登录态作为用户身份标识即可
利用 Unionid 创建用户体系
如果想实现多个小程序,公众号,已有登录系统的数据互通,可以通过获取到用户 unionid 的方式建立用户体系。因为 unionid 在同一开放平台下的所所有应用都是相同的,通过
unionid
建立的用户体系即可实现全平台数据的互通,更方便的接入原有的功能,那如何获取unionid
呢,有以下两种方式:如果户关注了某个相同主体公众号,或曾经在某个相同主体App、公众号上进行过微信登录授权,通过
wx.login
可以直接获取 到unionid
- 结合
wx.getUserInfo
- 和
<button open-type="getUserInfo"><button/>
- 这两种方式引导用户主动授权,主动授权后通过返回的信息和服务端交互 (这里有一步需要服务端解密数据的过程,很简单,微信提供了示例代码) 即可拿到
unionid
建立用户体系, 然后由服务端返回登录态,本地记录即可实现登录,附上微信提供的最佳实践:
需要获取
unionid
形式的登录体系,在以前(18年4月之前)是通过以下这种方式来实现,但后续微信做了调整(因为一进入小程序,主动弹起各种授权弹窗的这种形式,比较容易导致用户流失),调整为必须使用按钮引导用户主动授权的方式,这次调整对开发者影响较大,开发者需要注意遵守微信的规则,并及时和业务方沟通业务形式,不要存在侥幸心理,以防造成小程序不过审等情况。wx.login(获取code) ===> wx.getUserInfo(用户授权) ===> 获取 unionid
因为小程序不存在
cookie
的概念, 登录态必须缓存在本地,因此强烈建议为登录态设置过期时间- 值得一提的是如果需要支持风控安全校验,多平台登录等功能,可能需要加入一些公共参数,例如platform,channel,deviceParam等参数。在和服务端确定方案时,作为前端同学应该及时提出这些合理的建议,设计合理的系统。
openid
,unionid
不要在接口中明文传输,这是一种危险的行为,同时也很不专业。
小程序-图片导出
经常开发和使用小程序的同学对这个功能一定不陌生,这是一种常见的引流方式,一般同时会在图片中附加一个小程序二维码。
基本原理
借助
canvas
元素,将需要导出的样式首先在canvas
画布上绘制出来 (api基本和h5保持一致,但有轻微差异,使用时注意即可)借助微信提供的
canvasToTempFilePath
导出图片,最后再使用saveImageToPhotosAlbum
(需要授权)保存图片到本地
如何优雅实现
根据上述的原理来看,实现是很简单的,只不过就是设计稿的提取,绘制即可,但是作为一个常用功能,每次都这样写一坨代码岂不是非常的难受。那小程序如何设计一个通用的方法来帮助我们导出图片呢?思路如下:
绘制出需要的样式这一步是省略不掉的。但是我们可以封装一个绘制库,包含常见图形的绘制,例如矩形,圆角矩形,圆, 扇形, 三角形, 文字,图片减少绘制代码,只需要提炼出样式信息,便可以轻松的绘制,最后导出图片存入相册。笔者觉得以下这种方式绘制更为优雅清晰一些,其实也可以使用加入一个type参数来指定绘制类型,传入的一个是样式数组,实现绘制。
结合上一步的实现,如果对于同一类型的卡片有多次导出需求的场景,也可以使用自定义组件的方式,封装同一类型的卡片为一个通用组件,在需要导出图片功能的地方,引入该组件即可。
class CanvasKit { constructor() { } drawImg(option = {}) { … return this } drawRect(option = {}) { return this } drawText(option = {}) { … return this } static exportImg(option = {}) { … } }let drawer = new CanvasKit(‘canvasId’).drawImg(styleObj1).drawText(styleObj2) drawer.exportImg()
注意事项
小程序中无法绘制网络图片到canvas上,需要通过downLoadFile 先下载图片到本地临时文件才可以绘制
通常需要绘制二维码到导出的图片上,有一种方式导出二维码时,需要携带的参数必须做编码,而且有具体的长度(32可见字符)限制,可以借助服务端生成
短链接
的方式来解决小程序-数据统计
数据统计作为目前一种常用的分析用户行为的方式,小程序端也是必不可少的。小程序采取的曝光,点击数据埋点其实和h5原理是一样的。但是埋点作为一个和业务逻辑不相关的需求,我们如果在每一个点击事件,每一个生命周期加入各种埋点代码,则会干扰正常的业务逻辑,和使代码变的臃肿,笔者提供以下几种思路来解决数据埋点:
设计一个埋点sdk
小程序的代码结构是,每一个 Page 中都有一个 Page 方法,接受一个包含生命周期函数,数据的
业务逻辑对象
包装这层数据,借助小程序的底层逻辑实现页面的业务逻辑。通过这个我们可以想到思路,对Page进行一次包装,篡改它的生命周期和点击事件,混入埋点代码,不干扰业务逻辑,只要做一些简单的配置即可埋点,简单的代码实现如下: 代码仅供理解思路 page = function(params) { let keys = params.keys() keys.forEach(v => {if (v === 'onLoad') {
params[v] = function(options) {
stat() //曝光埋点代码
params[v].call(this, options)
}
}
else if (v.includes('click')) {
params[v] = funciton(event) {
let data = event.dataset.config
stat(data) // 点击埋点
param[v].call(this)
}
}
}) }这种思路不光适用于埋点,也可以用来作全局异常处理,请求的统一处理等场景。
分析接口
对于特殊的一些业务,我们可以采取
接口埋点
,什么叫接口埋点呢?很多情况下,我们有的api并不是多处调用的,只会在某一个特定的页面调用,通过这个思路我们可以分析出,该接口被请求,则这个行为被触发了,则完全可以通过服务端日志得出埋点数据,但是这种方式局限性较大,而且属于分析结果得出过程,可能存在误差,但可以作为一种思路了解一下。微信自定义数据分析
微信本身提供的数据分析能力,微信本身提供了常规分析和自定义分析两种数据分析方式,在小程序后台配置即可。借助
小程序数据助手
这款小程序可以很方便的查看。小程序-工程化
工程化做什么
目前的前端开发过程,工程化是必不可少的一环,那小程序工程化都需要做些什么呢,先看下目前小程序开发当中存在哪些问题需要解决:
不支持 css预编译器,作为一种主流的 css解决方案,不论是 less,sass,stylus 都可以提升css效率
- 不支持引入npm包 (这一条,从微信公开课中听闻,微信准备支持)
- 不支持ES7等后续的js特性,好用的async await等特性都无法使用
- 不支持引入外部字体文件,只支持base64
-
方案选型
对于目前常用的工程化方案,webpack,rollup,parcel等来看,都常用与单页应用的打包和处理,而小程序天生是 “多页应用” 并且存在一些特定的配置。根据要解决的问题来看,无非是文件的编译,修改,拷贝这些处理,对于这些需求,我们想到基于流的
gulp
非常的适合处理,并且相对于webpack配置多页应用更加简单。所以小程序工程化方案推荐使用gulp
具体开发思路
通过 gulp 的 task 实现:
实时编译 less 文件至相应目录
- 引入支持async,await的运行时文件
- 编译字体文件为base64 并生成相应css文件,方便使用
- 依赖分析哪些地方引用了npm包,将npm包打成一个文件,拷贝至相应目录
- 检查代码规范
上述实现起来其实并不是很难,但是这样的话就是一份纯粹的 gulp 构建脚本和 约定好的目录而已,每次都有一个新的小程序都来拷贝这份脚本来处理吗?显然不合适,那如何真正的实现 小程序工程化
呢? 我们可能需要一个简单的脚手架,脚手架需要支持的功能:
- 支持新建项目,创建Page,创建Component
- 支持内置构建脚本
- 支持发布小程序,也可以想办法接入Jenkins等工具做持续集成 (小程序持续集成后面会提) …