登录流程

一、背景

传统的web开发实现登陆功能，一般的做法是输入账号密码、或者输入手机号及短信验证码进行登录

服务端校验用户信息通过之后，下发一个代表登录态的 token 给客户端，以便进行后续的交互,每当token过期，用户都需要重新登录

而在微信小程序中，可以通过微信官方提供的登录能力方便地获取微信提供的用户身份标识，快速建立小程序内的用户体系，从而实现登陆功能

实现小程序用户体系主要涉及到openid和code的概念：

• 调用wx.login()方法会生成code，将code作为参数传递给微信服务器指定接口，就可以获取用户的openid

对于每个小程序，微信都会将用户的微信ID映射出一个小程序 openid，作为这个用户在这个小程序的唯一标识

二、流程

微信小程序登陆具体实现的逻辑如下图所示：

• 通过 wx.login() 获取到用户的code判断用户是否授权读取用户信息，调用wx.getUserInfo 读取用户数据
• 由于小程序后台授权域名无法授权微信的域名，所以需要自身后端调用微信服务器获取用户信息
• 通过 wx.request() 方法请求业务方服务器，后端把 appid , appsecret 和 code 一起发送到微信服务器。 appid 和 appsecret 都是微信提供的，可以在管理员后台找到
• 微信服务器返回了 openid 及本次登录的会话密钥 session_key
• 后端从数据库中查找 openid ，如果没有查到记录，说明该用户没有注册，如果有记录，则继续往下走
• session_key 是对用户数据进行加密签名的密钥。为了自身应用安全，session_key 不应该在网络上传输
• 然后生成 session并返回给小程序
• 小程序把 session 存到 storage 里面
• 下次请求时，先从 storage 里面读取，然后带给服务端
• 服务端对比 session 对应的记录，然后校验有效期

更加详细的功能图如下所示：

三、扩展

实际业务中，我们还需要登录态是否过期，通常的做法是在登录态（临时令牌）中保存有效期数据，该有效期数据应该在服务端校验登录态时和约定的时间（如服务端本地的系统时间或时间服务器上的标准时间）做对比

这种方法需要将本地存储的登录态发送到小程序的服务端，服务端判断为无效登录态时再返回需重新执行登录过程的消息给小程

另一种方式可以通过调用wx.checkSession检查微信登陆态是否过期：

• 如果过期，则发起完整的登录流程
• 如果不过期，则继续使用本地保存的自定义登录态

这种方式的好处是不需要小程序服务端来参与校验，而是在小程序端调用API，流程如下所示：

发布流程

一、背景

在中大型的公司里，人员的分工非常仔细，一般会有不同岗位角色的员工同时参与同一个小程序项目。为此，小程序平台设计了不同的权限管理使得项目管理者可以更加高效管理整个团队的协同工作

以往我们在开发完网页之后，需要把网页的代码和资源放在服务器上，让用户通过互联网来访问

在小程序的平台里，开发者完成开发之后，需要在开发者工具提交小程序的代码包，然后在小程序后台发布小程序

二、流程

关于发布的流程，主要分成了三个部分：

• 上传代码
• 提交审核
• 发布版本

上传代码

在开发者工具中，可以点击代码上传功能：

然后就可以填写版本信息：

然后点击上传，编译器则会提示上传代码成功

提交审核

代码上传完毕，就可以登陆微信公众号的官网首页，点击【开发管理】，查看应用详情：

提交审核过程需要填写审核信息，如下图：

提交审核成功之后如下图：

发布版本

当审核通过之后，即可提交发布

发布成功之后则如下：

三、扩展

上述是最简单的小程序代码发布的流程，通常的流程如下：

• 代码管理服务器上新建分支
• 开发测试新需求
• 测试完成后，将本地分支合并到 master 分支
• 拉取 master 分支最新代码，执行 build 命令生成小程序可执行文件
• 开发者工具点击“上传”
• 提审
• 发布

但是面对多人协调开发的时候，有可能出现已经上线的代码还没合并到master的情况

