---

微信2017.1.6日推送一條音訊：
微信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預覽圖片

變化：不再支持經過運用chooseImage api前往的localld以如：”img src=wxLocalResource://50114659201332”的方式預覽圖片。

適配建議：

在iOS微信6.5.3版本及之後的版本中，運用新增的jsapi：getLocalImgData 拿到LocalID對應的圖片base64編碼後再在前端頁面中顯示。

假如引入了頁面有引入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 ）

三：有運用JSSDK，並且運用了wx.config停止權限受權需關注jsapi調用的失敗問題

變化：WKWebview的外部完成變卦使我們對微信內的頁面jsapi權限管理做了一定邏輯上的調整，有極小能夠會發作以前受權正常的jsapi獲取權限不正常，從而招致調用jsapi失敗。

適配建議：

iOS微信6.5.1，WKWebview在此版本中已知有以下問題：頁面運用html5的History API pushState; popstate; replaceState等控制頁面導航（典型的如單使用頁面），同時運用JSSDK的wx.config為jsapi受權，此時大幾率會呈現jsapi由於無權限而調用失敗的問題。 在6.5.1中頁面若能夠的狀況下，可運用Anchor hash技術交換History技術來處理此問題。

iOS微信6.5.2及其之後版本，將不會存在以上問題，但不能100%確認有運用到 history或hash技術更改頁面導航地址的頁面完全沒有此類問題，仍然需求開發者留意關注此類問題。

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。

頁面視頻小窗播放

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

開發者需求特別留意小窗播放需求前端同時適配iOS10和iOS10以下的低版本

適配建議：需求完全依照以下代碼設置video標簽才可同時兼容不同的iOS版本

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，所以本地找不到數據，此時加載頁面就會失敗。

【微信iOS WKWebview 網頁開發適配指南】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！