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监听、甚至屏幕随机取色值等方法都不能满足全部的白屏场景。