iOS開發中webview和native code寫這是一件糾結的事?我寫這篇文章， 介紹一下我做iOS四年來總結的一些在webview和native code的配合上的一些經驗和技巧，當然，都是基于互聯網App的，希望對大家有所幫助。
首先提兩句兩者的優劣?webview的運維成本低， 更新幾乎不依賴App的版本；但在交互和性能上與跟native code有很大差距。native code與之對應。
注 : 我這里不說HTML5，因為我認為，HTML5確實給web帶入了一個新時代。這個時代是什么，web app。也就是說，只有脫離native的這個前提，在瀏覽器的環境下，HTML5的意義才能顯現，而我們討論iOS App的時候，HTML5顯然沒什么意義。
不管是用webview還是native code，我有兩個原則：
- 用戶體驗不打折
- 運維成本低
注，為什么不提開發成本。因為做web開發和iOS開發根本就是兩回事。當然，web開發發展了這么多年，對于某些功能實現是要比native app快。但多數情況，同一個功能，對于iOS開發者和web開發者，用各自擅長的方式開發成本都最低，所以說某個功能開發成本低，往往是一個偽命題。
剛剛說了，webview的優勢在于更新不依賴版本，那么在一款App中，只有會頻繁更新的界面考慮webview才有意義。那么哪些界面會頻繁更新，這就要因App而異了，我只說兩年來，我接觸到的一些。
首頁, 首頁資源可謂必爭之地，內容一天一換是正?，F象，一天幾換也不稀奇。而如果僅僅是內容的更換，非要上個webview就顯得有些激進了。而事實上首頁的變化千奇百怪，逢年過節變個臉，特殊情況掛個公告，偶爾還要特批強推一把某個業務，等等。
此前，我在設計App首頁的時候，把首頁配置設計的非常復雜。App端要處理n種情況，n各參數，server端要記住n種規則，直到一天，我崩潰了，把首頁完全換成webview，才豁然開朗。
活動頁。做互聯網都知道，活動，是一個最常見的運營手段。特點是，周期短，功能少，但基本不能復用。這些特點都標識了活動不適合做native，要用webview實現。
即使有人告訴你說，我的活動是一個長期活動而且形式不變，也不要相信他。因為在第二期，第三期，第四期他會分別加上一些非常詭異，卻有很合理的小變更，而這些變更是你在那個版本根本無法實現的。
試水的新功能。這種界面，往往設計不成熟，需要在運行過程中不斷收集用戶反饋，更新升級，甚至決定去留。所以，只有webview才能hold住如此不穩定的功能。
切記在一個功能還沒有確定之前，不要大張旗鼓單位開發native code，要知道，你寫的這些代碼，三天后就要改一遍，而且要發布上線。
富文本內容。這個不用多說了吧，按照HTML的常用標簽做一個webtext可不是小工程。而且富文本的變化太多了，一點無法匹配，都會導致整個界面巨丑。
OK，上邊說了我認為最該使用webview的4個界面，分別帶有不同的特點，用這些特點去描述一個界面，如果符合了，那么別猶豫了，做成webview吧。說了哪些界面做成webviev，再說說怎么做webview才能避其短處。
剛剛說了，webview的交互是個短板，因此webview在一個App中，只能作為界面，不允許在界面中出現動作。
而一個webview的界面如何跟native code結合起來呢，我的答案是，超鏈接。在webview上點擊超鏈接，會調用webview delegate的shouldload方法，自這里攔截請求，進行處理。
由于webview的鏈接都是URL，因此我建議，把整個App的界面都用URL管理起來。從320框架對VC的管理中獲得靈感，構建一個新的應用，總是先制定一套協議，封裝一個方法，每一次VC的切換都通過URL。如此一來，server與App的交互就簡單了許多，webview也如是。
最后就是長相問題，webview很難長成native的view。而我的方案是，長不成也要裝成。在一些情況下，禁用webview滾動，使用滾動框架（iScroll不錯）去實現。webview上下留出200pixel的空白背景，y從-200開始。否則大家知道，webview上下會有陰影的背景，不藏起來會很丑。等等，還有很多其他的方法去偽裝webview，是要視情景而用。
目前，就想到這些，一定有很多紕漏，只求拋磚引玉，能讓webview在App中發揮優勢，有助于開發者。
