微信js-sdk集成小結

完整的官方文檔在此：

https://mp.weixin.qq.com/wiki/7/aaa137b55fb2e0456bf8dd9148dd613f.html

之前有些第三方開發的js庫，確定是不要再用了。

• 公衆號後臺配置
  這個js-sdk的使用,是必須依附於一個公衆號的,要想配置成功,首先公衆號後臺得把頁面所需的域名配進來(官方文檔裏有), 注意配置的時候, 要把一個認證文件放在該域名指向的服務器,這個文件就在配置頁面上下載
  
• 簽名的生成
  看似複雜，實際上是描述最清晰，實現最簡單的，主要就是如下幾個步驟：
• • 根據appid獲取Token
  • 根據token獲取JsTicket
  • 根據JsTicket, 加上客戶端傳過來的隨機字符串(這個真是隨便生成一個就能夠,寫死的也不要緊,只要和前端用的同樣就行)、時間戳和url（必須是前端頁面的完整url地址，這是個大坑，後面會說），用SHA1算法加密生成signature（也就是簽名）
    注意：Token和Ticket須要緩存，不能每次都去微信服務器取，會被拒絕的，因此本身記錄一下每次來取的時間戳，比較一下， 只要不超過7200秒就能夠
    代碼片斷在此: https://git.oschina.net/songhui/codes/kmanqvby4xz05e2hpwl1r15/widget
     
• 頁面調試
  這裏滿滿的都是坑呀，其實一開始本身寫個測試頁面，很容易就經過了，後來僅僅是把js代碼從html中提取到一個獨立js文件中，用微信官方的調試工具，居然怎麼都通不過，每次都報

  config:invalid url domain

  
  上網處處查，都說是公衆號後臺域名配置不對，可我明明放在html文件中是能夠的呀!!! 後來終於發現, 這竟然是"微信web開發者工具"的bug, bug, bug...  一樣的頁面在手機端的微信裏好好的.
  
  以致於到了後來，我看見invalid url domain都很開心，這表示調試成功了。。。
   
• 關於url encode
  用到url有兩個地方：給本身的後臺發請求，獲取簽名的時候用一次，調用wx.onMenuShareAppMessaged 的時候用一次，獲取簽名的地址，要和頁面自身地址徹底一致，若是頁面地址簡單，是沒有任何問題的，若是地址複雜，保護一些"/"之類的特殊字符，就須要encodeURI方法來編碼，但恰恰咱們的地址很是複雜，帶一個子url的參數，這個參數裏面還有參數，大概是這個樣子：
  
  http://www.nijilijil.com/llll/url_detail.html?url=http%25253A%25252F%25252Fwww.nijilijil.com%25252Fllll%25252Fpicture_detail.html&id=1613&from=singlemessage
  
  （最後的from=singlemessage是微信轉發的時候加的）用在簽名方法裏，後端會把&id=後面的當成整個url的參數捨去，這樣生成的簽名就不對了。
  
  爲了解決這個問題，用了一個比較ugly的辦法：把這個url再編碼一次，把後面的&編碼爲特殊字符串"_AND_"，後端再解碼回來
   
• 關於調用順序
  官方文檔裏只給出了不一樣API的說明，沒有完整的例子，網上的例子一般是這樣的：

     

  wx.config({
  
         debug: false,
  
         appId: '1111111111111',// 必填，公衆號的惟一標識
  
         timestamp: timestamp,// 必填，生成簽名的時間戳
  
         nonceStr: nonce,// 必填，生成簽名的隨機串
  
         signature: signature,// 必填，簽名，
  
         jsApiList: [
  
            'onMenuShareAppMessage',
  
            'onMenuShareQQ',
  
            'onMenuShareWeibo',
  
            'onMenuShareQZone'
  
      ]});
  
      wx.error(function(res){
  
          console.log('出現一個問題:'+res.errorMessage);
  
      });
  
      wx.ready(function(){
  
          console.log('wx準備就緒');
      } 
      var shareConfig = {
  
          title: title, // 分享標題
  
          desc: descr, // 分享描述
  
           link: curl,
  
          imgUrl: image, // 分享圖標
  
          type: 'link', // 分享類型,music、video或link，不填默認爲link
  
          success: function () {
  
                   console.log('onMenuShareAppMessage ok');
  
              },
  
              cancel: function () {
  
                   console.log('onMenuShareAppMessage cancel');
  
              }
  
      };
  
      wx.onMenuShareAppMessage(shareConfig);

  
  config, ready, onMenuShareAppMessage幾個屬性順序設置，其實這是有問題的，特別是在手機端，執行比較慢的時候，極可能onMenuShareAppMessage已經設置了， wx.ready尚未被執行，這時設置就失敗了，並且沒有任何錯誤信息。正確的作法是把onMenuShareAppMessage調用放在ready方法裏面：

     

  var shareConfig = {
  
          title: title, // 分享標題
  
          desc: descr, // 分享描述
  
           link: curl,
  
          imgUrl: image, // 分享圖標
  
          type: 'link', // 分享類型,music、video或link，不填默認爲link
  
          success: function () {
  
                   console.log('onMenuShareAppMessage ok');
  
              },
  
              cancel: function () {
  
                   console.log('onMenuShareAppMessage cancel');
  
              }
  
      };
  
      wx.onMenuShareAppMessage(shareConfig);

   

• iframe的處理
  因爲咱們的頁面是一個通用父頁面經過iframe容器嵌入子頁面，分享的時候，固然但願不一樣的子頁面標題和題圖都不一樣，這時就須要再iframe加載完成後，再獲取子頁面信息，大體是這樣處理的：

  iframe.onload = function(){
  
       console.log("iframe load!");
  
       if(browser.versions.weixin){
  
          shareConfig(iframe.contentWindow.document.title ,iframe.contentWindow.document.title ,iframe.contentDocument.getElementById('share_img_url').innerHTML );
  
       }
  
  };

  
  其中share_img_url是子頁面中爲了分享專門設計的標籤
   
• 微信的緩存 微信緩存是個超級坑，網上也不少說法介紹如何清緩存，都不必定靠譜，包括: * 使用系統自帶設置->應用設置->微信->清除緩存功能 * 退出公衆號再從新加 * 卸載微信從新安裝(這也太兇殘了) 然而,微信給人的感受是: 你又千條妙計,我又必定之規，至於規則究竟是什麼，對不起，無可奉告！因此有時同一個頁面，第二次打開就已經刷新緩存了；有時任你怎麼清緩存，退出公衆號都無效，卸載微信沒試，我怕卸了之後不再想裝了。根據經驗，清緩存有80%的機率會生效。 鄙視微信，面向開發者的時候，徹底沒有面向用戶的易用性體驗，這種感受很像之前的微軟：windows，office都很好用，但你要是敢用微軟產品搭建企業級服務，保證死的很慘。