开发移动 Web 应用程序：何时、为什么以及如何

地球上有 68 亿人，其中 51 亿人拥有手机。 而今天，这些设备中越来越多的设备是智能手机。 根据皮尤研究中心最近的一项研究，在过去 5 年中，通过智能手机访问互联网的用户数量增加了一倍多，下载和使用移动应用程序的用户数量也增加了一倍多。 在手机上使用互联网或电子邮件的人中，超过三分之一的人主要通过他们的手持设备上网。

事实上，移动计算正变得越来越普遍……而且它很棒。

当然，除非它不是。

作为移动设备用户，没有什么比设计不佳的移动 Web 应用程序甚至原生应用程序更令人沮丧和难以驾驭的了。

作为一名移动应用程序开发人员，没有什么比努力支持尽可能广泛的移动客户端更令人恼火的了，每个移动客户端都有自己令人沮丧的特质。 无论您选择开发移动网络、原生应用程序还是混合应用程序，支持多种移动浏览器、更多奇特的设备以及掌握各种平台确实是一种非常痛苦的体验。

当然，今天并不是每个开发人员都需要担心支持移动客户端。 但移动设备和应用程序日益普遍的性质强烈表明，那些今天不需要支持移动客户端的人在不久的将来很可能需要这样做。 因此，如果您还没有考虑开发移动应用程序，那么您可能应该考虑。

移动 Web 应用 vs. 原生应用 vs. 混合应用

与大多数技术选择一样，对于要开发的移动应用程序类型，没有一刀切的答案。 有许多 Web 应用程序最佳实践需要考虑，但并非所有这些都是技术性的。 你的目标受众是谁？ 他们更喜欢移动网络还是原生应用？ 原生应用和混合应用有什么区别？ 您拥有哪些开发资源，他们最熟悉哪些移动技术？ 您为您的产品设想的许可和销售模式是什么？

一般来说（尽管总是有例外），移动网络应用程序路由比原生移动应用程序路由更快、更便宜，尤其是当目标是支持广泛的设备时。 相反，移动设备的原生功能（如运动传感器等）可能对您的应用程序至关重要，但只能通过原生应用程序访问（因此，这将使移动 Web 应用程序的选择成为非给你的开胃菜）。

除了旧的 Web 应用程序与原生应用程序的问题之外，混合移动应用程序可能是您的正确答案，具体取决于您的要求和资源限制。 混合应用程序，如原生应用程序，在设备本身上运行（而不是在浏览器内部），但使用 Web 技术（HTML5、CSS 和 JavaScript）编写，通常由混合应用程序框架支持。 更具体地说，混合应用程序在本机容器内运行，并利用设备的浏览器引擎（但不是浏览器）来呈现 HTML 并在本地处理 JavaScript。 Web 到本机的抽象层允许访问在移动 Web 应用程序中无法访问的设备功能，例如加速度计、相机和本地存储。

但无论您做出何种选择——无论是移动网络应用程序、原生应用程序还是混合应用程序——都要小心充分研究并确认您的假设。 例如，出于本移动 Web 应用程序开发教程的目的，您可能已经决定为电子商务开发一个本地移动应用程序来销售您的产品。 但是，据 Hubspot 称，73% 的智能手机用户表示他们使用移动网络而不是本地应用程序进行购物......所以，在这种情况下，你可能赌错了。

然后，当然，还有时间和预算的实际考虑。 正如我最喜欢的谚语之一所说， “更快、更好、更便宜……选择任何两个” 。 虽然上市时间和成本限制在 Web 应用程序开发中至关重要，但在过程中不要对质量做出过分妥协也很重要。 初次体验不佳的用户很难恢复信心。

事实上，移动网络、原生和混合应用程序都是完全不同的野兽，每一种都有自己独特的优势和挑战。 本移动 Web 开发教程特别侧重于在开发功能强大、直观且易于使用的移动 Web 应用程序时采用的方法和工具，以及应避免的陷阱。

移动 Web 应用开发需要详细规划

确定您（或您客户）的需求是应用程序开发、移动或其他方面最重要的最佳实践之一。 仔细研究目标功能以确定它们是否可以在您的移动 Web 应用程序中实现。 当您已经投入时间和资源来设计基于 Web 的界面和支持基础架构时，意识到您的一个或多个基本客户端功能不受支持，这是非常令人沮丧且非常低效的。

