likes
comments
collection
share

「应对微信调整」小程序推送公众号模版消息整改方案

作者站长头像
站长
· 阅读数 10

本文章适合使用小程序 openid 调用微信公众平台下发统一消息接口修改为模版消息的同学阅读

一. 前言

书接上文,本文继续进行对“微信团队调整微信公众号下发统一消息接口”的应对方案探讨,如何尽快的完成适配,以便于我们能正常的使用公众号和小程序的推送消息功能。

关于微信官方团队发出的公告事宜的具体事项,有还未了解的同学可以浏览我之前的文章:

本文将会对之前文章中提到的解决方案之一进行详细的讲解:另一种解决方案:打补丁方案

  1. 必须有一个微信开放平台,使用 unionid 做关联。
  2. 小程序与公众号同一主体。
  3. 小程序和公众号和微信开放平台关联。
  4. 通过 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
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 完成模版消息推送。

本文不对后端的整改方案做过多详细的讲解,只提供修改思路。

四. 总结

虽说这种方式能够快速的解决微信接口变更带来的影响,但是我始终不建议这样做,因为我认为这是野路子实现方案,也许这是一种临时方案,总觉得以后还需要改动。不建议使用这种方案的原因还有以下几点:

  1. 后台获取所有关注公众号的 openid 时间点问题,什么时间获取比较合适?需要轮询获取比对?
  2. 频繁调用微信官方的接口,会不会有限制?
  3. 性能问题,关注人为海量数据时,需要考虑比对的算法性能问题。

不过也有几个好处如下:

  1. 改动小,开发快速。
  2. 用户无感知,体验好,不需要用户重新操作。

综上所述,如果追求快的话就使用这种方式整改;如果寻求标准化流程,还是建议完全整改。

以下是彻底改正的方案,请查阅:

参考资料

微信公告链接

微信开放平台文档