【引言】

Hybrid App，一种开发模式，兼顾Web和Native的一种开发模式。有人说它把Web App扼杀在摇篮里，有人说它把Native App引向一个新阶段。我说，它是一把双刃剑，千万别闯进它的误区。本文是笔者在实践Hybrid App开发模式过程中总结出的一些经验教训，供读者参考。Hybrid App虽好，可万万不能仓促选择，盲目运用。

智能手机日益普及，移动互联网乱战日趋白热化，开发一个应用早就不是技术圈热议的话题，iOS和Android上的App已经成了每个互联网产品的标配。“唯快不破”也是中被移动互联网人尊为铁律，快速迭代，高效开发，低成本上线是每一个App开发团队追求的目标。同时，随着HTML 5的不断升温和智能手机硬件性能的提高，Hybrid App的概念应运而生。这种“Native搭台，HTML 5唱戏”的Hybrid App开发模式一时间受到各个开发团队追捧，快速进入了大量开发团队，成为主流开发模式。

Hybrid App优点众多，Web前端工程师0成本介入，不依赖版本的实时更新，快速实现跨平台需求，等等。而另一个方面，2012年Hybrid App的践行者Facebook决定大量弃用App中的HTML页面，转向更加Native化的方案。Facebook的这一举措也给Hybrid App方案的敲响了警钟，这似乎并不是一个完美的方案。

本文主要跟大家分享一下我团队和个人在Hybrid App的实践中遇到的问题，提醒大家不要闯进Hybrid App的误区。

误区一：为了HTML 5而Hybrid App。

HTML 5在Hybrid App模式中是一个最常被提起的概念。HTML 5作为一个HTML 4.0.1和XHTML 1.0的升级版，基于旧版本有更强大的表现功能，并加入了Local Storage等技术，确实为Web页面提供了更大的想象空间和更多的可能性。但HTML 5处在目前的发展阶段，受到浏览器兼容性和手机硬件性能水平的影响，它所能提供的功能与Native仍然有很大差距。

所以，我认为作为工程师要明确一款App采用Hybrid App模式的根本原因是什么。作为一款App其最根本的功能是满足使用者的需求，而并不是服务某项新技术。因此当决定采用Hybrid App去构建一款应用时，应该从应用本身功能特点和整个团队的开发资源配比统一考虑，是否有必要同时又有能力去驾驭一款“Native搭台，HTML唱戏”的Hybrid App。类似“HTML 5的时代已经到来，如果我们不这么做就变土鳖了，错过这场技术革新的大潮，终将被这个时代所淘汰”的话真不是一个有责任心的工程师应该发出的声音。

误区二：忽略关键因素

在谈到Hybrid App的场合我们更多提及的是它有诸多优点，如何架构一个Hybrid App，怎么让Web和Native和谐共处，然而Web开发中会被忽略的一些因素少被提起，这些因素又恰恰经常是一个Web页面能否正常运行在App中的决定性因素。

Web开发是基于PC的一种开发模式，开发者使用PC浏览器模拟App中的Web View进行调试。PC浏览器与手机Web View的区别是巨大的，能支配的CPU资源，最大占有的内存，运行的网络环境，鼠标操作与触控操作的区别，浏览器对CSS/JS的解析和对事件处理，等等。

App工程师，无论是iOS还是Android，最敏感的一个问题莫过于内存管理，而在Web开发则对这个问题没有过多注意。这就经常导致同一个功能界面Native实现中会通过一些技术手段，把内存容量控制在操作系统允许的范围内保证App正常运行。如果以Web方式接入App的页面没有一个明确的标准和严格的验收机制，相应的Web实现则不会过多考虑这方面的问题，而且浏览器也没有给前端工程师提供足够的Api支持处理内存问题，导致在某些条件下造成App无法正常运行，甚至Crash。

同样的问题会出现在网络环境方面，虽然现在wifi覆盖越来越广，3G网络也日益普及，但App运行的网络环境与PC相比仍然有着巨大差距，wifi和蜂窝网络的切换，基站变化等诸多因素都会导致网络间歇性断开。Web开发总是默认有一个稳定的网络环境，因此在对于不稳定网络环境问题的处理上也有所欠缺。没有明确的对于低速网络或不稳定网络访问的处理，在很多情况下这些页面也会非常不给面子。

误区三：富交互导致体验差

这里所谓的体验问题一分为二：一是与手机平台默认交互习惯不一致的体验，二是与同样功能Native界面存在的体验差距。

无论在Android还是iOS平台上，都有各自的一套交互习惯，包括视觉风格，界面切换，操作习惯等，与Web习惯完全不同。如果使用Web方式开发富交互的页面，或多页面功能就会出现这样的问题。

以iOS界面切换为例，系统风格是新界面自右向左推入，后退时界面自左向右推出，而旧界面保持状态。Web开发的默认习惯则是刷新页面，无论新载入页面或是后退，都会对页面进行刷新。因此使用Web模式开发多界面功能就面临这样的交互习惯差异，造成体验上的损失。当然Web方式也可模拟Native的交互方式，但这样的模拟首先提高了开发成本，有悖于最初的高效原则，从效果上看，也很难达到Native的流畅性。

