iOS WKWebview 網頁開發適配指南【轉】

微信iOS客戶端將於2017年3月1日前逐步升級爲WKWebview內核，須要網頁開發者提早作好網站的兼容檢查和適配。若有問題，可參考文末聯繫方式，向咱們諮詢。

背景

WKWebView 是蘋果在iOS 8中引入的新組件，目的是提供一個現代的支持最新Webkit功能的網頁瀏覽控件，擺脫過去 UIWebView的老、舊、笨，特別是內存佔用量巨大的問題。它使用與Safari中同樣的Nitro JavaScript引擎，大大提升了頁面js執行速度。

切換方法

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 。

前端適配關注的要點

適配的首要原則：若不能區分是WKWebview的新特性新行爲仍是微信內部邏輯致使原有頁面出現問題時，可以使用測試頁面分別在Safari和微信中的WKWebview內核分別測試，用以快速定位問題產生的緣由。

適配指南

切換爲WKWebview後，微信中的Webview行爲和Safari中保持高度一致，惟一的區別是微信Webview中會注入微信JSBridge相關的腳本。因此適配的重點須要關注如下幾個方面： 

一：頁面功能是否正常 

二：頁面屏幕適配是否正常 三：頁面行爲是否正常（例如用戶在瀏覽頁面時點擊返回按鈕返回上一個頁面時的頁面邏輯是否正常） 

四：頁面使用的語法是否兼容。 

五：JSSAPI是否正常完美的工做。 

六：重點關注Cookie和LocalStorage等相關的邏輯是否正常。 

七：若服務器有設置返回 Cache-Control緩存有效時間，則須要檢查相關邏輯是否正常。

 

正常狀況下，你的頁面是不須要作特別的適配，但若你的頁面有涉及到如下幾個受影響的邏輯，則須要根據適配建議進行適配和確認。

 

JSAPI相關適配

一：將再也不支持cache 

變化：在WKWebview中將暫不支持cache jsapi。 

適配建議：全部使用此api的開發者可去掉頁面相關邏輯。

 

二：頁面經過LocalID預覽圖片 

變化：1.2.0如下版本的JSSDK再也不支持經過使用chooseImage api返回的localld以如：」img src=wxLocalResource://50114659201332」的方式預覽圖片。 

適配建議：直接將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  ）

 

三：有使用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技術更改頁面導航地址的頁面徹底沒有此類問題，依然須要開發者注意關注此類問題。

 

Cookie和LocalStorage設置相關

一：退出微信帳號後，將會清空全部Cookie和LocalStorage。

 

二：頁面功能依賴Cookie，或有涉及到Cookie的相關邏輯 
WKWebview內部實現變動，會影響目前頁面Cookie相關的邏輯。

變化1：跨域存取Cookie
問題說明：在訪問一個頁面A時，若是頁面A引用了另外一個頁面B的資源（頁面A和B爲不一樣的域名），這時頁面B就被認爲是第三方頁面。若在頁面B中設置Cookie，就會命中WKWebview下阻止第三方跨域設置Cookie的安全策略，致使問題出現。
適配建議：
在WKWebview中是默認阻止跨域的第三方設置Cookie。全部經過Cookie傳遞的信息，可經過業務後臺存儲須要傳遞的信息，而後給頁面一個存儲信息相對應的access_token加密碼，再經過Url中加入本身業務的access_token進行頁面間的信息傳遞。

變化2：微信原生層面的網絡請求讀取不到WKWebview中設置的cookie，即便域名是相同的。
問題說明：若是頁面的資源或圖片存儲的服務器依賴校驗Cookie來返回數據的狀況，在切換到WKWebview後，在微信內長按保存，或者點擊預覽大圖時，原生層面發起的網絡請求將不會完整地帶上所設置的Cookie，會致使圖片保存失敗或預覽失敗。
適配建議：
建議靜態資源cookie free。若是確實有信息須要傳遞，可經過業務後臺存儲須要傳遞的信息，而後給頁面一個存儲信息相對應的access_token加密碼，再經過Url中加入本身業務的access_token進行頁面間信息傳遞。

除上述兩種狀況，開發者不用擔憂其餘狀況下Cookie丟失的問題，全部請求都會帶上完整的Cookie。

 

頁面視頻小窗播放

變化：iOS微信6.5.3及其以後的版本中，Webview默認支持小窗播放。 

開發者須要特別注意小窗播放須要前端同時適配iOS10和iOS10如下的低版本 

適配建議：須要徹底按照如下代碼設置video標籤纔可同時兼容不一樣的iOS版本

<video webkit-playsinline playsinline> </video>

 

WKWebview頁面行爲與Safari徹底一致，會致使頁面依賴UIWebview頁面行爲的邏輯失效或異常：（可根據業務自身邏輯，實現測試頁面後分別在Safari和微信WKWebview中驗證）

一：Safari或微信WKWebview中 頁面A跳轉到頁面B再返回頁面A後不會從新執行Script和Ajax(也不會觸發頁面reload)。 

二：Safari或微信WKWebview中，在頁面彈出輸入鍵盤後，會觸發JQuery的resize事件，而在UIWebView下不會。 

三：Safari或微信WKWebview中， window unload 事件在只有刷新才能觸發，退出頁面或者跳轉到其餘頁面都沒法觸發。 

四：Safari或微信WKWebview中，極少數狀況下某些特殊實現的頁面點擊事件會失效。

若是有涉及或者遇到以上問題，以兼容Safari行爲爲準。

其餘問題

一：頁面自定義重載標準方法或者函數時，須要確保不會與微信注入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，因此本地找不到數據，此時加載頁面就會失敗。

 

聯繫咱們

若是在適配過程當中有任何問題，能夠發送郵件到 wx_wkwebview@qq.com 。請提供詳細問題說明 ，強烈建議附上問題頁面的連接，並告知如何復現大家的問題。