分享程序小卡片的流程如下：
1. 客戶端程序調用微信提供的分享接口，接口參數裏指定分享的文案，以及程序小卡片上要使用的圖片的url。
2. 分享接口的調用會拉起微信。
3. 用戶在微信裏選擇要分享的對象。
4. 微信通過客戶端指定的圖片url發起資源的網絡請求。
5. 相關的資源服務器收到請求後返回相關的圖片資源。
6. 微信獲得圖片資源後，在用戶選擇要分享的對象會話裏會展示一個遊戲的程序小卡片的浮窗，讓用戶進一步確認是否分享。
7. 用戶點擊確認，分享成功。
8. 用戶按下返回鍵返回遊戲領取分享獎勵。
目前微信官方提供給小遊戲開發者的拉起微信分享的接口裏無法知道用戶是否分享了程序小卡片，爲了提升產品的用戶自裂變效益，每一款微信小遊戲內都存在如下功能：
用戶分享遊戲的程序小卡片到微信後可以獲得相關的遊戲獎勵。
由於從微信提供的分享接口無法知道用戶是否真正做了分享操作，所以只要用戶在遊戲中觸發了這個分享接口，不管用戶最後有沒有把程序小卡片分享出去，都只能算分享成功，發放相關的遊戲獎勵。
這種缺陷對於那些資深的微信小遊戲用戶羣體來說，會讓你預期的用戶自裂變效益大大降低，因爲這類用戶玩的微信小遊戲多了就能夠發現這種缺陷，於是每次在遊戲中觸發分享執行到分享流程的步驟3時就跳過4、5、6、7步驟，直接執行步驟8操作。
針對這種情況，雖然我們無法準確判斷玩家是否執行了步驟7，但是可以通過一些手段來提高這種判斷的準確率。
目前最low的辦法就是在觸發分享接口的時候加個定時器，通過從玩家拉起微信分享到返回遊戲的時間間隔來模糊判斷用戶是否進行了分享，例如：設定玩家如果拉起微信分享5秒內就返回了遊戲，那麼就判定玩家沒有完成分享，否則就是分享成功了。
這種套路其實對於那些玩得多玩得久的用戶來說，也很容易發覺裏面的道道，於是在執行到分享流程步驟3時等上幾秒以後再返回遊戲，照樣領獎勵。
這篇要講的解決方案是能把判斷用戶是否分享的準確率提升到用戶的分享流程至少執行到步驟6後回到遊戲才能領獎勵。
提高判斷微信小遊戲用戶是否分享的準確率的解決方案：
爲了減小服務器的開發壓力，我們把遊戲分享的程序小卡片上的圖片資源放在了CDN緩存上，這樣把微信端請求該圖片的訪問壓力就交給了CDN處理。
1. 搭建一臺web服務器，對外提供一個https訪問接口，例如：
https://xxxx.cn/wxshareimg
請求參數的格式爲：openId:xxxxxx&deppendUrl=https://cdnimgurl.cn/xx.jpg
請求協議爲：GET
完整的請求url示例：https://xxxx.cn/wxshareimg?openId:xxxxxx&deppendUrl=https://cdnimgurl.cn/xx.jpg
2. 把分享流程步驟1裏的圖片url改成這臺web服務器對外提供的https訪問接口的url，例如
https://xxxx.cn/wxshareimg?openId:xxxxxx&deppendUrl=https://cdnimgurl.cn/xx.jpg
3. 分享流程步驟4的網絡請求將由web服務器對外提供的https訪問接口來處理，接收到請求後，把請求參數裏的openId取出來，然後在數據庫裏添加一條標識該openId的用戶進行了一次分享的記錄，然後，通過web請求的重定向特性，設置請求header的重定向url爲deppendUrl的值（deppendUrl=https://cdnimgurl.cn/xx.jpg），最後，給微信端返回302狀態（表示本次請求需要重定向）。
4. 微信端收到302狀態後就知道要請求重定向，於是再次請求資源時拿出請求header裏的url（在解決方案步驟3裏設定的重定向url（https://cdnimgurl.cn/xx.jpg））重新發起網絡請求，這時才真正去CDN裏獲取圖片資源。
5. 用戶從微信頁面返回遊戲頁面時，我們再請求自己的web服務器，通過openId來查詢該用戶是否在數據庫裏有標識進行過分享的記錄，如果記錄存在，那麼就給該用戶發放分享成功的獎勵。
如此一來，也就間接提高了判斷微信小遊戲用戶是否分享的準確率。