這幾天在使用小程序的模板消息推送接口的時(shí)候，出現(xiàn)了個(gè)報(bào)錯(cuò)信息 “the formId is no longer available in develop or trial version”，去文檔查看了一下才發(fā)現(xiàn)，模板消息功能在今年1月份已經(jīng)下架了，現(xiàn)在統(tǒng)一都是使用訂閱消息：

那么這兩個(gè)功能有什么區(qū)別呢？

模板消息推送

簡(jiǎn)單地說(shuō)，用戶每進(jìn)行一次提交表單或是支付行為，都會(huì)產(chǎn)生一個(gè) formId，開發(fā)者可以通過(guò)這個(gè) formId 向用戶推送消息。由于下發(fā)權(quán)限是在開發(fā)者這邊，為了防止消息頻繁推送對(duì)用戶造成的騷擾，小程序做出了一個(gè)限制：一個(gè) formId 只有 7 天有效期，每推送一次消息會(huì)消耗一個(gè) formId，也就是說(shuō)，正常情況下，開發(fā)者 7 天內(nèi)可以推送的消息數(shù)量是有限的。這樣當(dāng)然對(duì)用戶是友好的，但是對(duì)開發(fā)者來(lái)說(shuō)，有些業(yè)務(wù)場(chǎng)景又確實(shí)推送多條消息：比如說(shuō) A 用戶發(fā)布一個(gè)二手商品，B 用戶點(diǎn)擊了“感興趣”，需要推送消息告知 A 用戶，同理，C 用戶也點(diǎn)擊了“感興趣”，同樣需要推送消息告知 A 用戶，這種情況下一個(gè) formId 肯定是不夠用的。于是在訂閱消息出現(xiàn)以前，開發(fā)者就使用了一些黑科技來(lái)收集 formId：包括基于事件冒泡的多層嵌套表單，以及在小程序里埋藏大量的點(diǎn)擊事件等，只要用戶點(diǎn)擊了就會(huì)觸發(fā)表單提交，生成新的 formId，然后記錄下有效期存放到數(shù)據(jù)庫(kù)中，方便后續(xù)的使用。

不過(guò)有不少的黑科技已經(jīng)被微信官方修復(fù)了，而且我們會(huì)發(fā)現(xiàn)，最終還是回到了起點(diǎn)，仍然沒有解決用戶受到消息騷擾的問題。微信大概也意識(shí)到了這一點(diǎn)，所以推出了訂閱消息功能。

訂閱消息推送

舉個(gè)訂閱消息的例子：當(dāng)我們參與某個(gè)公眾號(hào)的抽獎(jiǎng)活動(dòng)之后，會(huì)有彈窗提示我們是否接受抽獎(jiǎng)結(jié)果的信息推送，這個(gè)彈窗就屬于訂閱消息功能的授權(quán)環(huán)節(jié)。

從使用體驗(yàn)來(lái)看，訂閱消息推送最大的特征就在于，它對(duì)于用戶和開發(fā)者都是友好的。首先，消息下發(fā)的權(quán)限交還給了用戶，由用戶自己來(lái)決定要不要接受消息推送，不再像之前那樣被動(dòng)接受了；其次，對(duì)于我們開發(fā)者來(lái)說(shuō)，只需要調(diào)用接口詢問用戶是否接受消息推送即可，只要用戶同意，那么我們就可以多次發(fā)送消息，不再需要像以前那樣費(fèi)力去收集 formId 了。

使用

首先登錄微信公眾平臺(tái)，選擇 訂閱消息 —— 我的模板 —— 添加，然后根據(jù)自己的需求選擇一個(gè)模板，配置關(guān)鍵字，提交之后即可獲得模板對(duì)應(yīng)的模板 Id，這個(gè) Id 稍后調(diào)用 api 的時(shí)候會(huì)用到，當(dāng)然，同樣需要用到的還有關(guān)鍵字對(duì)應(yīng)的參數(shù)：

小程序端代碼：

