HTML5、Native或混合型应用开发全接触
openkk 12年前
<p> 许多企业向实施移动战略迈出了头几步，它们正面临将影响移动项目成效的一个重要决定。为移动 App 选择一种开发方法：Native、Web 还是 Hybrid 的过程牵涉许多因素，比如预算、项目时间表、目标群体和 App 功能，等等。每种方法都有天生的优点和局限性，找到最适合本企业要求的一种开发方法可能是项艰巨的任务。</p> <p> 本白皮书的目的不是确定哪一种是最佳的开发方法，因为不存在最佳的开发方法，而是列出每一种方法的优缺点，并描述最适合某一种开发方法的不同场景或企业需求。</p> <p> <strong>开发方法介绍</strong></p> <p> <strong>一、Native App</strong></p> <p> Native App 含有二进制可执行文件，直接下载到设备上，并存储在本地。安装过程由用户启动；在一些情况下，由企业的 IT 部门启动。下载 Native App 的最常见方法是访问应用程序商店，如苹果的应用程序商店、安卓的应用程序市场或黑莓的应用程序世界；但是还有其他方法，有时由移动开发商来提供。</p> <p> 一旦应用程序安装到了设备上，用户可以如同启动设备提供的其他任何服务那样启动应用程序。一旦完成初始化，Native App 就直接与移动操作系统进行联系，不用通过任何中介或容器。Native App 可随意访问由操作系统开发商提供的所有应用编程接口（API）；在许多情况下，NativeApp 有着某种特定的移动操作系统所常见的独特外观和感觉。</p> <p> 想创建 Native App，开发者必须编写源代码（采用人类可读的形式），并建立额外资源，比如镜像、音频段和针对特定操作系统的各种声明文件。使用由操作系统开发商提供的 工具，对源代码进行编译（有时还要进行链接），目的是为了建立一个二进制形式的可执行文件，它可以连同其余资源封装起来，并随时可供分发。</p> <p> 这些工具以及其他实用程序和文件通常名为移动操作系统的软件开发工具包（SDK）。虽然不同操作系统上进行的开发过程常常很相似，但是 SDK 视特定的平台而定，每一种移动操作系统都随带各自的独特工具。下面这张表显示了与四大移动操作系统有关的不同工具、语言、格式和分发渠道。</p> <p><a title="HTML5、Native 或混合型应用开发全接触" rel="lightbox[21298]"><img style="display:block;margin-left:auto;margin-right:auto;" title="HTML5、Native 或混合型应用开发全接触" alt="HTML5、Native或混合型应用开发全接触" src="https://simg.open-open.com/show/e1e140cb2116d5dbfe41d0b58299bed4.jpg" width="553" height="253" /></a></p> <p> 平台之间的这些区别导致了 Native 开发方法的最重大缺点之一：为一种移动平台编写的代码无法在另一种平台上使用；这样一来，为多种操作系统开发和维护 Native App 成了一项时间很长、成本很高的任务。</p> <p> 那么，为什么尽管存在成本高昂的这个缺点，许多公司还是选择 Native 开发这条路呢？为了回答这个问题，我们就要更清楚地了解 API 的角色。</p> <p> <strong>应用编程接口（API）</strong></p> <p> 一旦 Native App 安装到了移动设备上，并由用户启动，它就能借助操作系统公开的专有 API 调用，与移动操作系统进行联系。这些 API 可以分为两大类：低级 API 和高级 API。</p> <p> <strong>低级 API</strong></p> <p> 正是借助这些低级 API 调用，应用程序能直接与触摸屏或键盘进行联系、渲染图形、连接至网络、处理从麦克风收到的音频、通过扬声器或麦克风播放声音，或者接收来自摄像头的图像或 视频。应用程序能访问全球定位系统（GPS）、接收方位信息，当然还可以读写固态硬盘上的文件，或者访问现有和将来会有的其他任何硬件元件。</p> <p> <strong>高级 API</strong></p> <p> 除了提供我们刚才提到的低级硬件访问服务外，移动操作系统还提供对个人移动体验来说很重要的较高级服务。这类服务包括浏览 Web，管理日历、联系人资料和相册等过程，当然还包括打电话或收发文本消息的功能。</p> <p> 虽然大多数移动操作系统包含一组内置的应用程序可以执行这些服务，但是还让 Native App 可以访问一组公开的高级 API，让它们可以访问上述许多重要的服务。其他 API 让可下载式应用程序可以访问操作系统开发商提供的各种基于云的服务，比如推送通知（Push Notifications）或应用程序内购买（In-App Purchase）等服务。</p> <p> <strong>GUI 工具包</strong></p> <p> 操作系统提供的另一组重要的 API 是 GUI 工具包。每一种移动操作系统都随带各自的一组用户界面组件，比如按钮、输入区、滑块、菜单、菜单栏、对话框及其他。可以使用这些组件的应用程序继承了该特定移动操作系统的外观和感觉，通常会带来非常流畅的用户体验。</p> <p> 值得一提的是，不同的移动平台带有一系列独特的用户界面组件。因而，为了可在多种操作系统上运行而设计的应用程序需要设计者熟悉每一种操作系统不同的用户界面组件。</p> <p> 虽然 API 视特定的操作系统而定，并且给开发诸多 Native App 的工作大大增添了复杂性和成本，但是这些元素只是创建丰富移动应用程序的手段而已，这些应用程序可以充分利用现代移动设备所提供的全部功能。</p> <p> <strong>二、移动 Web App</strong></p> <p> 现代移动设备包含功能强大的浏览器，这些浏览器支持许多新的 HTML5 功能、CSS3和高级 JavaScript。由于最近在这方面取得的进展，HTML5预示着这项技术将从一种“页面定义语言”，转变成一种功能强大的开发标准，用于开发丰富 的、基于浏览器的应用程序。</p> <p> 表明 HTML5 大有潜力的几个例子包括：高级的用户界面组件、可以访问丰富媒体类型、地理位置服务和离线功能。使用这些特性和处于开发中的其他更多特性，开发者就能仅仅使用 Web 技术，开发出高级应用程序。</p> <p> 不妨先来区别一下两种极端的 Web App 开发方法。我们都熟悉移动浏览和针对移动设备优化的网站。这些网站能够识别何时被智能手机访问，因而呈现为了在小尺寸屏幕上提供舒适的“触摸体验”设计的 HTML 网页。但是有些公司更进一步，建立了移动网站，以改善用户体验。这种移动网站看起来就像 Native App，可通过快捷方式来启动，这与启动 Native App 的方式没什么不同。</p> <p><a title="HTML5、Native 或混合型应用开发全接触" rel="lightbox[21298]"><img style="display:block;margin-left:auto;margin-right:auto;" title="HTML5、Native 或混合型应用开发全接触" alt="HTML5、Native或混合型应用开发全接触" src="https://simg.open-open.com/show/b919784e52a9fc433e8f401dbcbc505e.jpg" width="520" height="438" /></a></p> <p> 这两个极端之间存在一系列广泛的可能性，大多数网站实施了各自的 Hybrid 特性。</p> <p> 移动 Web App 是一种很有希望的趋势。为了紧紧抓住这个趋势，帮助开发者构建客户端用户界面，已开发出越来越多的 JavaScript 工具包，比如 Sencha Touch 和 jQuery Mobile，它们创建的用户界面在外观和感觉上与 Native App 大同小异。两者都完全在移动设备的浏览器里面执行，充分利用了现代移动浏览器所提供的最新 JavaScript、CSS 和 HTML5 特性。</p> <p> Web App 最突出的优势之一是，它支持多种平台，而且开发成本低。大多数移动开发商利用了浏览器中的同一种渲染引擎：WebKit——主要由谷歌和苹果领导的这个开 源项目提供了如今最全面的 HTML5 实现机制。由于应用程序的代码用与 WebKit 兼容的标准 Web 语言编写而成，所以一个应用程序在诸多不同的设备和操作系统上提供了统一的体验，因而使得它在默认情况下支持多种平台。但是这些优势并非没有代价。尽管移 动领域的 Web 技术大有潜力和希望，但它们仍存在相当大的局限性。为了解这些局限性，我们就要解释 Web App 是如何运行的。</p> <p> 不像 Native App 是独立的可执行文件，直接与操作系统进行联系，Web App 则在浏览器里面运行。而浏览器本身是可直接访问操作系统 API 的一种 Native App，但是只有数量有限的这些 API 向浏览器里面运行的 Web App 公开。虽然 Native App 可以完全访问设备，但是许多特性只是部分可供 Web App 使用，或者根本不可使用。虽然预计这种情况在将来会随着 HTML 的改进而改变，但是如今的移动用户无法使用这些功能。</p> <p> <strong>三、Hybrid App</strong></p> <p> <strong>Hybrid</strong>开发方法结合了 Native 开发和 Web 技术。借助这种方法，开发者就能使用跨平台 Web 技术，开发应用程序的大部分代码，又可以在需要时直接访问 Native API。</p> <p> App 的 Native 代码部分使用操作系统的 API 来创建嵌入式 HTML 渲染引擎，该引擎在浏览器和设备的 API 之间充当了桥梁。这座桥梁让 Hybrid App 得以充分利用现代设备所提供的全部特性。</p> <p> App 开发者可以选择编写自己的桥梁，或者充分利用现成的解决方案，比如 PhoneGap——这种开源库为有选择的设备功能提供了在诸操作系统上保持一致的统一 JavaScript 接口。</p> <p> App 的 Native 代码部分可以独立开发，但是市场上的一些解决方案把这种类型的 Native 容器作为其产品的一部分来提供，因而让开发者有办法只要使用 Web 语言，就可以构建利用设备所有特性的高级 App。在一些情况下，解决方案让开发者可以充分利用现已掌握的任何 Native 开发技能，根据企业的独特要求来定制 Native 容器。</p> <p> App 的 Web 部分可能是驻留在服务器上的网页，也可能是一组 HTML、JavaScript、CSS 和媒体文件，封装到 App 代码中，存储在设备本地。这两种方法都有其优势和局限性。放置在服务器上的 HTML 代码让开发者不必经历提交和批准过程——有些 App 商店要求这个过程，就可以对 App 进行小幅更新。遗憾的是，这个方法摈弃了任何离线可用性，因为设备与网络没有连接时，无法访问设备。另一方面，把 Web 代码封装到 App 里面可以提高性能和可访问性，但是不允许远程更新。如果结合这两种开发方法，也许可以集两者之所长。这种系统采用的架构可以把 HTML 资源放置在 Web 服务器上，以获得灵活性，但是又把它们本地缓存在移动设备上，以获得高性能。</p> <p> <strong>比较不同的开发方法</strong></p> <p> 所以为了总结，不妨看一下这三种开发方法各自相比怎么样。</p> <p><a title="HTML5、Native 或混合型应用开发全接触" rel="lightbox[21298]"><img style="width:530px;display:block;height:271px;margin-left:auto;margin-right:auto;" title="HTML5、Native 或混合型应用开发全接触" alt="HTML5、Native或混合型应用开发全接触" src="https://simg.open-open.com/show/d5e16aca4937f20488187271ce4e4517.jpg" width="673" height="335" /></a></p> <p> Native 开发方法在性能和设备访问方面很出色，但成本和更新方面有缺点。Web 方法更新起来简单得多，成本较低，也更容易，但是目前功能有限，也无法获得使用 Native API 调用所能获得的那种出色的用户体验。Hybrid 开发方法提供了折中方案：在许多情况下，它集两者之所长，如果开发者面向多种操作系统更是如此。</p> <p><a title="HTML5、Native 或混合型应用开发全接触" rel="lightbox[21298]"><img style="display:block;margin-left:auto;margin-right:auto;" title="HTML5、Native 或混合型应用开发全接触" alt="HTML5、Native或混合型应用开发全接触" src="https://simg.open-open.com/show/3ce1beb71c47f0dff9908daf6065e48d.jpg" width="501" height="655" /></a></p> <p> 从上面这张表可以推断出，没有哪一种开发方法总是提供所有的优点。选择一种合适的方法取决于企业的具体要求，可能取决于诸多因素，比如预算、时 间表、内部资源、目标市场、所需的应用程序功能、IT 基础设施及其他许多方面。但是有一点很清楚：如今的大多数公司显然在两个方面之间作一取舍：一方面是用户体验和应用程序功能，另一方面是开发成本和产品上 市时间。问题就变成了选择一种合适的开发方法，能兼顾企业的要求和其在预算和产品上市时间方面的限制。</p> <p><a title="HTML5、Native 或混合型应用开发全接触" rel="lightbox[21298]"><img style="display:block;margin-left:auto;margin-right:auto;" title="HTML5、Native 或混合型应用开发全接触" alt="HTML5、Native或混合型应用开发全接触" src="https://simg.open-open.com/show/e84b483fd5ef64d7edea58d05544d31e.jpg" width="394" height="386" /></a></p> <p style="text-align:center;"> 选择合适的开发方法</p> <p> 下面介绍有助于帮助企业选择合适开发方法的一些场景：</p> <p> <strong>一、Native 开发方法的场景</strong></p> <p> <strong>现有的 Native 开发技能</strong>——反对 Native 开发方法的主要理由之一是，它缺少对多种平台的支持。要求为多种移动平台开发 App 的企业需要招聘新员工，或者对内部开发者进行众多 Native 语言方面的培训。内部拥有这种 Native 开发技能的企业不需要大笔新的投入，就能够充分利用这些技能。</p> <p> <strong>单一移动操作系统</strong>——在一些情况下，企业旨在向有限的目标群体发布移动 App——这个群体已知使用单一移动操作系统。比如说，考虑这种场景：向员工发放黑莓设备的企业分发内部 App。在这种情况下，支持多种平台也许不是优先事项：由于开发单一的 Native App 只需要一套有限的技能和工具，所以这种方法很有意义。</p> <p> <strong>Native 功能</strong>——有些 App 是围绕某一项功能开发的。就拿 Skype 来说，VOIP 和访问用户的联系人信息是 App 的两大关键要素；考虑到现有的技术，只能采用 Native 方法来开发。对这类 App 而言，Web 语言根本不够完善，根本无力获得所需的功能。</p> <p> <strong>丰富用户界面的需求</strong>——有些游戏类 App 需要提供实时响应的丰富用户界面，对这类 App 而言，Web 技术还无法提供足够有效的解决方案。对有这类需求的 App 而言，开发者采用 Native 开发方法仍然比较好。</p> <p> <strong>二、Web 开发方法的场景</strong></p> <p> <strong>直接分发</strong>——有些企业更喜欢以一种内部控制的方式来分发 App，他们不喜欢受制于有时很漫长、很不确定的审批过程。这种情况下，使用纯粹的 Web 语言可以完全规开应用商店的审批过程，让企业可以完全控制 App 的定期更新和分发。</p> <p> <strong>试点 App</strong>——比较 Native App 与 Web App 开发所需的成本和上市时间时，使用 Web 方法开发试点应用程序是一种引人入胜的、经济高效的方法。一旦概念得到了证明，企业可以决定从头开始创建新的 App，或者充分利用 Hybrid App 中的部分现有代码。</p> <p> <strong>可视性</strong>——除了前面提到的分发外，构建 Web App 的另一个优点是搜索引擎结果具有可视性；在许多情况下，搜索引擎结果将 App 展示给比仅仅通过应用商店获得的群体更庞大的群体。</p> <p> <strong>三、Hybrid 开发方法的场景</strong></p> <p> <strong>折衷考虑</strong>——如果企业使用 Hybrid 开发方法，就能集两者之所长。一方面，Native 让开发者可以充分利用现代移动设备所提供的全部不同的特性和功能。另一方面，使用 Web 语言编写的所有代码都可以在不同的移动平台之间共享，使得开发和日常维护过程变得集中式、更简短、更经济高效。</p> <p> <strong>内部技能</strong>——Web 开发技能十分常见，许多企业都拥有这类技能。如果选择 Hybrid 开发方法，在合适解决方案的支持下，Web 开发者只要仅仅运用 HTML、CSS 和 JavaScript 等 Web 技能，就能构建 App，同时提供 Native 用户体验。</p> <p> <strong>考虑未来</strong>——HTML5的可用性和功能都在迅速改进。许多分析师预测，它可能会成为开发前端 App 的默认技术。如果用 HTML 来编写 App 的大部分代码，并且只有在需要时才使用 Native 代码，公司就能确保他们今天的投入在明天不会变得过时，因为 HTML 功能变得更丰富，可以满足现代企业一系列更广泛的移动要求。</p> <p> <strong>总结</strong></p> <p> 由于移动 App 继续在商业界扮演核心角色，全球各地的企业为越来越多的关键任务服务赋予移动特性。许多公司正在力求找到最佳的开发方法来实现目标，但是许多公司很快认识 到：每一种开发方法有天生的局限性，没有哪一种方法能够满足现代移动企业的所有要求、应对复杂情况。</p> <p> 正如本白皮书试图表明的那样，答案不在于使用哪一种开发方法，而在于使用灵活的解决方案；这种解决方案能利用各种方法提供的优点，不仅支持首款移动 App 的开发，还支持将来所有的 App，不管他们采用哪种开发方法。</p> <p> 但是 Hybrid、Native 和 Web 之间的选择不是唯一的选择，尽管无疑是重大的选择。制定移动战略的公司还必须考虑这个市场的未来：</p> <ul> <li>移动设备和技术的进一步分散，这反过来会继续增加与移动 App 开发、集成和日常管理有关的总体成本和复杂性。</li> <li>消费者和企业内部加快采用移动技术，从而提高了安全性、扩展性和日常控制等方面的需求；</li> <li>新的设备特性和补充技术（如近场通信、地理位置、增强现实、社交网络及其他技术）无疑会带来移动应用程序的新类型和新用例。</li> <li>新的 App 分发渠道（包括公共和私有渠道）让企业很容易把应用程序交到用户手上，迅速部署更新版、管理整批 App，不需要经历漫长的提交和审批过程。</li> </ul> <p> 如果考虑到所有这些方方面面，公司必须选择这样一种解决方案：不仅足够灵活，可以支持各种类型的 App，还能支持将 App 安全而灵活地集成到 IT 基础设施中，并且让公司可以通过一个集中式界面来监测和控制整批 App。</p> <p> 英文原文：<a href="/misc/goto?guid=4958343155627432018" rel="nofollow" target="_blank">http://www.worklight.com/assets/file…evelopment.pdf</a><br /> 来自: <a id="link_source2" href="/misc/goto?guid=4958343156433401583" target="_blank">51CTO</a></p>