UIWebView & WKWebView

1. UIWebView VS WKWebView

• 稳定性:

  UIWebView较多的WebCore、JavaScriptCore Crash，以及系统性的内存泄露导致OOM，对整个App的稳定性都是极大的隐患。反观WKWebView，基于独立进程，不会占用App的内存计算，同时也不会导致主App Crash。所以在系统级的稳定性上，WKWebView有着极大的优势。

• 加载速度:

  WKWebView通过JIT大幅优化了JS的执行速度，但是对于新闻类App内容页的使用场景来说，简单的进入、退出页面，且单纯的加载渲染HTML字符串，WKWebView比UIWebView慢了很多（Benchmark）。

• 兼容性:

  NSURLProtocol的无法使用、长按MenuItems Bug（before iOS11）、iOS8不能删除Cache、设置Cookies及UA、POST参数、异步执行JS…这一系列的问题，成为了稳定项目替换WKWebView最大的挑战。

• 扩展性:

  WKWebView具有更加丰富的接口、更多HTML和CSS的支持、以及更加友好的JS交互。同时Api的持续更新和社区的活跃，从长远使用的角度看有着极大的优势。

2. 修复、扩展WKWebView

通过以上的分析，WkWebView从系统级的稳定性、性能以及后续扩展性都有很大的优势。通过WKWebViewExtension扩展修复原生WKWebView，结合HybridPageKit中WKWebView的回收复用逻辑，极大程度上解决了原生WKWebView的问题，起到了很好的效果。

• 修复扩展的问题:

  通过逐阶段分析耗时，在内容页的使用场景下，WKWebView从alloc到准备开始渲染这段时间，有着极大的优化空间。在浏览内容页这种场景下，HybridPageKit中通过WKWebView的复用回收以及资源缓存，极大降低了WKWebView加载渲染HTML的时间，使之低于原生UIWebView。

  通过私有方法的扩展和代码优化，在WKWebViewExtension中支持了URLProtocol、修复了MenuItems的bug、支持iOS8清理缓存、扩展安全的JS执行方法、以及扩展NavigationDelegate以兼容JSBridge逻辑等。

• 无需解决的问题:

  对于新闻类App内容页的使用场景，一些WKWebView的问题并没有必要形成通用的解决方案以兼容代码。比如POST请求不能带参数、Javascript异步执行等问题，都可以通过代码的重构来进行解决。尤其不推荐卡主Runloop从而同步JS的方式。

• 遗留问题:

  目前，在使用WKWebView的过程中，唯一未解决的问题就是可靠、全面的白屏检测方案，从而支持WKWebView在任何情况下的Crash进行重载。诸如系统Crash回调、WebView Title监听、ContentSize监听、甚至屏幕随机取色值等方法都不能满足全部的白屏场景。