UIWebView v.s. WKWebView

做浏览器首先要选个好的基础。iOS8提供两类浏览组件：UIWebView和WKWebView。这俩有啥不一样呢？

UIWebView是iOS传统的浏览控件，绝大多数浏览器都采用这个控件作为基础。Chrome，Firefox，Safari都不例外。根据网上说法，UIWebView比较封闭，很多API都不开放，但却一度是唯一的选择。好处是，这个控件使用时间比较长了，有很多方案可以参考。

而WKWebView是苹果在iOS8和 OS X Yosemite 应用中中新推出的WebKit中的一个组件。它代替了 UIKit 中的UIWebView和AppKit中的WebView，提供了统一的跨双平台 API。拥有 60fps 滚动刷新率、内置手势、高效的app和web信息交换通道、和Safari相同的JavaScript引擎。

根据测试，WKWebView拥有比UIWebView更为强大的性能。（具体请见https://www.sencha.com/blog/apple-shows-love-for-html5-with-ios-8/

和http://blog.initlabs.com/post/100113463211/wkwebview-vs-uiwebview）

WKWebview完美么？不见得，毕竟苹果还没将UIWebView放进Depreciate列表里。

网上也可以简单的找到几条缺点：

——There is no cookie management API, which means there is no obvious way to clear/manage cookies（没有控制Cookie的API）

——Protocol handlers no longer work, which breaks several very important features（指针句柄不能用？渣翻译）

——POST bodies are missing from delegate callbacks, which breaks certain aspects of form handling（真的是翻不出来）

(具体请见——为什么Chrome不用WKWebView?

https://code.google.com/p/chromium/issues/detail?id=423444）

此外，WKWebView对读取本地html文件的支持也不好。

（具体请见——WKWebView真让人失望

http://blogging.alastair.is/the-disappointing-reality-of-wkwebview/）

那么，问题来了，这两个该选哪一个？

说到底，这个问题应该是这样的：同一类方案，A方案足以满足现有需求，虽有不少缺点但有大量的解决方案，B方案有不少闪光点，但是缺点也不小，该选哪个？

这个问题到让我想起了2008年。那年，诺基亚如日中天，iPhone不过还是个襁褓中的婴儿。后面的故事大家也都知道了。那么给我们的思考是什么？

至少在我看来，如果A拿不出B那样的亮点，那么当B集中力量解决自己的缺点之后，这个世界就没A什么事儿了。

所以我还是决定选WKWebView，有闪光点的方案总是值得关注的，尤其是那些缺点很容易改正的。