WKWebView 是蘋果在iOS 8中引入的新組件,目的是提供一個現代的支持最新Webkit功能的網頁瀏覽控件,擺脫過去 UIWebView的老、舊、笨,特別是內存占用量巨大的問題。它使用與Safari中一樣的Nitro javaScript引擎,大大提高了頁面js執行速度。
也就是說WKWebview是針對IOS端的手機瀏覽器內核,本來這不關我們什么事兒的,但是問題在于微信iOS客戶端將于2017年3月1日前逐步升級為WKWebview內核,所以此文章的目的是列出WKWebview內核兼容性相關的知識點,以及教大家如何調試發現問題所在,讓微信的這次瀏覽器內核升級能夠最大限度的降低對我們原有項目的影響。
iOS微信6.5.3版本開始支持開發者手動切換WKWebview和UIWebview,使開發者可提前對WKWebview進行適配。
手動切換入口:
在微信會話列表頁點擊右上角“加號按鈕”,選擇菜單中的”添加朋友”,在添加朋友界面的搜索框中輸入字符串:“:switchweb”,再點擊鍵盤右下角搜索按鈕。切換成功后會提示當前使用的內核是UIWebview或是WKWebview。
校驗切換方法:
通過命令成功切換到WKWebview后,可通過以下方法驗證當前網頁使用的是否是WKWebview內核。
微信內任意入口進入任意網頁,在網頁加載成功后向下拉動頁面(或點擊網頁右上角菜單按鈕),使之顯示出地址欄,當地址欄以 “此網頁由” 開頭即為當前使用WKWebview,若以“網頁由”則是使用的UIWebview。
頁面如何判斷當前使用的webview內核:
在頁面中可通過微信注入的window.__wxjs_is_wkwebview變量判斷當前使用的webview內核。 iOS微信6.5.3及其之后的版本 window.__wxjs_is_wkwebview 為true時是使用WKWebview,為 false或者 “undefine”時是 UIWebview 。
以上就是手動切換新內核的方法和檢查新內核的方法,在手機上很簡單就能夠完成。
然后以下便是兼容性方面的重點:一:將不再支持cache
變化:在WKWebview中將暫不支持cache jsapi。
適配建議:所有使用此api的開發者可去掉頁面相關邏輯。
總結:有使用的就必須換掉。因為此內核是直接不支持cache jsapi的。而沒有使用的則不受影響。二:頁面通過LocalID預覽圖片
變化:不再支持通過使用chooseImage api返回的localld以如:”img src=wxLocalResource://50114659201332”的方式預覽圖片。
適配建議:
1. 在iOS微信6.5.3版本及之后的版本中,使用新增的jsapi:getLocalImgData 拿到LocalID對應的圖片base64編碼后再在前端頁面中顯示。
2. 如果引入了頁面有引入JSSDK,則直接將JSSDK升級為1.2.0最新版本即可幫助頁面自動適配。(目前JSSDk線上版本是 1.0.0 和 1.1.0,更新版本為1.2.0 ,https://res.wx.QQ.com/open/js/jweixin-1.2.0.js )
總結:以chooseImage方法預覽圖片的通通改成getLocalImgData方法就可以了,當然系統上有引入jssdk的話升級也可以自動解決。
三:有使用JSSDK,并且使用了wx.config進行權限授權需關注jsapi調用的失敗問題
變化:WKWebview的內部實現變更使我們對微信內的頁面jsapi權限管理做了一定邏輯上的調整,有極小可能會發生以前授權正常的jsapi獲取權限不正常,從而導致調用jsapi失敗。
適配建議:
1. iOS微信6.5.1,WKWebview在此版本中已知有以下問題:頁面使用HTML5的History API pushState; popstate; replaceState等控制頁面導航(典型的如單應用頁面),同時使用JSSDK的wx.config為jsapi授權,此時大幾率會出現jsapi因為無權限而調用失敗的問題。 在6.5.1中頁面若可能的情況下,可使用Anchor hash技術替換History技術來解決此問題。
2. iOS微信6.5.2及其之后版本,將不會存在以上問題,但不能100%確認有使用到 history或hash技術更改頁面導航地址的頁面完全沒有此類問題,依然需要開發者注意關注此類問題。
總結:此問題屬于出現概率很小的事件,如果出現了,要么就叫用戶升級微信版本,要么就放棄使用H5的History API。Cookie和LocalStorage設置相關
一:退出微信賬號后,將會清空所有Cookie和LocalStorage。
二:頁面功能依賴Cookie,或有涉及到Cookie的相關邏輯
變化:WKWebview內部實現變更,會影響目前頁面Cookie相關的邏輯,例如跨域存取Cookie和頁面的資源或圖片存儲服務器依賴校驗Cookie來返回數據等情況。
問題說明:在訪問一個頁面A時,如果頁面A引用了另一個頁面B的資源(頁面A和B為不同的域名),這時頁面B就認為是第三方頁面。若在頁面B中設置Cookie,就會命中WKWebview下阻止第三方跨域設置Cookie的安全策略,導致問題出現。
適配建議:
在WKWebview中是默認阻止跨域的第三方設置Cookie。所有通過Cookie傳遞的信息,可通過業務后臺存儲需要傳遞的信息,然后給頁面一個存儲信息相對應的access_token加密碼,然后通過Url中加入自己業務的access_token進行頁面間信息傳遞。
如果頁面的資源或圖片存儲的服務器依賴校驗Cookie來返回數據的情況,在切換到WKWebview后,在微信內長按保存,或者點擊預覽大圖時,將不會完整的帶上所設置的Cookie,會導致圖片保存失敗或預覽失敗。除了此種情況,開發者不用擔心其他情況下Cookie丟失的問題,所有請求都會帶上完整的Cookie。
總結:退出微信賬號所引發的清空cookie和localstorage是沒有辦法避免的,不用管,知道就好。而引用第三方頁面資源時候,我們就不應該在第三方頁面上設置COOKIE,這樣會導致錯誤而且的確也不安全。凡是這種傳遞參數的方法,都需要修正。
頁面視頻小窗播放
變化:iOS微信6.5.3及其之后的版本中,Webview默認支持小窗播放。
開發者需要特別注意小窗播放需要前端同時適配iOS10和iOS10以下的低版本
適配建議:需要完全按照以下代碼設置video標簽才可同時兼容不同的iOS版本
<video webkit-playsinline playsinline></video>
總結:加就是了,不用懷疑。
一:頁面自定義重載標準方法或者函數時,需要確保不會與微信注入Webview中的JSBridge相關方法沖突,否則會導致頁面在微信中的行為異常。
二:強烈建議不要在無法確保頁面緩存策略和邏輯與服務器邏輯完全保持一致的情況下冒然設置html頁面文件(除了html類型的頁面,頁面引用的其他資源或腳本按照自身業務合理設置即可)相關的Cache-Control屬性。
典型案例:
如果第一次訪問頁面A.html 服務器302跳轉到A1.html?uid=111設置Cache-Control: max-age=60,此A1.html的uid參數是服務器設置的111(此時A1.html已經被客戶端緩存)。 第二次訪問頁面A.html ,服務器同樣302跳轉到A1.html?uid=222,但是此時的A1.html頁面的uid參數是222, 客戶端帶參數完整鏈接詢問服務器緩存是否可用, 服務器返回緩存可用304,但是客戶端緩存的A1.html完整鏈接帶的uid參數是111,所以本地找不到數據,此時加載頁面就會失敗。
總結:問題一基本可以確保,因為自定義的方法和函數沖突的話會報錯,一般都容易排查,問題二則比較難排查,所以不能隨意添加cache-control屬性,這點需要確保。(當然我們常用的是no-cache模式,一般不產生緩存)新聞熱點
疑難解答