let templateId = 'Ite6-mnfTlONu6rd35AJ-SGQYKQgj1WMvjVj0O5h9kE'
wx.requestSubscribeMessage({
    tmplIds: [templateId],
    success: (res)=> {
        // 如果用戶點(diǎn)擊允許
        if(res[templateId] == 'accept'){
            console.log('點(diǎn)擊了允許')
            wx.cloud.callFunction({
                name:'sendMessage',
                data:{
                    templateId,
                    content: this.data.textContent,
                    blogId: this.properties.blogid,
                }
            }).then(res => {                      
                this.setData({
                    textContent:''
                })
            })
        } else {
            console.log('點(diǎn)擊了取消')
        }
    }
    fail:(res) => {}
}) 

wx.requestSubscribeMessage 這個(gè) api 主要用來(lái)調(diào)起彈窗詢問用戶是否接受消息推送， tmplIds 數(shù)組存放各類模板 Id，因?yàn)殚_發(fā)者可能不止使用了一個(gè)模板。

這里要注意兩個(gè)地方，第一個(gè)是這個(gè) api 只能在點(diǎn)擊事件或者觸發(fā)支付回調(diào)后使用， bindsubmit 表單提交事件是用不了的；第二個(gè)是，不管用戶點(diǎn)擊允許還是拒絕，都會(huì)來(lái)到 success 回調(diào)，fail 回調(diào)是在 api 本身調(diào)用失敗后執(zhí)行的。那么怎么判斷用戶是點(diǎn)擊了允許還是拒絕（取消）呢？如果用戶點(diǎn)擊了允許，那么 res 中模板 Id 鍵對(duì)應(yīng)的鍵值會(huì)是 “accept”（反之則是 “reject”），然后調(diào)用相應(yīng)的云函數(shù)并傳參，進(jìn)行消息推送。

在云函數(shù)中調(diào)用相關(guān) api 之前，要先去云函數(shù)文件夾下的 config.JSON 文件設(shè)置調(diào)用權(quán)限：

{
  "permissions": {
    "openapi": [
      "subscribeMessage.send"
    ]
  }
}

相關(guān)的云函數(shù)：

const cloud = require('wx-server-sdk')
cloud.init()

exports.main = async (event, context) => {
  const {OPENID} = cloud.getWXContext()

  return await cloud.openapi.subscribeMessage.send({
    touser: OPENID,
    page: `/pages/blog-comments/blog-comments?blogId=${event.blogId}`,
    data:{
      thing4:{
        value:'評(píng)價(jià)完成'
      },
      thing1:{
        value: event.content
      }
    },
    templateId: event.templateId
  })
}

主要是用到了 cloud.openapi.subscribeMessage.send() 這個(gè) api，相關(guān)的參數(shù)就根據(jù)自己的實(shí)際情況來(lái)：這里的 OPENID 是消息發(fā)送目標(biāo)的 openid ， page 則是用戶點(diǎn)擊消息后進(jìn)入的頁(yè)面（這里是評(píng)論詳情頁(yè)）， data 就對(duì)應(yīng)我們之前在微信公眾平臺(tái)設(shè)置的模板關(guān)鍵字，當(dāng)然，這里要注意使用此前模板提供的鍵名（ thing4 和 thing1 ），最后還有一個(gè)參數(shù)就是我們的模板 Id 啦。其實(shí)和之前模板消息的用法是差不多的，只不過(guò)我們不再需要傳參 fromId 了。

最后，對(duì)用戶來(lái)說(shuō)，他也可以在彈窗的時(shí)候點(diǎn)擊允許和記住選擇，這樣就是默認(rèn)每次都接受消息推送了，對(duì)應(yīng)的就是默認(rèn)執(zhí)行 wx.requestSubscribeMessage 中的 if 代碼塊。

其實(shí)，不談技術(shù)，單從用戶的角度來(lái)看，這個(gè)功能的調(diào)整其實(shí)是很人性化的，選擇權(quán)確實(shí)本就應(yīng)該掌握在用戶手中，如果用戶沒有權(quán)限拒收不需要的消息，這樣的產(chǎn)品還談什么用戶體驗(yàn)?zāi)?？在查閱相關(guān)資料的時(shí)候，也看到了一篇從產(chǎn)品角度分析的 文章 ，感覺寫得不錯(cuò)，感興趣的可以看一看

參考：

小程序官方文檔