移动网络应用程序开发新手的另一个常见问题是假设桌面浏览器的基于网络的代码将在移动浏览器中“按原样”工作。 不是。 肯定存在差异，如果你不知道它们，它们肯定会咬你。 例如，HTML5 <video>标签的自动播放功能不适用于移动浏览器。 类似地，现在大多数移动浏览器不支持（或至少不始终支持）CSS transition和opacity属性。 您还会遇到移动平台上的某些 Web API 方法的问题，例如需要 Adob​​e Flash 的 SoundCloud 音乐流 API，大多数移动设备不支持该 API。

移动 Web 应用程序开发中一个特别复杂的因素是移动设备的寿命往往比桌面显示器的寿命短得多（美国手机的平均寿命约为 21 个月）。 这些较短的设备寿命，伴随着新移动设备和技术的不断发布，产生了不断变化的目标设备格局。 虽然在浏览器中工作确实通过使您免受许多特定于设备的问题的影响而在一定程度上缓解了这个问题，但您仍然需要设计一个支持许多不同屏幕分辨率的基于浏览器的视图（以及针对横向和纵向方向进行适当调整） ）。

还需要考虑支持 Apple 的 Retina 显示器（液晶显示器的像素密度足够高，以至于人眼无法在典型的观看距离上辨别单个像素）。 包括 iPhone、iPod Touch、iPad、MacBook Pro、iPad Mini 和 iPad Air 在内的几款 Apple 产品都提供 Retina 显示屏。 特别是对于移动 Web 应用程序，重要的是要意识到 Retina 显示屏会使低分辨率图像（通常提供给移动设备）看起来很模糊，并且可能会出现像素化。 在这些情况下，最好的应用程序开发解决方案是让服务器识别出请求来自 Retina 设备，然后向客户端提供替代的更高分辨率图像。

如果您想使用一些很酷的 HTML5 内容，请记住提前验证您正在寻找的功能是否在您的客户可能使用的设备环境中受支持。 例如，在 iOS 6 及更高版本中，不支持导航器getUserMedia功能，因为相机只能通过本机应用程序访问。 caniuse.com 和 html5test.com 是检查特定设备和浏览器支持的两个重要资源。

CSS3 媒体查询还可以帮助您为每个设备提供定制的内容。 下面是一些用于捕获不同设备特征的示例代码，例如像素密度、屏幕分辨率和方向：

 /* For lower than 700px resolutions */ @media (max-width: 700px) { ... } /* Same as last but with the device orientation on land scape */ @media (max-width: 700px) and (orientation: landscape) { ... } /* Including width and orientation you can add a media type clause, in this case 'tv' */ @media tv and (min-width: 700px) and (orientation: landscape) { ... } /* for low resolution display with background-image */ .image { background-image: url(/path/to/my/image.png); background-size: 200px 300px; height: 300px; width: 200px; } /* for high resolution (Retina) display with background-image */ @media only screen and (min--moz-device-pixel-ratio: 2), only screen and (-o-min-device-pixel-ratio: 2/1), only screen and (-webkit-min-device-pixel-ratio: 2), only screen and (min-device-pixel-ratio: 2) { -repeat; background-size: 200px 400px; /* rest of your styles... */ } }

优化您的移动 Web 应用程序的性能

“天哪，这东西太慢了！” 作为移动 Web 应用程序开发人员，这些可能是您最想从某个用户那里听到的最后一句话。 因此，您必须仔细考虑如何减少和优化每个字节和服务器传输以减少用户的等待时间。 期望传输总是通过 WiFi 网络完成是不现实的，您应该知道，60% 的移动网络用户表示他们希望网站在 3 秒或更短的时间内加载到他们的手机上（来源）。 同样，谷歌发现，每增加 5 秒的加载时间，流量就会下降 20%（还值得注意的是，搜索引擎将加载时间视为其页面质量得分计算的一部分）。

作为本移动 Web 应用程序开发教程的一部分，这里有一些技巧可以帮助优化移动 Web 应用程序的性能并最​​大限度地减少延迟：

