做瀏覽器首先要選個好的基礎(chǔ)。iOS8提供兩類瀏覽組件：UIWebView和WKWebView。這倆有啥不一樣呢？
UIWebView是iOS傳統(tǒng)的瀏覽控件，絕大多數(shù)瀏覽器都采用這個控件作為基礎(chǔ)。Chrome，F(xiàn)irefox，Safari都不例外。根據(jù)網(wǎng)上說法，UIWebView比較封閉，很多API都不開放，但卻一度是唯一的選擇。好處是，這個控件使用時間比較長了，有很多方案可以參考。
而WKWebView是蘋果在iOS8和 OS X Yosemite 應(yīng)用中中新推出的WebKit中的一個組件。它代替了 UIKit 中的UIWebView和AppKit中的WebView，提供了統(tǒng)一的跨雙平臺 API。擁有 60fps 滾動刷新率、內(nèi)置手勢、高效的app和web信息交換通道、和Safari相同的JavaScript引擎。
根據(jù)測試，WKWebView擁有比UIWebView更為強(qiáng)大的性能。（具體請見https://www.sencha.com/blog/apple-shows-love-for-html5-with-ios-8/
和http://blog.initlabs.com/post/100113463211/wkwebview-vs-uiwebview）
WKWebview完美么？不見得，畢竟蘋果還沒將UIWebView放進(jìn)Depreciate列表里。
網(wǎng)上也可以簡單的找到幾條缺點：
——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/）
那么，問題來了，這兩個該選哪一個？
說到底，這個問題應(yīng)該是這樣的：同一類方案，A方案足以滿足現(xiàn)有需求，雖有不少缺點但有大量的解決方案，B方案有不少閃光點，但是缺點也不小，該選哪個？
這個問題到讓我想起了2008年。那年，諾基亞如日中天，iPhone不過還是個襁褓中的嬰兒。后面的故事大家也都知道了。那么給我們的思考是什么？
至少在我看來，如果A拿不出B那樣的亮點，那么當(dāng)B集中力量解決自己的缺點之后，這個世界就沒A什么事兒了。
所以我還是決定選WKWebView，有閃光點的方案總是值得關(guān)注的，尤其是那些缺點很容易改正的。
