根据最近的一篇报告显示，HTML是移动应用开发人员使用最多的语言，开发人员对于选择哪种网页技术考虑的最主要因素，是代码的跨平台便携性和开发的低成本性。我们常常听说，hybrid app使用起来非常慢，而且设计也很糟糕，让我们看看是否有可能又有原生应用的形，又有我们习惯使用的感。

　　这篇文章会提供很多关于如何构建良好的hybrid移动应用的线索、代码片段和经验。我将会大致介绍一下hybrid移动应用的开发，包括它的优点和缺点。然后，我会分享一下过去两年我在开发Hojoki和CatchApp时积累的经验，这两个项目都运行在主流的移动平台，并且是由HTML、CSS和Javascript建成的。最后，我们会介绍一下打包代码到原生app的一些比较好的工具。

　　什么是混合模式移动应用

　　移动app可以大致被分为三种，native、hybrid和web app。如果使用native app，你可以使用设备和操作系统的所有能力，同时，平台的性能负荷最小。然而，构建web app可以让你的代码跨平台，使得开发时间和成本大大减少。而hybrid app把这两者的优点都结合起来，使用一套共同代码，在许多不同的平台上部署类似原生的app。

　　有两种构建hybrid app的方法：

　　Webview app：HTML,CSS和Javascript基础代码在一个内部的浏览器(叫做WebView)中运行，这个浏览器打包在一个原生的app中，一些原生的API可以通过这个包被Javascript获得，比如Adobe PhoneGap和Trigger.io。