• 图像优化。 众所周知，图像加载时间是影响移动设备页面加载的最大性能问题之一。 使用在线图像优化器（例如 smushit.com）有助于解决此问题。
• 代码压缩。 根据您拥有的代码量，压缩 JavaScript 和 CSS 文件可能会对性能产生重大影响。
• 数据库查询。
  • 一些移动设备浏览器接受的 cookie 不如桌面浏览器多，这可能导致需要执行比平时更多的查询。 因此，在支持移动 Web 应用程序客户端时，服务器端缓存尤其重要。
  • 请记住使用适当的过滤器来阻止 SQL 查询注入，否则可能会危及您的站点和服务器的安全性。
• 内容交付网络 (CDN)。 如果您计划提供大量视频、图像、音频文件或其他类型的媒体，强烈建议使用 CDN。 一些更常见的商业 CDN 包括 Amazon S3、Microsoft Windows Azure 和 MaxCDN。 使用 CDN 的优势很多，包括：
  • 改进的下载性能。 利用 CDN 的资源，您可以分配负载、节省带宽并提高性能。 更好的 CDN 提供更高的可用性、更低的网络延迟和更低的数据包丢失。 此外，许多 CDN 提供全球分布的数据中心选择，使下载可以从更靠近用户位置的服务器进行（导致更少的网络跃点和更快的下载）。
  • 更多并发下载。 浏览器通常会限制与单个域的并发连接数，之后会阻止其他下载，直到之前的下载之一完成。 从同一站点下载许多大文件时，您经常可以看到此限制。 每个额外的 CDN（在不同的域上）都允许额外的并发下载。
  • 增强分析。 许多商业 CDN 提供使用报告，可以补充您自己的网站分析，并可以更好地量化视频观看和下载。 例如，GTmetrix 有一个出色的网站报告工具，用于监控和优化您网站上加载的资源。

移动 Web 应用程序开发工具

“为正确的工作选择正确的工具”是一句古老的格言，它同样适用于软件开发，就像它适用于任何其他领域一样。 本教程提供并介绍了一些用于移动 Web 应用程序开发的更流行和广泛使用的工具，但请记住，很可能还有其他工具是用于开发移动 Web 应用程序的“正确”工具，具体取决于您的要求和可用资源。

选择正确的 JavaScript 移动 Web 应用程序框架

由于移动 Web 应用程序开发往往会带来许多相同的常见挑战——例如跨浏览器兼容性以及移动浏览器中的 HTML 和 CSS 不一致——已经开发了专门用于解决这些问题的框架（基于 HTML5 和 CSS3）和在各种智能手机和平板电脑上尽可能完美地工作。 这些移动网络应用程序框架中的大多数都是轻量级的，这有助于促进快速移动网络浏览，而不会影响您网站的外观和感觉。

将我们的视野扩展到移动领域之外，如果有一个流行的 JavaScript 框架值得一提，那就是 jQuery。 如果您熟悉桌面版本，我建议您尝试将 jQuery Mobile 用于您的移动 Web 应用程序。 它有一个小部件库，可将语义标记转换为手势友好格式，使触摸屏上的操作变得容易。 最新版本由一个非常轻量级的代码库组成，其中包含许多真正可以改善您的 UI 的图形元素。

另一种替代品 Sencha Touch 也在迅速获得市场份额。 它提供了出色的整体性能，并有助于生成在很大程度上看起来和感觉像原生界面的移动 Web 用户界面。 它的全功能小部件库基于 Sencha 的 ExtJS JavaScript 库。

以下是比较 jQuery Mobile 和 Sencha Touch 时需要考虑的一些关键差异：

• 看和感觉。 一般来说，Sencha Touch 应用程序的外观和感觉比 jQuery 移动应用程序更清晰和优越，但重要的是要记住，这种反应往往是高度主观的。
• 可扩展性。 jQuery Mobile 提供了许多 3rd 方扩展，并且本质上被设计为高度可扩展的，而 Sencha Touch 目前更像是一个“封闭”框架。
• 设备支持。 与 Sencha Touch 相比，jQuery Mobile 目前针对的设备横截面更大。
• HTML“对比” JavaScript。 jQuery 主要以 HTML 为中心（即，在 JavaScript 中扩展和操作现有的 HTML），而 Sencha Touch 编码则完全基于 JavaScript。 （顺便说一下，这是一个例子，说明您的开发团队的技能组合在您选择技术时非常重要。）
• 外部依赖。 jQuery mobile 需要 jQuery 和 jQuery UI 来进行 DOM 操作，而 Sencha Touch 没有外部依赖项。
• 学习曲线。 大多数开发人员发现 jQuery 的启动时间少于 Sencha Touch，这可能是由于大部分 Web 开发人员已经熟悉标准 jQuery 库。

