踩坑---一個不是坑的難以言喻的坑，有關企業微信在iOS端上傳文件的坑

原由

今早一去公司，被組長遠程發過來一個Bug，聽說是用戶反饋的一個iOS的問題，在咱們的業務中，有一個有關圖片上傳的問題。咱們的業務代碼是在本身的客戶端、微信、釘釘、企業微信四個地方跑的同一套代碼。

Bug描述

Bug的具體描述是企業微信用戶在使用上傳圖片時，無反應。可是在安卓下運行正常。在其餘平臺運行正常。
找測試復現該問題時，發如今安卓平臺下一切正常，可是在iOS端測試發現，在iOS8上運行正常，在iOS9往上的系統中，會彈出一個報錯

a.oldWXObj.invoke not a function

解決過程

1. 由於是在iOS端有問題，因此我初步懷疑是由於咱們本身對企業微信的相關SDK進行二次封裝的時候出現了問題，因此我在本身的業務代碼中找到了調用wx.chooseImage的地方，而後console出相關的opts參數

wx.chooseImage(opts);//這是咱們本身的調用

wx.chooseImage({
    count: 1, // 默認9
    sizeType: ['original', 'compressed'], // 能夠指定是原圖仍是壓縮圖，默認兩者都有
    sourceType: ['album', 'camera'], // 能夠指定來源是相冊仍是相機，默認兩者都有
    defaultCameraMode: "batch", //表示進入拍照界面的默認模式，目前有normal與batch兩種選擇，normal表示普通單拍模式，batch表示連拍模式，不傳該參數則爲normal模式。（注：用戶進入拍照界面仍然可自由切換兩種模式）
    success: function (res) {
        var localIds = res.localIds; // 返回選定照片的本地ID列表，
                // andriod中localId能夠做爲img標籤的src屬性顯示圖片；
                // 而在IOS中需經過上面的接口getLocalImgData獲取圖片base64數據，從而用於img標籤的顯示
    }
});

發現opts沒有問題，而後開始查看企業微信的開發文檔，發現了這樣一段話

此接口在企業微信2.3及之後版本支持相機連拍（當sourceType是camera時）
參數defaultCameraMode僅在企業微信2.4.20及之後版本支持
從2.4.6版本開始，IOS版企業微信瀏覽器將升級爲WkWebView，因其不支持原有的直接經過localid做爲img標籤的src屬性來顯示圖片的方式。開發者須要採用經過getLocalImgData來獲取localid對應圖片的base64數據。

看到了iOS，看到了有關圖片上傳，便覺得是這裏的問題，而後便開始對localid 進行修改，改着改着發現，不對啊，是調用的時候就報錯了，並非由於在callback裏面的問題啊。

1. 而後把wx.chooseImage進行alert，發現這個函數是存在的，可是發現仍是有問題，代碼大概是這樣的

a.oldWXObj.invoke("chooseImage",params，callback)

而後我一直在想這個a.oldWXObj是什麼東東，看源碼，並無找到這個東西，而後查看咱們的sdk版本是1.0.0，最新的sdk版本是1.2.0。覺得是由於sdk版本的緣由，而後把項目中的sdk升級，問題仍是存在，看來不是sdk的緣由，繼續探索。

1. 後來沒有思路，去請教大佬，大佬給了個思路，在企業微信中開啓一個別的第三方的業務，看看他們的圖片上傳是否也存在相同的問題，OK，照着這個思路往下繼續。我去，第三方的圖片上傳是沒有問題的，OK，那麼確定是咱們本身的業務代碼的問題，而後把業務剝離出來，在新建兩個文件，一個採用咱們本身封裝的sdk，一個不用本身封裝事後的sdk，直接調用wx的sdk，而後我把相關的wx.config給 複製 了過去，發現圖片上傳仍是有問題，而後考慮是否是免登沒有經過呢？ 試着調用其餘的方法，發現獲取當前位置、掃描二維碼、開始錄音這三個方法均可以成功調用，肯定免登是經過了的，不是免登的問題。
2. 大佬說換個思路，用Charles開始抓包查看第三方的實現，這一部分纔是寫這個 踩坑記錄的重點 ，主要是看這個調試的過程，最開始用Mac自帶的Safari嘗試調試，發現企業微信並無把調試開放出來，只能經過抓包來一點點嘗試了，OK，在簡書上搜索Charles抓包，按照步驟，發現第三方是https，而後再萬能的簡書，抓包https，一切完成後。發現第三方也是調用的wx.chooseImage，那麼說明咱們調用的業務代碼沒問題啊，而後經過這種方式，用本地文件代替線上的文件進行調試，把咱們的相關業務代碼代替第三方的相關代碼，發現咱們的代碼在第三方的應用裏面是正常運行的。我去！！！這就奇怪了呀，這時，一天的時間不知不覺都過去了，尚未解決問題，心中真的是，一言難盡！！！
3. 最後，開始從頭梳理代碼，從第三方最開始調用企業微信的sdk開始一點點對比，把咱們的相關信息跑在第三方平臺裏，來，把wx.config粘貼過來、貼過來、過來、來......咦，這個config有一點不同誒！！！

//咱們本身的配置
wx.config({
    debug: false, 
    appId: '', // 必填，企業微信的corpID
    timestamp: , // 必填，生成簽名的時間戳
    nonceStr: '', // 必填，生成簽名的隨機串
    signature: '',// 必填，簽名，見附錄1
    jsApiList: [] // 必填，須要使用的JS接口列表，全部JS接口列表見附錄2
});


//文檔標準的配置
wx.config({
    beta: true,// 必須這麼寫，不然wx.invoke調用形式的jsapi會有問題
    debug: true, // 開啓調試模式,調用的全部api的返回值會在客戶端alert出來，若要查看傳入的參數，能夠在pc端打開，參數信息會經過log打出，僅在pc端時纔會打印。
    appId: '', // 必填，企業微信的corpID
    timestamp: , // 必填，生成簽名的時間戳
    nonceStr: '', // 必填，生成簽名的隨機串
    signature: '',// 必填，簽名，見附錄1
    jsApiList: [] // 必填，須要使用的JS接口列表，全部JS接口列表見附錄2
});

 忽然發現咱們的代碼配置裏面，沒有beta這個配置，加上，試一下，😌😌😌，心情非常複雜，代碼此次終於正常調起來了。
OK，到這裏，問題解決。

結論

此次不是踩坑的大坑，總結出3點：

1. 配置一旦配好後，再沒動過，因此不會想到是配置的問題，直接就奔着調用的方法去了。下一次，代碼仍是要記得從頭捋！！！
2. 企業微信對前一版本的相關配置兼容有坑！！！
3. 學會了用第三方的代碼來檢測本身的業務代碼，用本地代碼替換線上代碼進行運行調試。
4. 多學多作多看，大佬就是大佬，爭取本身早日成爲大佬。😌😌😌