本文章适合使用小程序 openid 调用微信公众平台下发统一消息接口修改为模版消息的同学阅读
一. 前言
书接上文,本文继续进行对"微信团队调整微信公众号下发统一消息接口"的应对方案探讨,如何尽快的完成适配,以便于我们能正常的使用公众号和小程序的推送消息功能。
关于微信官方团队发出的公告事宜的具体事项,有还未了解的同学可以浏览我之前的文章:
解决方案思路引导:突发!如何应对微信小程序与公众号下发统一消息接口调整
本文将会对之前文章中提到的解决方案之一进行详细的讲解:另一种解决方案:打补丁方案
- 必须有一个微信开放平台,使用 unionid 做关联。
- 小程序与公众号同一主体。
- 小程序和公众号和微信开放平台关联。
- 通过 unionid 使 小程序 openid 和公众号 openid 关联起来,实现公众号模版推送。
注意:这个方案真的是退退退而求其次的方案,如果是老项目,不想重新开发一套认证系统,可以使用这种方案改一下。如果是新开发的项目,不要使用这种方案。
二. 开发前准备
1. 申请微信开放平台
进入微信平台官网,点击注册,按照指引进行完成注册并认证。
微信开放平台官网:https://open.weixin.qq.com/
2. 申请微信公众号、小程序
本文在这里不做重复的讲解,参考上一篇文章指引完成注册:
3. 关联绑定
在微信开放平台绑定微信公众号和小程序,这样在获取 openid 的时候会多获取一个参数 unionid,这个 unionid 就是连接公众号和小程序的桥梁,通过小程序 openid 和 unionid 可以获取到公众号的 openid。
说到这里,不太长开发微信应用的同学是不是会有点懵,怎么这么多 id,那么接下来我们先认识一下微信平台的这些 id 的具体含义吧。
4. 微信的几个ID说明
-
AppID:AppID是不同类型的产品的账号ID,是账号的唯一标识符。
- 例如:公众号的AppID、小程序的AppID、开放平台的AppID、第三方平台的AppID、移动应用的AppID、网站应用的AppID、小商店的AppID等等。
-
openid:openid 是微信用户在不同类型的产品的身份ID
- 微信用户访问公众号、小程序、移动应用、网站应用、小商店等都会有唯一的openid,但同一个微信用户访问不同的产品生成的openid也是不一样的。
- 例如,对于不同公众号,同一用户的openid不同;同理,对于不同的小程序,同一用户的openid也是不同的。
-
unionid:unionid是微信用户在同一个开放平台下的产品的身份ID
- 如果开发者拥有多个移动应用、网站应用、和公众账号(即公众号和小程序),可通过 UnionID 来区分用户的唯一性,因为只要是同一个微信开放平台账号下的移动应用、网站应用和公众账号,用户的 UnionID 是唯一的。即,同一用户,对同一个微信开放平台下的不同应用,UnionID是相同的。
总结上面的,简言之就是:
-
AppID:是产品的身份证,是唯一标识。
-
openid:用户在产品使用时产生的唯一身份标识,遵循两同原则,同一用户使用同一产品,openid 相同。其中有一个不同,openid 则不同。
-
unionid:用户在开放平台下的身份标识,同一个开放平台下绑定的公众号、小程序、移动应用、网站应用等,获取到的 unionid 都是一样的。
上面的总结一下,你是不是就舒服多了,豁然明朗了。
三. 进入开发
其实这种方案,对于前端来说,要修改的地方特别少
1. 前端修改
前端运行流程图
- 调用微信小程序登录接口,获取到 code
js
wx.login({
success (res) {
if (res.code) {
// 获取到code = res.code
// 通过 code 发起网络请求换取 openid 和 unionid
} else {
console.log('登录失败!' + res.errMsg)
}
}
})
- 根据 code 换取小程序 openid 和 unionid
- 将小程序 openid 和 unionid 存储在后端
完成上面的操作,基本上前端就整改完毕了,剩下的就是后端来修改了。
2. 后端修改
后端运行流程图
- 首先获取到小程序 openid 和 unionid。
- 获取到所有关注微信公众号的关注人列表,拿到对应的关注人的 公众号 openid 和 unionid。
- 根据第一步获取到的 unionid 对比后拿到公众号 openid。
- 使用公众号 openid 完成模版消息推送。
本文不对后端的整改方案做过多详细的讲解,只提供修改思路。
四. 总结
虽说这种方式能够快速的解决微信接口变更带来的影响,但是我始终不建议这样做,因为我认为这是野路子实现方案,也许这是一种临时方案,总觉得以后还需要改动。不建议使用这种方案的原因还有以下几点:
- 后台获取所有关注公众号的 openid 时间点问题,什么时间获取比较合适?需要轮询获取比对?
- 频繁调用微信官方的接口,会不会有限制?
- 性能问题,关注人为海量数据时,需要考虑比对的算法性能问题。
不过也有几个好处如下:
- 改动小,开发快速。
- 用户无感知,体验好,不需要用户重新操作。
综上所述,如果追求快的话就使用这种方式整改;如果寻求标准化流程,还是建议完全整改。