　　被编译的hybrid app：用一种语言编写代码(如C#或者Javascript)，对于每一种支持的平台都把代码编译进原生代码中，这样做的结果是，每一个平台都有一个原生的app，但是在开发过程中少了一些自由空间。可以看一下这些例子，Xamarin，Appcelerator Titanium，Embarcadero FireMonkey。

　　这两种方法都被广泛使用，存在即合理，不过今天我们只关注WebView app ，因为WebView app可以让开发人员平衡他们现有的网页技术。我们来看一下hybrid app相对于native app和web app的各种优点和缺点。

　　优点

　　开发人员可以使用现有的网页技术

　　对于多种平台使用一套基础代码

　　减少开发时间和成本

　　使用响应式网页设计可以非常简便的设计出多样的元素(包括平板)

　　一些设备和操作系统特征的访问

　　高级的离线特性

　　可见度上升，因为app可以原生发布(通过app store)，也可以发布给移动端浏览器(通过搜索引擎)

　　缺点

　　某些特定app的性能问题(那些依赖于复杂的原生功能或者繁重的过渡动画的app，如3D游戏)

　　为了模拟native app的UI和感官所增加的时间和精力

　　并不完全支持所有的设备和操作系统

　　如果app的体验并不够原生化，有被Apple拒绝的风险(比如说一个简单的网站)

　　这些缺点比较显著，不能忽略，它们告诉我们，并不是所有的app都适合混合模式，你需要小心的预计你的目标用户、他们对平台的选择和对app的需求。对于许多app来说，好处都是大于坏处的，比如内容驱动的app。

　　Hojoki和CatchApp都是内容驱动的app，所以我们一开始觉得它们非常适合混合模式的开发方式。我们之前提到的好处中的前三点对于我们构建Hojoki的移动app帮助很大，不过也仅仅是4周的时间而已。显而易见，Hojoki的第一个版本缺失了很多重要的东西，接下来的时间里，我们都把精力扑在提升性能、对每一个平台制作自定义的UI和利用不同设备的高级特性上。那个时候积累的那些经验对于让app形似并神似native app很重要，下面我会尽可能多的分享一下我的经验。

　　那么， 怎么能让你的app形似并神似一个原生的app呢?对于一个移动网页开发人员来说，能够使用设备和操作系统的能力，能够打包他们的app，这些都听上去很棒。然后，如果要用户相信这是一个native app，那么它就必须长得像并且表现的像。如何完成这一点对于混合模式移动开发人员来说仍然是最大的挑战之一。

　　让你的用户宾至如归

　　虽然我们只写一套基础代码，但这并不意味着多种不同平台上的感官都要完全一样，你们用户根本不在乎什么潜在的跨平台技术，他们只想要app根据他们的期望来展现，他们想要“宾至如归”。你的第一步应该是为每一个平台做设计概览：

　　“IOS设计资源”, IOS开发人员库

　　“Android设计”, Android开发人员

　　“设计”, Windows开发中心

　　虽然这些概览并不能完美适应全部的app，但是它们仍然提供了一套非常全面和标准的界面和体验，每一种平台的用户都会希望得到这样的体验。

　　DIY VS. UI框架

　　如果你一个人实施这些组件、样式和动画，这是个很大的挑战，现在有各种各样的UI框架来帮助你，从商业(Kendo UI)的到开放(lonic)的，从共同UI(JQuery Mobile和Onsen UI)到许多有平台针对性的UI(Sencha Touch和ChocolateChip-UI)。有些能够很好的提供精确到像素的布局，有些则相对粗糙，这些各式各样的框架能够很方便的让使用者定义一个web app。然而，就我的观念而言，框架最主要的缺点关乎性能，因为大多数UI框架都尽量“海纳百川”，要根据自己的情况在设备上试试demo后再决定是否要使用。

　　在制作Hojoki的时候，我们尝试自己用CSS3和极少的Javascript来创建所有的组件，这样做的好处是能够帮助我们控制性能，减少负荷。当然，我们也会使用一些别人使用过的较小的库来解决一下复杂的任务。

　　自定义UI组件

　　自定义UI组件也有很多很好的使用例子，你需要根据你的目标用户来决定使用平台的UI还是自定义UI，如果你想要单干，你需要对UX设计有很深的理解，因为之前的那些概览都是专家们为了迎合他们平台用户的需求而制作的。

　　不管你是决定坚持使用平台的UI概览还是自己做自定义的组件，你都必须知道，有一些特定的设计样式是用户每天使用并热爱的。通常我们如何把一个app介绍给用户呢?通过幻灯片讲演或者教学覆盖。用户如何导航?如果标签栏或者侧边栏。用户如何快速加载或者刷新数据?下拉刷新。(在接下来的文章中会讲到类似原生的滚动)

　　移动端UI设计的资源

　　“移动端UI设计样式：10几个灵感迸发的网站”，Jacob Gube，Six Revisions

　　“用HTML、CSS和Javascript克隆IOS 7的UI”，C?me Courteault

　　“用HTML5点进移动端UI”(幻灯片)，Luke Melia and Yael Sahar, Slideshare

　　设计一个看起来原生的标题栏

　　在UI中，标题栏是一个很重要的部分，包括它的标题、导航元素、尤其是前进和后退按钮。对于我来说，许多流行框架在提供HTML和CSS解决方案方面，相比一些原生的app是失败的，而为每个平台用最小的DOM和最少行的css代码来仿照这个UI部分其实相当的简单。

　　1htmlFeedDetails

　　在JSFiddle中查看“iOS、Android和Windows Phone中看起来原生的标题栏”的完整代码，下面是我的成果：

　　用html5和css做成的看起来原生的标题栏

　　在不同的平台上使用相同的DOM更为便利，因为代码整洁而且易于维护，我发现这样做对于许多IOS和Android上的UI组件都适用(包括标题栏、标签栏、定制的导航菜单、设置页面、浮层，还有很多其他的东西)。然而，想要更多的支持Windows Phone变得更加困难，因为它带来了许多非常不一样的设计模块。

　　支持高分辨率屏幕

　　现如今，高分辨率的智能手机和平板构成了巨大的移动设备市场，在iOS设备中占有率超过80%，在Android设备中占有率超过70%。为了让你设备上的图片展现得更清晰，你通常不得不将其尺寸放大到超过它原本大小的两倍，因此现在响应式网站设计中，如何针对所有不同的分辨率提供适合尺寸的图片，成为了现在热议的话题之一。现在有非常多的途径解决，每一种的优点和缺点都与带宽、代码易维护性和浏览器的兼容性有关，现在让我们来快速的回顾一下当下最流行的方法，顺序不分先后：

　　服务端的调整和传输

　　客户端通过javascript的检测和替换