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，我有两个原则：
1，用户体验不打折
2，运维成本低
注，为什么不提开发成本。因为做web开发和iOS开发根本就是两回事。当然，web开发发展了这么多年，对于某些功能实现是要比native app快。但多数情况，同一个功能，对于iOS开发者和web开发者，用各自擅长的方式开发成本都最低，所以说某个功能开发成本低，往往是一个伪命题。
刚刚说了，webview的优势在于更新不依赖版本，那么在一款App中，只有会频繁更新的界面考虑webview才有意义。那么哪些界面会频繁更新，这就要因App而异了，我只说两年来，我接触到的一些。
首页。首页资源可谓必争之地，内容一天一换是正常现象，一天几换也不稀奇。而如果仅仅是内容的更换，非要上个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方法，自这里拦截请求，进行处理。这里附上这种方法的说明，此前的一文：http://pingguohe.net/2011/06/25/webview_to_nativeview/
由于webview的链接都是URL，因此我建议，把整个App的界面都用URL管理起来。从320框架对VC的管理中获得灵感，构建一个新的应用，总是先制定一套协议，封装一个方法，每一次VC的切换都通过URL。如此一来，server与App的交互就简单了许多，webview也如是。
最后就是长相问题，webview很难长成native的view。而我的方案是，长不成也要装成。在一些情况下，禁用webview滚动，使用滚动框架（iScroll不错）去实现。webview上下留出200pixel的空白背景，y从-200开始。否则大家知道，webview上下会有阴影的背景，不藏起来会很丑。等等，还有很多其他的方法去伪装webview，是要视情景而用。
原文链接：http://pingguohe.net/2012/06/01/use_webview_in_ios_app/