1️⃣、iOS 平台中 UIWebView 与 WKWebView 有什么区别？
UIWebView特点:
- 加载速度慢；
- 内存占用多，内存优化困难；
- 如果内存占用过多，还可能因为占用过多被系统kill掉。
- UIWebView的内存占用不会在关闭WebView时主动回收，每次新开WebView都会消耗额外内存。
WKWebView的特性：
在性能、稳定性、功能方面有很大提升，内存占用是UIWebView的1/4~1/3；
允许JavaScript的Nitro库加载并使用（UIWebView中限制）；
- 支持了更多的HTML5特性；
- 高达60fps的滚动刷新率以及内置手势；
- 将UIWebViewDelegate与UIWebView重构成了14类与3个协议（详见SDK）；
- ios8以上支持
- 可以和js直接互调函数，不比引入WebViewJavascriptBridge等第三方库
- 不自动注入cookie，需要自己注入
2️⃣、WKWebView 有哪一些坑？
白屏问题：WKWebView之所以有更低的内存占用，是因为它是一个多进程组件，Network Loading 以及 UI Rendering 在其它进程中执行（也就是说使用WKWebView总的内存占用不一定比UIWebView少，只是App Process Memory会减少）。在UIWebView上，当内存占用过大，当前APP会crash，而使用WKWebView，WebContent Process会crash，这个时候就产生了白屏。
Cookie问题：WKWebView会将cookie延迟存储进NSHTTPCookieStorage，但是WKWebView发起的请求不会自动带上NSHTTPCookieStorage中的cookie。
WKWebView 页面样式问题：在 WKWebView 适配过程中，我们发现部分H5页面元素位置向下偏移或被拉伸变形，追踪后发现主要是H5页面高度值异常导致。
视频自动播放：WKWebView 需要通过WKWebViewConfiguration.mediaPlaybackRequiresUserAction设置是否允许自动播放，但一定要在 WKWebView 初始化之前设置，在 WKWebView 初始化之后设置无效
goBack API问题：WKWebView 上调用 -[WKWebView goBack], 回退到上一个页面后不会触发window.onload()函数、不会执行JS。
3️⃣、Crosswalk 是什么，它有什么作用？
Crosswalk是一种 Web 运行时，可替换标准 Android Cordova 应用使用的内置 WebViewapps。 Crosswalk 基于 Google Chromium*，支持 Cordova 插件，相比于 Android 中的默认 WebView，它可显著改进 HTML5 特性支持。目前Crosswalk正式支持的移动操作系统包括Android和Tizen，在Android 4.0及以上的系统中使用Crosswalk的Web应用程序在HTML5方面可以有一致的体验，同时和系统的整合交互方面（比如启动画面、权限管理、应用切换、社交分享等等）可以做到类似原生应用。现在Crosswalk已经成为众多知名HTML5平台和应用的推荐引擎，包括Google Mobile Chrome App、Intel XDK、Famo.us和Construct2等等，未来的Cordova 4.0也计划集成Crosswalk。
1)更出色的 HTML5 支持
相比于默认 Android WebViews，Crosswalk 运行时包含更多目前最新的 HTML5 支持。
2)高级 HTML5 API 支持
Crosswalk 包含 WebGL 与 WebAudio API 支持，有助于游戏开发人员创建沉浸式 3D 游戏，无需学习本机 Android 开发。 Android 4.4 版本以下的默认 Android WebViews 不支持这些 API。
什么时候最适合在 Android 上使用 Crosswalk？
当 HTML5 应用使用默认 Android WebViews 不支持的 HTML5 特性时，最适合使用 Crosswalk 构建选项。它包含的 HTML5 特性有 WebGL、WebRTC、IndexedDB、Web Sockets、CSS3 特性（比如 flexbox）等（这里仅列举一部分）。
如果 HTML5 应用是使用标准框架（比如 Bootstrap* 或 App Framework）的简单应用，那么 Crosswalk 可能无法提供任何有意义的价值，在这种情况下，您可以使用默认的 Android WebView（标准 Android Cordova 构建）。我们建议您在不同制造商提供的 Android 4.0、4.1、4.2、4.3 和 4.4 版本上测试应用，以确保 HTML5 应用能够一致运行。 如果在 Android 上遇到任何 HTML5 特性不一致或丢失，或 CSS3 性能低下等问题，建议您迁移至 Crosswalk 构建设置，以在 Android 上为 HTML5 应用打造一致的、最新的运行时环境。
4️⃣、常见的 WebView 性能优化方案有哪一些？
性能方面：
WebView它能以较低的成本实现Android、iOS和Web的复用，但对于WebView的性能，给人最直观的莫过于：打开速度比native慢。当我们打开一个WebView页面，页面往往会慢吞吞的loading很久，若干秒后才出现你所需要看到的页面。
这是为什么呢？
对于一个普通用户来讲，打开一个WebView通常会经历以下几个阶段：
1.交互无反馈
2.到达新的页面，页面白屏
3.页面基本框架出现，但是没有数据；页面处于loading状态
4.出现所需的数据
从程序上观察，WebView启动过程大概分为以下几个阶段：
当App首次打开时，默认是并不初始化浏览器内核的；只有当创建WebView实例的时候，才会创建WebView的基础框架。
所以与浏览器不同，App中打开WebView的第一步并不是建立连接，而是启动浏览器内核。
由于这段过程发生在native的代码中，单纯靠前端代码是无法优化的；大部分的方案都是前端和客户端协作完成，以下是几个业界采用过的方案：
1）全局WebView：在客户端刚启动时，就初始化一个全局的WebView待用，并隐藏，当用户访问了WebView时，直接使用这个WebView加载对应网页，并展示。
优点：比较有效的减少WebView在App中的首次打开时间。当用户访问页面时，不需要初始化WebView的时间。
缺点：额外的内存消耗。页面间跳转需要清空上一个页面的痕迹，更容易内存泄露。
2）客户端代理数据请求：在客户端初始化WebView的同时，直接由native开始网络请求数据；当页面初始化完成后，向native获取其代理请求的数据。
优点：数据请求和WebView初始化可以并行进行，总体的页面加载时间就缩短了；缩短总体的页面加载时间。
缺点，从代理处获取数据
3）建立连接/服务器处理优化：DNS，connection，服务器处理是主要耗时的过程，优化方案：
DNS采用和客户端API相同的域名
DNS会在系统级别进行缓存，对于WebView的地址，如果使用的域名与native的API相同，则可以直接使用缓存的DNS而不用再发起请求图片。
4）同步渲染采用chunk编码：同步渲染时如果后端请求时间过长，可以考虑采用chunk编码，将数据放在最后，并优先将静态内容flush。对于传统的后端渲染页面，往往都是使用的【浏览器】–> 【Web API】 –> 【业务 API】的加载模式，其中后端时间就指的是Web API的处理时间了。在这里Web API一般有两个作用：
- 确定静态资源的版本。
- 根据用户的请求，去业务API获取数据。
5）页面框架渲染：页面在解析到足够多的节点，且所有CSS都加载完成后进行首屏渲染。在此之前，页面保持白屏；在页面完全下载并解析完成之前，页面处于不完整展示状态。