因此可以考虑自动化构建部署，就是将从开发到部署的一系列流程变成自动化，衔接连贯，在构建失败时能够告知开发者，构建成功后能够告知测试和实施人员，可参考如下流程图：

支付流程

一、前言

微信小程序为电商类小程序，提供了非常完善、优秀、安全的支付功能

在小程序内可调用微信的API完成支付功能，方便、快捷

场景如下图所示：

• 用户通过分享或扫描二维码进入商户小程序，用户选择购买，完成选购流程
• 调起微信支付控件，用户开始输入支付密码
• 密码验证通过，支付成功。商户后台得到支付成功的通知
• 返回商户小程序，显示购买成功
• 微信支付公众号下发支付凭证

二、流程

以电商小程序为例

支付流程图如下所示：

具体的做法：

• 打开某小程序，点击直接下单
• wx.login获取用户临时登录凭证code，发送到后端服务器换取openId
• 在下单时，小程序需要将购买的商品Id，商品数量，以及用户的openId传送到服务器
• 服务器在接收到商品Id、商品数量、openId后，生成服务期订单数据，同时经过一定的签名算法，向微信支付发送请求，获取预付单信息(prepay_id)，同时将获取的数据再次进行相应规则的签名，向小程序端响应必要的信息
• 小程序端在获取对应的参数后，调用wx.requestPayment()发起微信支付，唤醒支付工作台，进行支付
• 接下来的一些列操作都是由用户来操作的包括了微信支付密码，指纹等验证，确认支付之后执行鉴权调起支付
• 鉴权调起支付：在微信后台进行鉴权，微信后台直接返回给前端支付的结果，前端收到返回数据后对支付结果进行展示
• 推送支付结果：微信后台在给前端返回支付的结果后，也会向后台也返回一个支付结果，后台通过这个支付结果来更新订单的状态

其中后端响应数据必要的信息则是wx.requestPayment方法所需要的参数，大致如下：

wx.requestPayment({
  // 时间戳
  timeStamp: '',
  // 随机字符串
  nonceStr: '',
  // 统一下单接口返回的 prepay_id 参数值
  package: '',
  // 签名类型
  signType: '',
  // 签名
  paySign: '',
  // 调用成功回调
  success () {},
  // 失败回调
  fail () {},
  // 接口调用结束回调
  complete () {}
})

参数表如下所示：

三、结束

小程序支付和以往的网页、APP微信支付大同小异，可以说小程序的支付变得更加简洁，不需要设置支付目录、域名授权等操作

实现原理

一、背景

网页开发，渲染线程和脚本是互斥的，这也是为什么长时间的脚本运行可能会导致页面失去响应的原因，本质就是我们常说的 JS 是单线程的

而在小程序中，选择了 Hybrid 的渲染方式，将视图层和逻辑层是分开的，双线程同时运行，视图层的界面使用 WebView 进行渲染，逻辑层运行在 JSCore 中

• 渲染层：界面渲染相关的任务全都在 WebView 线程里执行。一个小程序存在多个界面，所以渲染层存在多个 WebView 线程
• 逻辑层：采用 JsCore 线程运行 JS 脚本，在这个环境下执行的都是有关小程序业务逻辑的代码

二、通信

小程序在渲染层，宿主环境会把wxml转化成对应的JS对象

在逻辑层发生数据变更的时候，通过宿主环境提供的setData方法把数据从逻辑层传递到渲染层，再经过对比前后差异，把差异应用在原来的Dom树上，渲染出正确的视图

当视图存在交互的时候，例如用户点击你界面上某个按钮，这类反馈应该通知给开发者的逻辑层，需要将对应的处理状态呈现给用户

对于事件的分发处理，微信进行了特殊的处理，将所有的事件拦截后，丢到逻辑层交给JavaScript进行处理

由于小程序是基于双线程的，也就是任何在视图层和逻辑层之间的数据传递都是线程间的通信，会有一定的延时，因此在小程序中，页面更新成了异步操作