响应式框架和移动 Web 应用程序

近年来，越来越多的响应式框架开始出现，其中两个目前最流行的是 Bootstrap 和 Foundation。 简而言之，响应式框架简化并简化了基于 Web 的响应式 UI 设计和实现，将最常见的布局和 UI 范例封装到一个可重用、性能优化的框架中。 这些框架大多基于 CSS 和 JavaScript，其中许多是开源的、免费下载且易于定制的。 除非您有一组非常特殊的要求，否则使用其中一个框架可能会降低设计和实现移动 Web 应用程序的工作量。

检查两个主要选项 Bootstrap 和 Foundation，需要考虑的一些关键差异包括：

• 目标平台。 虽然 Bootstrap 确实支持移动设备、平板电脑和桌面设备，但它主要面向桌面使用。 另一方面，Foundation 基本上适用于所有屏幕尺寸和类型。
• 浏览器兼容性。 Bootstrap 兼容 IE7 或更高版本，而 Foundation 仅兼容 IE9 或更高版本。
• 布局和组件的多样性。 Bootstrap 的 UI 元素集合比 Foundation 提供的要多得多。
• 自动调整大小。 使用 Foundation，网格会根据当前浏览器的高度和宽度进行收缩和拉伸，而 Bootstrap 仅支持基于标准屏幕尺寸集的预定义网格尺寸集。

调试和测试移动 Web 应用程序

调试移动 Web 应用程序可能会很棘手并且有些令人沮丧，特别是如果您需要四处寻找不同的设备进行测试，或安装 SDK 以模拟（通常不完美）目标客户端平台。

在这种情况下，移动 Web 开发（与原生应用程序开发相比）的一个明显优势是您可以利用标准的基于浏览器的开发人员工具来调试您的应用程序。 根据我个人对远程调试的偏好，我在本应用程序开发教程中推荐的是带有 DevTools 的 Chrome。 其他标准选项包括带有 Firebug 的 Firefox 或 Opera 的 Dragonfly 工具。

我喜欢 Chrome 及其 DevTools 的一些原因包括：

• Chrome 的 DevTools 中的移动模拟器。 这可能是选择 Chrome 来调试移动 Web 应用程序的唯一充分理由。 主要功能包括模拟触摸事件、用户代理欺骗、网络带宽限制、地理位置覆盖、设备方向覆盖和 CSS 媒体类型模拟。
• 交互式编辑器。 能够即时编辑 JavaScript 或 CSS。
• 高级 JavaScript 调试器。 允许 DOM 断点并提供分析 JavaScript 代码执行时间的能力。
• 内置 JSON 和 XML 查看器。 避免需要任何插件来检查服务器响应。
• 直接通过 USB 支持 Android 调试桥 (ADB) 协议。 便于远程调试会话的简单实例化。 （这是谷歌关于如何在 Chrome 中开始远程调试的一个很好的教程。）
• 动态检查资源。 允许您检查应用程序的本地数据源，包括 IndexedDB 或 Web SQL 数据库、本地和会话存储、cookie 和应用程序缓存资源。 您还可以快速检查应用程序的视觉资源，包括图像、字体和样式表。

要测试您的 Web 应用程序的布局和交叉浏览兼容性，您还可以使用一些有用的在线工具，例如 BrowserStack。 只需输入您的应用程序的 URL，选择浏览器、版本和操作系统，您就会在该环境中获得站点的模拟视图（和加载速度）。 用于此目的的另一个有用工具是 CrossBrowserTesting。

包起来

随着当今市场上和使用中的移动设备数量、种类和复杂性的持续快速增长，对有效、用户友好、高性能移动应用程序的需求可能会大幅增加。 因此，能够智能高效地开发这些应用程序将继续至关重要。

在移动设备的 Web、本机和混合移动应用程序选项之间进行选择时，必须考虑许多因素。 每个都有自己的优势，但移动 Web 应用程序通常代表您最有效的开发（以及上市时间）选项。 如果您选择走这条路，我希望这个移动 Web 应用程序开发教程能帮助您更直接、更成功地到达目的地。