另一个方面，也是上述提到的与Native相比，同样的功能在性能上存在巨大差距。Web界面上JS对HTML Node的操作需要消耗大量的CPU资源，手机CPU的性能还不能与PC相提并论，就算在智能手机之间，硬件水准也参差不齐，一个可以在iPhone 5上流畅运行的界面，跑到三星S III上很可能就卡住不动了。所以我们经常可以发现一些富交互页面上的操作无法达到令人满意的流畅度，而流畅度也正是用户评价一款App优劣的最直观因素。

误区四：跨平台

一次开发，跨平台运行是Web的优势，这也是很多App采用Hybrid模式的重要原因之一。兼容性问题在Web开发过程中往往不被关注，但当下智能手机的软硬件版本众多，兼容性绝对是一个不容忽视的问题。

以Android手机为例，诸多主流品牌都有各自定制过的操作系统，浏览器内核对JS和CSS的解析，事件处理等方面都存在区别。以HTC One为例重叠在一起的层在某些情况下会对点击事件透传，而其他多数平台则不存在这个问题。并且目前移动平台的开发框架还没有完全成熟，可以很好的解决兼容性问题。所以就要求开发者在开发过程中要对兼容性做充分测试，对于某些特殊版本进行特殊处理。

即使在相对统一的iOS平台，不同版本之间也存在较大差异。例如：在iOS 4.x版本中CSS甚至不支持position fix的属性，4英寸屏幕的设备无法很好的支持apple-mobile-web-app-capable属性，等等。

误区五：交互一致性。

交互一致性是一个非常容易被误读的概念，“一致性”经常被理解为同一个应用在各种平台和场景下要有一致性的体验。我认为在移动平台开发过程中，“一致性”应该是App视觉和交互习惯与其运行平台的习惯保持一致。而Web开发“一次开发，跨平台运行”的特性与此存在一定程度上的冲突。

以“返回上一页面”的操作为例，在iOS平台上在页面顶部始终存在一个44像素高的导航栏，左侧有一个返回按钮用于返回操作，而Android平台则习惯使用设备提供的返回键操作。这个返回按钮在iOS平台可以通过绝对地址的方式连接到任何其他页面，而在Android平台返回按钮和设备的返回键则可能指向不同的位置。

例如这样的一个流程：首页->列表->筛选->刷新过的列表，此时的返回操作被期望是导向首页，则页面上的返回按钮可以通过绝对链接的方式实现，而Android设备的返回键则只能返回上一个筛选页面，再次返回是筛选前的列表页。

Hybrid App方案是一把双刃剑，一方面它平衡了Native App和Web页面的优缺点，一定程度上解决了Native App开发过程中迭代慢，版本依赖，Native开发资源不足的问题，但另一个方面过度依赖Hybrid方案会造成Web前端开发成本快速上升，甚至造成App整体体验下降，甚至造成功能缺失。

不要为了Hybrid而Hybrid，控制好方案中Native与Web的边界。

扩展阅读

较早Mobtest针对Facebook的iOS App专门做的一片评测文章，阐述了使用大量HTML页面的App出现的问题：http://blog.mobtest.com/2012/05/heres-why-the-Facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/

资深开发者@李秉骏 在InfoQ发表的《Hybrid App实战》，阐述了Hybrid模式的优势与劣势，并简单介绍了开发Hybrid App所需的技术储备，供读者参考。：http://www.infoq.com/cn/articles/hybrid-app-development-combat

资深开发者@唐巧 较早对Hybrid App主流框架PhoneGap的分析文章，笔者非常同意对PhoneGap框架的态度，PhoneGap虽好，可不要贪杯哟：http://blog.devtang.com/blog/2012/03/24/talk-about-uiwebview-and-phonegap/

————–
转自infoq：http://www.infoq.com/cn/articles/hybridapp-misunderstanding

有多少前端攻城湿，就有多少IE受害者~~~ →_→

    这段时间开始搞webview，html5~~~~本来以为总算可以暂时逃离IE的魔咒了，可是没想到的是，除了iphone和android，还有个wp7，wp7里还有个IE9，之前听说IE9支持html5，所以开始并没有把它放在心上，可是真正要用它的时候，问题来了

    开始的时候是习惯的拿alert测试，没反应，把页面内容删光，只剩一个alert也不行，google一下，以为是客户端对webview功能做了限制，去找客户端同事，人家很委屈的说，没做任何限制~~~好吧，不能alert，换其他方法测试

    然后是发觉click绑定有时不成功，开始以为绑定方法不对，试遍了jquery的的live、click、bind，和DOM的onclick，都不行，将同样的页面直接用wp7的IE9打开，于是又去找客户端，这次同事认真查了wp7的手册，回复给我一段文档，大意是说：wp7的webview只支持简单的html显示。可是其他很多js功能是可以用的~~~嗯，也就是说具体支持哪些js功能~~没准~~~~这便是悲剧之源

    后来，死马当活马医，将链接的“href=javascript:void(0)”，改成“href=#”，click绑定居然起效了~~~~尼玛的微软，连最屎的IE6都支持“void(0)”

    做技术的有句话：发现了问题就等于解决了问题~~~~可是对于眼下这种薛定谔的猫的问题，真的没办法了，除非有时间一个一个试去~~~~可惜没时间~~~~无奈，降格，把你当wap用总可以吧！！！