现阶段移动开发模式分析

现阶段移动开发模式分析

Tips：内容部分来源于网络，未找到具体作者，请其见谅。

1. 三分天下

目前移动端信息呈现的载体大体分为三类：Web App、Hybrid App、Native App。

如果放在一年半以前，甚至是一年前，如果要做一个移动App，大家可能还是会倾向于Native App，优势不必说了，无非是性能和用户体验。但是，随着手机换机潮的到来，Android系统的更新换代在加快，Android 4.0以上系统在全球的分布已经超过95%，手机硬件性能也有所提升，这些为浏览器的渲染及脚本引擎的效率提供了基础。因此，在App中增加对web技术的使用，无论是形成Hybrid App，还是更纯粹的Web App，都有了可用性的前提。

• 对于现在的移动开发者来说，可能Native App 已不再是首选方案，硬件正在变好，选用最合适的技术方案，兼顾成本和可维护性成为主要的考虑方向。

• 对于Web App，HTML5 + CSS3 + JavaScript的三件武器几乎一统天下。Zepto.js，jQuery等各种JS框架也得到了快速的发展和应用，比如Zepto.js就一举摒弃了对很多老浏览器的兼容，可以比jQuery的部署体积更小，老牌的jQuery也在其2.X版本中果断放弃了对IE6、7、8的支持，这些甩掉历史包袱的举动，正在加速技术发展，而AngularJS更是做到了极致。

• 对于Hybrid App，PhoneGap自从转给Apache基金会以后，已经完成了使命，换了一个Cordova的名称，继续接力。Cordova为Native和Web打通了桥梁，使得JS脚本可以访问到设备的Native能力，通过这种结合，双方发挥各自的优势，看上去是个不错的选择，也是当前阶段可先的做法。而且这些Web部分可以更灵活的进行更新，甚至以插件的方式供Native App管理，再结合对本地缓存的有效利用，其体验不比Native差太多，是很好的架构方案。目前很多应用都采用了这种方案，当然是否使用Cordova另计。

• Hybrid App还有一种方案，就是由Facebook主导的React Native方案。该方案与Cordova不同，Cordova全是Web思维，只是用JS桥接了一些设备特性。React的思路是用Web的思路写界面，而不是用Native思路，但界面元素将被React框架转化为Native界面元素，从而达到最终的应用是Native化的目的。但该React Native框架目前还未发布，从现有的信息来看，对Native控件的封装会减少很多控件的接口，影响一些特殊功能的实现，另外仍然需要针对iOS、Android等不同平台进行开发，平台知识必不可少，对开发人员也是个挑战。

2. 理性看待Hybrid App

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方案的敲响了警钟，这似乎并不是一个完美的方案。下面主要谈谈使用时要注意些什么。

1. 不能为了HTML5而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的时代已经到来，如果我们不这么做就变土鳖了，错过这场技术革新的大潮，终将被这个时代所淘汰”的话真不是一个有责任心的工程师应该发出的声音。

2. 忽略关键因素

   • 在谈到 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 开发总是默认有一个稳定的网络环境，因此在对于不稳定网络环境问题的处理上也有所欠缺。没有明确的对于低速网络或不稳定网络访问的处理，在很多情况下这些页面也会非常不给面子。

3. 富交互导致体验差

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

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

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

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

4. 跨平台

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

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

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

5. 交互一致性

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

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

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

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

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