2.4-小程序
小程序
优缺点
优点
- 随搜随用,用完即走:使得小程序可以代替许多 APP,或是做 APP 的整体嫁接,或是作为阉割版功能的承载体
- 流量大,易接受:小程序借助自身平台更加容易引入更多的流量
- 安全
- 开发门槛低
- 降低兼容性限制
缺点:
- 用户留存:及相关数据显示,小程序的平均次日留存在 13% 左右,但是双周留存骤降到仅有 1%
- 体积限制:微信小程序只有 2M 的大小,这样导致无法开发大型一些的小程序
- 受控微信:比起 APP,尤其是安卓版的高自由度,小程序要面对很多来自微信的限制,从功能接口,甚至到类别内容,都要接受微信的管控
生命周期有哪些
应用的生命周期
生命周期 | 说明 |
---|---|
onLaunch | 小程序初始化完成时触发,全局只触发一次 |
onShow | 小程序启动,或从后台进入前台显示时触发 |
onHide | 小程序从前台进入后台时触发 |
onError | 小程序发生脚本错误或 API 调用报错时触发 |
onPageNotFound | 小程序要打开的页面不存在时触发 |
onUnhandledRejection() | 小程序有未处理的 Promise 拒绝时触发 |
onThemeChange | 系统切换主题时触发 |
页面的生命周期
生命周期 | 说明 | 作用 |
---|---|---|
onLoad | 生命周期回调—监听页面加载 | 发送请求获取数据 |
onShow | 生命周期回调—监听页面显示 | 请求数据 |
onReady | 生命周期回调—监听页面初次渲染完成 | 获取页面元素(少用) |
onHide | 生命周期回调—监听页面隐藏 | 终止任务,如定时器或者播放音乐 |
onUnload | 生命周期回调—监听页面卸载 | 终止任务 |
组件的生命周期
生命周期 | 说明 |
---|---|
created | 生命周期回调—监听页面加载 |
attached | 生命周期回调—监听页面显示 |
ready | 生命周期回调—监听页面初次渲染完成 |
moved | 生命周期回调—监听页面隐藏 |
detached | 生命周期回调—监听页面卸载 |
error | 每当组件方法抛出错误时执行 |
注意的是:
- 组件实例刚刚被创建好时, created 生命周期被触发,此时,组件数据
this.data
就是在 Component 构造器中定义的数据 data , 此时不能调用setData
- 在组件完全初始化完毕、进入页面节点树后, attached 生命周期被触发。此时,
this.data
已被初始化为组件的当前值。这个生命周期很有用,绝大多数初始化工作可以在这个时机进行 - 在组件离开页面节点树后, detached 生命周期被触发。退出一个页面时,如果组件还在页面节点树中,则 detached 会被触发
还有一些特殊的生命周期,它们并非与组件有很强的关联,但有时组件需要获知,以便组件内部处理,这样的生命周期称为“组件所在页面的生命周期”,在 pageLifetimes
定义段中定义,如下:
路由跳转的方式有哪些
常见的微信小程序页面跳转方式有如下:
- wx.navigateTo(Object):用于保留当前页面、跳转到应用内的某个页面,使用
wx.navigateBack
可以返回到原页面 - wx.redirectTo(Object):用于关闭当前页面,跳转到应用内的某个页面
- wx.switchTab(Object):跳转到
tabBar
页面,并关闭其他所有非tabBar
页面 - wx.navigateBack(Object):用于关闭当前页面,并返回上一页面或多级页面,开发者可通过
getCurrentPages()
获取当前的页面栈,决定需要返回几层则设置对象的delta
属性即可 - wx.reLaunch(Object):关闭所有页面,打开到应用内的某个页面,返回的时候跳到首页
提高微信小程序的应用速度的手段
小程序首次启动前,微信会在小程序启动前为小程序准备好通用的运行环境,如运行中的线程和一些基础库的初始化。然后才开始进入启动状态,展示一个固定的启动界面,界面内包含小程序的图标、名称和加载提示图标。此时,微信会在背后完成几项工作:
- 下载小程序代码包
- 加载小程序代码包
- 初始化小程序首页
下载到的小程序代码包不是小程序的源代码,而是编译、压缩、打包之后的代码包
加载优化:
- 代码压缩
- 清理无用资源
- 减少资源包中图片等资源数量和大小,仓鼠
- 资源拆分以及子包预加载技术
首屏渲染优化:
- 请求可以在页面 onLoad 就加载,不需要等页面ready后在异步请求数据
- 尽量减少不必要的https请求,可使用 getStorageSync() 及 setStorageSync() 方法将数据存储在本地
- 可以在前置页面将一些有用的字段带到当前页,进行首次渲染(列表页的某些数据--> 详情页),没有数据的模块可以进行骨架屏的占位
在微信小程序中,提高页面的多次渲染效率主要在于正确使用setData
:
- 不要过于频繁调用setData,应考虑将多次setData合并成一次setData调用
- 数据通信的性能与数据量正相关,因而如果有一些数据字段不在界面中展示且数据结构比较复杂或包含长字符串,则不应使用
setData
来设置这些数据 - 与界面渲染无关的数据最好不要设置在data中,可以考虑设置在page对象的其他字段下
小程序的登录流程
传统的web
开发实现登陆功能
- 用户处输入账号密码、或者输入手机号及短信验证码进行登录
- 校验用户信息后,下发一个代表登录态的
token
给客户端,以便进行后续的交互,每当token
过期,用户都需要重新登录
微信中,通过微信官方提供的登录能力方便地获取微信提供的用户身份标识,快速建立小程序内的用户体系,从而实现登陆功能
- 通过
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
检查微信登陆态是否过期
小程序开发流程
关于发布的流程,主要分成了三个部分:
- 上传代码
- 提交审核
- 发布版本
小程序支付流程
- 打开某小程序,点击直接下单
- wx.login 获取用户临时登录凭证code,发送到后端服务器换取 openId
- 在下单时,小程序需要将购买的商品Id,商品数量,以及用户的 openId 传送到服务器
- 服务器在接收到商品 Id、商品数量、openId 后,生成服务期订单数据,同时经过一定的签名算法,向微信支付发送请求,获取预付单信息(prepay_id),同时将获取的数据再次进行相应规则的签名,向小程序端响应必要的信息
- 小程序端在获取对应的参数后,调用wx.requestPayment()发起微信支付,唤醒支付工作台,进行支付
- 接下来的一些列操作都是由用户来操作的包括了微信支付密码,指纹等验证,确认支付之后执行鉴权调起支付
- 鉴权调起支付:在微信后台进行鉴权,微信后台直接返回给前端支付的结果,前端收到返回数据后对支付结果进行展示
- 推送支付结果:微信后台在给前端返回支付的结果后,也会向后台也返回一个支付结果,后台通过这个支付结果来更新订单的状态
小程序实现原理
而在小程序中,选择了 Hybrid
的渲染方式,将视图层和逻辑层是分开的,双线程同时运行,视图层的界面使用 WebView
进行渲染,逻辑层运行在 JSCore
中
- 渲染层:界面渲染相关的任务全都在 WebView 线程里执行。一个小程序存在多个界面,所以渲染层存在多个 WebView 线程
- 逻辑层:采用 JsCore 线程运行 JS 脚本,在这个环境下执行的都是有关小程序业务逻辑的代码
小程序启动运行两种情况:
- 冷启动(重新开始):用户首次打开或者小程序被微信主动销毁后再次打开的情况,此时小程序需要重新加载启动,即为冷启动
- 热启动:用户已经打开过小程序,然后在一定时间内再次打开该小程序,此时无需重新启动,只需要将后台态的小程序切换到前台,这个过程就是热启动