Hybrid移动应用:用网页技术提供Native体验外文翻译资料

Hybrid Mobile Apps: Providing A Native Experience With Web Technologies

According to a recent report, HTML is the most widely used language for mobile app developers. The main reasons among developers for selecting web technologies are cross-platform portability of code and the low cost of development. Wersquo;ve also heard that hybrid apps tend to be sluggish and poorly designed. Letrsquo;s prove whether itrsquo;s possible to deliver the native look and feel that wersquo;re used to.

This article provides many hints, code snippets and lessons learned on how to build great hybrid mobile apps. Irsquo;ll briefly introduce hybrid mobile app development, including its benefits and drawbacks. Then, Irsquo;ll share lessons Irsquo;ve learned from over two years of developing Hojoki and CatchApp, both of which run natively on major mobile platforms and were built with HTML, CSS and JavaScript. Finally, wersquo;ll review the most prominent tools to wrap code in a native app.

What Are Hybrid Mobile Apps?

Mobile apps can be generally broken down into native, hybrid and web apps. Going the native route allows you to use all of the capabilities of a device and operating system, with a minimum of performance overhead on a given platform. However, building a web app allows your code to be ported across platforms, which can dramatically reduce development time and cost. Hybrid apps combine the best of both worlds, using a common code base to deploy native-like apps to a wide range of platforms.

There are two approaches to building a hybrid app:

The code is written in one language (such as C# or JavaScript) and gets compiled to native code for each supported platform. The result is a native app for each platform,but less freedom during development. Examples are Xamarin, Appcelerator Titanium and Embarcadero FireMonkey.

While both approaches are widely used and exist for good reasons, wersquo;ll focus on WebView apps because they enable developers to leverage most of their existing web skills. Letrsquo;s look at all of the benefits and drawbacks of hybrid apps compared to both native and mobile web apps.

These drawbacks are significant and cannot be ignored, and they show that the hybrid approach does not suit all kinds of apps. Yoursquo;ll need to carefully evaluate your target users, their platforms of choice and the apprsquo;s requirements. In the case of many apps, such as content-driven ones, the benefits outweigh the drawbacks. Such apps can typically be found in the “Business and Productivity,” “Enterprise” and “Media” categories in the app store.

Both Hojoki and CatchApp are very content-driven productivity apps, so we initially thought they would be a great match for hybrid development. The first three benefits mentioned above were especially helpful to us in building the mobile app for Hojoki in just four weeks. Obviously, that first version lacked many important things. The following weeks and months were filled with work on optimizing performance, crafting a custom UI for each platform and exploiting the advanced capabilities of different devices. The learning in that time was crucial to making the app look and feel native. Irsquo;ll share as many lessons as possible below.

So, how do you achieve a native look and feel? To a mobile web developer, being able to use the features of a device and operating system and being able to package their app for an app store sounds just awesome. However, if users are to believe it is a native app, then it will have to behave and look like one. Accomplishing this remains one of the biggest challenges for hybrid mobile developers.

Make Your Users Feel at Home

A single code base doesnrsquo;t mean that the app should look and feel exactly the same on all platforms. Your users will not care at all about the underlying cross-platform technology. They just want the app to behave as expected; they want to feel “at home.” Your first stop should be each platformrsquo;s design guidelines:

While these guidelines might not perfectly suit all kinds of apps, they still provide a comprehensive and standard set of interfaces and experiences that users on each platform will know and expect.

DIY VS. UI FRAMEWORKS

Implementing all of these components, patterns and animations on your own can be quite a challenge. All kinds of frameworks exist to help you with that, ranging from commercial (Kendo UI) to open-source ones (Ionic) and from ones with a common UI (jQuery Mobile and Onsen UI) to many platform-specific UIs (Sencha Touch and ChocolateChip-UI). Some are really good at providing a pixel-perfect layout, while others are rather sloppy, thus making it easy for the user to identify a web app. However, my impression is that their main drawbacks are performance-related, because most UI frameworks try to be as all-embracing as possible. Judge for yourself by taking a few minutes to try the demos on your own device.

At Hojoki, we try to craft all components on our own using CSS3 and minimal JavaScript. This keeps us in control of performance and reduces overhead. We obviously use small libraries for complicated tasks that someone else has solved just fine.

CUSTOM UI COMPONENTS

Custom UI components also have many good use cases. Deciding between a platformrsquo;s UI and a custom UI will obviously depend on your target audience. If you want to do your own thing, you should have a deep understanding of UX design, because the guidelines linked to above were crafted by ex

剩余内容已隐藏，支付完成后下载完整资料

Hybrid移动应用:用网页技术提供Native体验

根据最近的一篇报告显示，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“，Cocirc;me Courteault
• “用HTML5点进移动端UI”（幻灯片），Luke Melia and Yael Sahar, Slideshare

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

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

lt;headergt;

lt;button class='back'gt;Feedlt;/buttongt;

lt;h1gt;Detailslt;/h1gt;

lt;!-- more actions (e.g. a search button on the right side) --gt;lt;/headergt;

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

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

支持高分辨率屏幕

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

• 服务端的调整和传输
• 客户端通过javascript的检测和替换
• html5的picture元素
• html5 的srcset属性
• css image-set属性
• css media queries
• 可伸缩矢量图形(SVG)

一直以来，针对响应式图片都没有一个完美的方法，这主要还是取决于图片的类型和它们在app上的展现使用方式。如果是静态图片(比如logo和教程图片)，我尽量使用SVG，它们能不费吹灰之力的完美缩放，并且只要你是Android 3 就能获得很好的浏览器支持。

当你不能选择SVG的时候，html5的picture元素和srcset属性一定会成为日后前端开发人员的首选。当下，它们最大的不足就是在浏览器上的支持太局限，因此他们需要一些插件.

同时，css背景图片和media queries是比较可靠的解决方案:

/* Normal-resolution CSS */.logo {

width: 120px;

background: url(logo.png) no-repeat 0 0;}

/* HD and Retina CSS */@media

only screen and (-webkit-min-device-pixel-ratio: 1.25),

only screen and ( min--moz-device-pixel-ratio: 1.25),

only screen and ( -o-min-device-pixel-ratio: 1.25/1),

only screen and ( min-device-pixel-ratio: 1.25),

only screen and ( min-resolution: 200dpi),

only screen and ( min-resolution: 1.25dppx) {

.logo {

background: url(logo@2x.png) no-repeat 0 0;

background-size: 120px; /* Equal to normal logo width */

}}

但是，你的app也许已经包含了许多内容(比如新闻文章)，要调整所有的图片标签或者用css替代会让我们筋疲力竭，在这种情况下，服务端解决方案就会是最好的选择。

从去年开始，越来越多的android系统已经离XXHDPI(超高分辨率)屏幕又进了一步。不论上面提到的哪种方案更适合你的需要，你要记住的是你需要用到三倍于原图大小的图片来支持android的最新的设备。

使用系统字体

使用系统字体是一种让用户体感到宾至如归的一种简单但是重要的方法。

主流平台上，我比较推荐这些字体样式：

/* iOS */font-family: Helvetica Neue, Helv

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[613296]，资料为PDF文档或Word文档，PDF文档可免费转换为Word