异步会使得各部分的运行时序变得复杂一些，比如在渲染首屏的时候，逻辑层与渲染层会同时开始初始化工作，但是渲染层需要有逻辑层的数据才能把界面渲染出来

如果渲染层初始化工作较快完成，就要等逻辑层的指令才能进行下一步工作

因此逻辑层与渲染层需要有一定的机制保证时序正确，在每个小程序页面的生命周期中，存在着若干次页面数据通信

三、运行机制

小程序启动运行两种情况：

• 冷启动（重新开始）：用户首次打开或者小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动，即为冷启动
• 热启动：用户已经打开过小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需要将后台态的小程序切换到前台，这个过程就是热启动

需要注意：

1.小程序没有重启的概念
2.当小程序进入后台，客户端会维持一段时间的运行状态，超过一定时间后会被微信主动销毁
3.短时间内收到系统两次以上内存警告，也会对小程序进行销毁，这也就为什么一旦页面内存溢出，页面会奔溃的本质原因了

开发者在后台发布新版本之后，无法立刻影响到所有现网用户，但最差情况下，也在发布之后 24 小时之内下发新版本信息到用户

每次冷启动时，都会检查是否有更新版本，如果发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序需要等下一次冷启动才会应用上

优化手段

一、是什么

小程序启动会常常遇到如下图场景：

这是因为，小程序首次启动前，微信会在小程序启动前为小程序准备好通用的运行环境，如运行中的县城和一些基础库的初始化

然后才开始进入启动状态，展示一个固定的启动界面，界面内包含小程序的图标、名称和加载提示图标。此时，微信会在背后完成几项工作：

• 下载小程序代码包
• 加载小程序代码包
• 初始化小程序首页

下载到的小程序代码包不是小程序的源代码，而是编译、压缩、打包之后的代码包

整体流程如下图：

二、手段

围绕上图小程序的启动流程， 我们可以从加载、渲染两个纬度进行切入：

加载

提升体验最直接的方法是控制小程序包的大小，常见手段有如下：

• 代码包的体积压缩可以通过勾选开发者工具中“上传代码时，压缩代码”选项
• 及时清理无用的代码和资源文件
• 减少资源包中的图片等资源的数量和大小（理论上除了小icon，其他图片资源从网络下载），图片资源压缩率有限

并且可以采取分包加载的操作，将用户访问率高的页面放在主包里，将访问率低的页面放入子包里，按需加载

当用户点击到子包的目录时，还是有一个代码包下载的过程，这会感觉到明显的卡顿，所以子包也不建议拆的太大，当然我们可以采用子包预加载技术，并不需要等到用户点击到子包页面后在下载子包

渲染

关于微信小程序首屏渲染优化的手段如下：

• 请求可以在页面onLoad就加载，不需要等页面ready后在异步请求数据
• 尽量减少不必要的https请求，可使用 getStorageSync() 及 setStorageSync() 方法将数据存储在本地
• 可以在前置页面将一些有用的字段带到当前页，进行首次渲染（列表页的某些数据--> 详情页），没有数据的模块可以进行骨架屏的占位

在微信小程序中，提高页面的多次渲染效率主要在于正确使用setData：

• 不要过于频繁调用setData，应考虑将多次setData合并成一次setData调用
• 数据通信的性能与数据量正相关，因而如果有一些数据字段不在界面中展示且数据结构比较复杂或包含长字符串，则不应使用setData来设置这些数据
• 与界面渲染无关的数据最好不要设置在data中，可以考虑设置在page对象的其他字段下

除此之外，对于一些独立的模块我们尽可能抽离出来，这是因为自定义组件的更新并不会影响页面上其他元素的更新

各个组件也将具有各自独立的逻辑空间。每个组件都分别拥有自己的独立的数据、setData调用

三、总结

小程序启动加载性能：

• 控制代码包的大小
• 分包加载
• 首屏体验（预请求，利用缓存，避免白屏，及时反馈

小程序渲染性能：

• 避免不当的使用setData
• 使用自定义组件