标签 webview 下的文章

善用iOS App中webview

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,是要视情景而用。
目前,就想到这些,一定有很多纰漏,只求抛砖引玉,能让webview在App中发挥优势,有助于开发者。欢迎交流讨论,问题可移步http://segmentfault.com