小程序开发的与众不同

距离上次发文已经一年了,我真是个懒惰的人啊!!!

元旦过完了,假也休完了,开始新的一年了,总结一下最近开发小程序的与众不同之处。

1、小程序必须设置合法域名,否则无法发出请求。

官方文档是这么说的:

注意:域名只支持https,不能使用IP或者localhost,域名必须经过ICP备案,每个接口最多设置20个域名。

那么问题来了,我们开发的时候的域名不符合上面的要求啊!怎么办?

在微信开发者工具中有这个:

点击这个双箭头,从详情中

选择不校验合法域名,这时候就可以开发啦。同样,在真机调试时,也需要打开调试模式哦。

2、小程序登录态的管理

通常我们在做网页开发的时候会用cookie来管理登录态,但是小程序没有cookie。小程序官方建议的的登录态管理是这样的:

简单说就是:

(1)前端同学调用微信小程序api:login()拿到code传给后端

(2)后端拿着appid、appsecret和code调微信接口服务返回session_key+openId等,后端自定义登录态返给前端

(3)前端将自定义登录态存储到storage里,每次发请求时候带着

我们遇到的坑:用户切换账号时,由于登录态存储在了storage里,所以即使切换账号拿到的还是之前的用户的登录态,后端根据此登录态认为当前用户还是原来的用户,所以就乱了……

填坑方法: 当用户每次启动时都校验一下登录态是否过期,调小程序api:checkSession。我们在小程序官方文档上并没有找到明确说明若微信切换账号,登录态会过期,但是根据网友的建议和实际测试证明,若切换账号登录态的确会过期,那么过期之后重新问后端请求新的登录态,在请求数据就ok了。

3.小程序更新机制

我们遇到的坑:我们的小程序第一次上线是个全新的,所以不存在更新不更新之说,第二次上线就有了更新问题。第二次上线发布之后,同事们打开小程序发现并不是新版啊!!还是旧版啊!!

更新机制是怎么样呢?

要说更新得先从小程序的运行机制来说,speak is cheap,show doc:

也就是说,当我们发布新版小程序时,用户只有冷启动两次才能使用新版的小程序?what?我不接受……

官方提供解决思路:

1. 同步检查更新(放弃):可能是最直接的解决思路,但主要问题是会影响小程序的启动速度,当下小程序的更新迭代是非常频繁的,部分用户可能每次启动都命中更新,如果需要同步检查更新+同步下载新的版本,那将会影响这部分用户的启动体验。

2. 模块热替换(放弃):从技术上来说,这是最好的方案,小程序运行起来后,在打开新页面时,马上应用新版本里的页面,但这就会存在新旧逻辑、页面共存问题,对于开发者来说,反而更不好处理,特别是涉及到全局变量时,情况会更复杂,对于我们已有的框架来说,也是一个大挑战,不过这个也是我们之后努力的方向。

3. 定时 check 新版本(目前方案):6.6.3 及以上版本的客户端,会定时 check 最近使用过的小程序是否有发布新版本;如果有,下次打开的时候会同步更新新版本再打开。这可以保证在新版本发布 24 小时后,所有小程序都能使用最新版本。(这部分是微信客户端自身优化,开发者无需关心)

4. 异步更新 + 强制更新(目前方案):同步检查更新与模块热替换两者之间的折衷方案,即还是维持异步更新机制,在异步下载完小程序代码包后,提供重启小程序的能力,这样在遇到紧急问题时可以马上解决。

异步更新 + 强制更新方案介绍

从基础库 1.9.90 开始,我们提供了 wx.getUpdateManager 接口,使用该接口,可以获知是否有新版本小程序、新版本是否下载好以及应用新版本的能力。

当小程序冷启动时,会自动向微信后台请求新版本信息,如果有新版本,会马上触发新版本的下载。开发者可以通过 wx.getUpdateManager,获知当前更新的状态。

最佳实践

从用户体验上来说,我们还是建议只在非常必要时才强制用户重启更新,例如出现线上紧急 BUG。通常情况下,可以选通过弹出选择框让用户选择是否重启更新(实现请参考示例代码)。

哎呀,匆忙结尾,若有错误,欢迎指正,3Q

愿我们有能力不向生活缴械投降---Lin

原文发布于微信公众号 - 女程序员的日常(gh_df41d619fb70)

原文发表时间:2019-01-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券