# IOS WKWebview Web Adaptation
WeChat iOS passenger terminal has been upgraded to WKWebView kernel since March 1, 2017, web developers need to do compatibility checks and adaptations in advance.If you have questions, please refer to the contact details at the end of the article for advice.
# background
WKWebView is a new component introduced by Apple in iOS 8 to provide a more modern web browsing control that supports the latest Webkit features, and to address the problems of UIWebView large memory footprint and poor performance.WKWebView uses the same Nitro JavaScript engine as Safari, which greatly speeds up page JS execution.
# Switching Methods
As of iOS version 6.5.3, developers can manually switch between WKWebView and UIWebView for early adaptation.
Manually switch the entrance: On the WeChat session list page, click the "plus button" in the upper right corner, select "Add a friend," enter ": switchweb" in the search box, and click the search button in the lower right corner of the keyboard.When the switch is successful, the kernel in use (UIWebView or WKWebView) is prompted.
Verify the switching method: After switching to WKWebView, enter any web page, and pull down the page (or click the menu button in the upper-right corner) to display the ground bar.WKWebView if the field begins with "From this page";UIWebView for "page by."
How pages judge their kernels:
The current kernel can be determined through thewindow injected by WeChat.__wxjs_is_wkwebview
variable.IOS WeChat 6.5.3 and later,window.__wxjs_is_wkwebview
It is WKWebView when true, UIWebView when false or undefined.
Front-end adaptation concerns: The primary principle of adaptation: If you cannot distinguish whether a new feature WKWebView or an internal logic WeChat causes a page exception, you can test it under the Safari and WeChat WKWebView kernels respectively to quickly locate the problem.
# Adaptation guidelines
After switching to WKWebView, WeChat WebView behavior is highly consistent with Safari, the only difference is that WeChat WebView is injected with JSBridge script.Appropriation focuses on the following:
- Is the page functioning properly?
- Is the page screen alignment correct?
- Is the page behavior normal (e.g. return button logic)
- Page Syntax Compatibility
- JSSDK Is it working properly
- Cookies and LocalStorage related logic
- Server Cache-Control cache logic
In general, no special adaptations are required, but if the following affected logic is involved, please adapt and confirm as recommended.
1. Cache is no longer supported
- Change: WKWebView Cache jsapi is not supported.
- Adaptation advice: remove the relevant page logic.
2. LocalID Preview Image
- Changes: JSSDK The following versions 1.2.0 no longer support localId returned by chooseImage as
img src = wxLocalResource: / /...
Preview image. - Adaptation recommendation: Upgrade JSSDK to 1.2.0 and above, or use the getLocalImgData interface to get data.
JSSDK 1.2.0 Undercarrier address
3. Jsapi call failure problem after wx.config authorization
- Changes: WKWebView internal implementation changes, jsapi weight management logic adjustment, a small probability of normal authorization but jsapi call failure.
- Appropriate advice:
- IOS WeChat 6.5.1: If the page uses HTML5 History API (pushState, popstate, replaceState)With wx.config authorization, it is possible that the JSAPI unauthorized call fails.The Anchor hash technique is recommended to replace the History technique.
- IOS WeChat 6.5.2 and later: The above issue has been fixed, but if the page involves history or hash technology, it is still relevant.
4. Cookies and LocalStorage settings
When you exit your WeChat account, all cookies and LocalStorage will be emptied.Note when pages rely on cookies or related logic:
Change 1: Cross-domain access cookies Problem: Page A refers to page B resources of different domain names, and when B sets cookies, it will be intercepted by WKWebView security policy that prevents third parties from setting cookies across domains.
Adaptation suggestions: Store the information to be passed through the business background, assign access_token to the page, and pass the information through URL.Change 2: WeChat Native network requests cannot read cookies set by WKWebView (even if the domain name is the same) Problem: If the resource or image server relies on cookie validation, after switching WKWebView, the native request will not bring a cookie when long pressing to save or preview a large image, resulting in a failure to save or preview.
Adaptation recommendation: Static resources are recommended to be cookie free.If you need to pass information, it is also passed through background storage and access_token.
With the exception of the above two cases, all requests carry the full cookie, and there is no need to worry about losing the cookie.
5. Page Video window plays
- Changes: iOS WeChat 6.5.3 and later, WebView supports small window playback by default.Developers need to pay special attention to the small window playback needs the front end to adapt to both iOS10 and lower versions of iOS10.
- Recommended adaptation: Compatible with iOS10 and below, the video tag should be set as follows:
<video webkit-playsinline playsinline> </video>
6. WKWebview page behavior is exactly the same as Safari, resulting in a logical failure or exception for pages that depend on UIWebview page behavior
According to the logic of the business itself, the test page can be implemented and verified in Safari and WeChat WKWebview
- Safari or WeChat In WKWebview, page A skipping to page B and returning to page A does not re-execute Script and Ajax (and does not trigger page reload), but it triggers events such as pageshow and pageHide of the page.
- In Safari or WeChat WKWebview, the resize event of JQuery is triggered when the page pops up the input keyboard, but not in UIWebView.
- In Safari or WeChat WKWebview, the window unload event cannot be triggered when only refreshed, exiting the page, or jumping to another page.
- In Safari or WeChat WKWebview, in rare cases, some specially implemented page click events are invalidated.
# Other Questions
- When a page customloads a standard method or function, you need to ensure that it does not conflict with WeChat related methods injected into the WebView, otherwise it will cause the page to behave abnormally in WeChat.
- It is strongly recommended not to set html page files without ensuring that page caching policy and logic are fully aligned with server logic (except for html type pages,The Cache-Control attribute associated with other resources or scripts referenced by the page can be set according to their own business.
- With WKWebView, the method of modifying native titles multiple times through document.title in a single-page application will no longer work, a problem that will be addressed in the WeChat release in March.
- In WKWebView, the form's method = 'post' and target ='_blank 'cause the network request's post data to be lost when submitting.The solution is to determine if it is in WeChat, and the method of the form is' post ', then the target is'_self '.
Typical cases
What if the first visit to the page A.html server 302 jumps to A1.html?Uid = 111 set Cache-Control: max-age = 60. The uid parameter for this A1.html is 111 set by the server (A1.html is already cached by the client at this point).The second visit to the page A.html, the server also 302 jump to A1.html?Uid = 222, but the uid parameter of the A1.html page at this time is 222, and the passenger with the parameter complete link asks if the server cache is available,The server returns a cache available 304, but the uid parameter of the A1.html full link of the guest cache is 111, so the local data cannot be found, and the loading page will fail at this time.