针对移动应用开发的虚拟讨论

在过去几年间，移动应用以雷霆之势席卷全球。我们在工作和休闲时间中使用互联网的方式，已经随着移动应用的前进脚步发生了变革。在此期间，许多创建移动应用的技术浮现在世间；而在开发应用的时候，人们也开始考虑“移动优先”的做法。然而，哪怕现在移动设备似乎早已无处不在，未来的时代却只不过刚刚揭开帷幕。我们正在面对全新一代的移动设备，诸如可穿戴设备或众多移动配件——正是它们构成了“万物互联”的世界。我们将面对全新的用户界面，通过它们数据展示及指令接收处理。同时，我们还将看到，越来越多的公司将真正地践行“移动优先”的思路。而在未来数年中，这一切都将影响我们设计、开发和测试软件的方式。

本篇 InfoQ 文章是针对日新月异的移动技术世界撰写的系列文章之一。读者可以点击这里，订阅该系列文章，并接收更新提醒。

移动应用几乎已经无处不在，因此我们不应该忽视，它们作为提供服务的辅助甚至是主要渠道的价值。不过，尽管大家都很清楚，为了获得最大的用户量，我们的应用应该同时支持 Android 和 iOS 系统，但对于具体使用什么技术和工具开发适用于这些系统的应用，却还存在着许多争执。

在这一领域中，众多围绕着“原生应用”、“混合应用”和“HTML/JavaScript 应用”的讨论仍未平息。因此我们邀请了一些业界人士，针对应用开发分享他们各自的观点。在这次讨论邀请对象的名单中，包括了工具栈提供商和开发者：

• Chris Eidhof——iOS 开发者、作家
• Daniel Gallo——Sencha 的工程师
• Brian LeRoux——PhoneGap 创作者
• Maxim Zaks——Wooga 的游戏开发者
• Miguel de Icaza——Xamarin 的 CTO

InfoQ：现在有着数量庞大、类型多样的移动应用开发技术，用于构建基于交叉编译器的原生应用、混合应用或是基于 HTML5/JavaScript 的应用。那么，请为我们讲一讲，你们各自青睐哪些技术，以及为何会对它们感兴趣。

Chris：我们希望能够为应用的最终用户提供最佳体验。基本上，这意味着几乎在应用的各个方面，我们都需要与苹果提供的原生类库非常紧密地结合。我们非常重视流畅的动画，以及让用户能够感觉轻松自在的界面。然而在许多非原生应用中，用户界面都让人觉得还缺点什么。在我看来，只有当开发者正在构建一个图形图像工作负荷较低的游戏时，非原生应用才可能成为一个好的选择。多年以来，我为许多客户重写了应用，他们最初都从 HTML5 应用入手（大部分是因为他们认为这样能够节省资金），但最终的结果都非常令人失望——他们不得不从头开发原生版应用。

Daniel：我下面要说的内容，将会非常具有倾向性，因为我在 Sencha 工作，我们开发针对移动和桌面环境的 Web 应用框架，因此我的答案必然是：HTML5 和 JavaScript。

我相信，这条特别的技术路线能够带来许多便利，例如这里有着非常巨大的开发者人才市场，这些开发者都拥有 Web 技术（JS、HTML、CSS）经验。

此外，在开发过程中，开发者可以非常轻松地在浏览器中，调试和测试编写好的代码，因为在此期间并不需要使用任何交叉编译器，将 HTML/JavaScript 代码转化为对应的原生版本。大部分基于 HTML5 和 JavaScript 的框架还提供了这样的便利：开发者编写一遍应用，就能够让它在各个不同平台上运行——与针对每种设备编写原生应用相比，这将帮助开发者节省时间和金钱。

另外值得指出的一点是，现如今所有的设备都宣称能够支持 HTML5，因此使用 HTML5 开发应用，是能够使应用立即覆盖到所有设备上的唯一途径。

Brian：在我的职业生涯早期，先是为企业编写原生 APP，接下来又重写它们。随之而来的是我对这种类型的环境的厌恶情绪不断积累。我认为，这正是我创造 PhoneGap 的动机，至少是部分动机。不过，颇具讽刺意味的是，我们今天投入了大量的时间编写原生代码，正是为了实现我们的目标：致力于推动 Web 成为开发者的首选平台。

有些时候人们会为此感到吃惊：Web 浏览器以及其中嵌入的插件，都是采用原生代码编写的——与我们编写操作系统时所采用的开发语言相同（一般都是 C 和 C++）。实际上，如果某种 Web 技术没有实现某些东西，那并不是因为它不能，而是我们没有在平台中增加这部分的支持。因此，对 Web 成为“原生”来说，并不存在技术壁垒。

在理解这些东西是如何构建起来方面，我们应该意识到将之视为对立的两面，是一种被误导的观点。此外，想象一下某个外来者闯入到特定某一组利益干系人的利益壁垒中，只是为了看到这种技术在五到十年的时间窗里被抛弃，这并不是我们技术投资的最佳商业战略。更好的方式是基于 Web 的通行守则（web commons）进行构建，或许甚至做出一些贡献，从而让大家都能够获益。

封闭的 GUI 技术一般会表现出阻止、抗拒的态度，但接下来就会随着 Web 技术悄然无声却又持续不断地演进而逐渐淡出舞台。科学技术的最新进展与十年前相比，其间遥远的差距甚至可以用光年来形容。借助于 WebRTC、WebGL，不同的设备 API、WebAudio API，以及 JavaScript 虚拟机方面的进步，Web 目前又一次站在了变革的边缘。这些技术进步将为新兴企业带来重大的机遇，去颠覆旧有的企业。不过从整体来看，移动 Web 尚处于新生儿时期，而这些新能力目前几乎尚未得以利用。

Maxim：我个人更青睐原生应用开发方式，因为它使我们能够聚焦并专注于用户体验，并且在这样的模式下，我们可以轻易地利用平台提供的精华能力。

在构建应用的过程中，开发者如果在心里想着要针对许多平台，将会使得开发变得更脆弱。特别是在开始开发应用的时候，我喜欢专注于针对某一个平台，创建出绝佳的应用，而不去关心其他若干平台的特性集或特殊范式。

Miguel：毫无疑问，我喜欢的是我们现在为人们提供的方式。

我们所做的，是将.NET 和 C#的核心部分带到了 Android、iOS、Mac 和 PlayStation 上，让这一语言变得尽可能通用。这意味着，我们并没有移植以往与.NET 相关的那些用户界面元素。相反，我们针对各个平台，分别创建了 C#类库，让开发者能够充分利用每个平台上的全部特性，让他们创建的应用能够利用苹果和 Google 带来的每一个微小细节。这意味着这些原生平台上出现的所有创新和改进，都将被我们转化并提供给我们的用户。

这样的做法对于开发者很有价值，能够帮助他们精细化调节每个最终细节，并使用平台上的每一个特性。但还有其他很多开发者，他们只是想要让应用经过一次开发就能够运行在所有平台上，或是认为在其应用的用户界面以及与平台的整合中，并非每个部分都需要原生平台的能力。对这些人来说，我们创建了一系列跨平台类库（都在前面所提到的技术之上构建），为他们提供一次编写、四处运行的库。这其中包括我们的 Xamarin.Forms API，它聚焦于构建跨平台用户界面；Xamarin.Mobile，用于访问一个设备上的不同特性（例如相机、加速度计、陀螺仪等等）；CososSharp，用于跨平台 2D 游戏。我们还开发了跨平台的 SQLite，另外我们向 Couchbase 提交了一些贡献，使得同一套 API 能够使用存储、离线和同步存储。

InfoQ：现在有许多讨论，围绕着原生应用与 HTML5/JavaScript 应用的性能差异。即使移动设备和移动浏览器正在变得越来越强大，人们依旧认为原生的速度会更快。那么真实情况是否如此？或者这只不过取决于是否按正确的方式使用了正确的框架？

Chris：从理论上讲，没有任何理由能够证明 JavaScript 就应该更加缓慢。然而，在实践中，我们“总是会”发现这样的现象。JavaScript 是一门解释性语言，运行速度比 Objective-C 慢许多。使用 HTML 进行渲染，无论怎样优化，其性能与原生 UI 相比都有较大差距。我相信，确实能够打造一个足够快的非原生应用，然而现实中几乎没人知道如何实现这一目标。

Daniel：这类讨论已经持续有一阵了。但是性能的问题，其实完全取决于使用某个特定框架构建应用的过程中，开发者是否良好地完成了自己的工作。很多时候，他们只是完成了 Web 应用的构建，而完全没有仔细考虑应该如何组织它，以优化其性能。例如，在屏幕上一次性渲染过多的组件，或是展现过多的数据——它们原本可以打包成较小的分组——都将严重影响性能。

如果能够巧妙地设计应用，基于 HTML5/JavaScript 的方式完全没有道理不能够与对应的原生应用竞争。已经有一些现实世界中的例子证实了这个理论，例如 Sencha 的 Fastbook Demo ，这是一个基于 HTML5 的 Facebook“概念验证”（proof-of-concept）应用，在许多方面它的表现都超过了 Facebook 的原生应用。它展示了人们能够让 Web 应用获得很棒的性能，同时也证明了要实现这一点，需要经过深思熟虑的设计——按照应用而不是网站的思路来设计它。

原生应用同样可能由于采用了糟糕的架构，而出现性能欠佳的问题。例如 Facebook 应用在 iPhone 4 上非常糟糕——因此，我们不应该简单地说“原生应用的速度总是更快”。

毫无疑问，原生应用中的一些特定方面会更快，例如我们知道当前 WebView 的一些性能限制。但除了这些为数不多的特定领域外，大部分商业应用都可以使用 HTML5 混合模式获得理想的性能。此外，针对 WebView 性能的问题，iOS 和 Android 都在新版本中做出了重大改进，而且预计在不远的将来，这一切将得到进一步改善。因此，许多与 WebView 相关的性能问题都将得到解决。

Brian：直接向 CPU 下达指令，是硬件能够提供的速度最快的执行方式。然而这意味着我们应该使用编译语言来编写一切，除非追求执行速度并不总是我们达成软件目标的最优途径！

有时，我们需要考虑开发者的技能、快乐情绪以及 API 的人机工程学。增加一名新的开发者，或者甚至只是加入已有的技术或内容投资，都可能会引发这一选择问题。当我们考虑某种技术的性能时，这些方面的权衡会变得更加复杂。专利软件类的 GUI 工具在持久性方面的过往记录欠佳，而开源的 JavaScript 框架则似乎逐渐进入（又淡出了）流行趋势。

今天，我们可以使用 Web 技术构建一个应用，横跨所有主流平台，并获得与原生应用相比非常接近的体验。有些时候我们则需要混合方法，例如像 Instagram 所做的那样，结合 WebView 和原生菜单。这些问题的答案，正如同现实生活一样，并非那么明确的非黑即白，而是有许多处于灰度区域的情况。如果我们恰巧拥有一支 Swift 开发者组成的一流团队，那么无论出于何种考虑，我们都应该只针对 iOS8 开发应用。如果我们认为 Java 的生态系统在美学上充满吸引力，那么在这种情况下，Android 就是我们及我们的应用应该置身的绝佳环境。而如果我们在.NET 技术方面有着巨大的投入，那么我将会推荐 Xamarin。“具体问题具体分析”是开发者们熟知的一个理由。

最终，如果我们想要接触到最广阔范围的设备及其用户，那么建议的选择便是 Web 技术。如果我们想要获得苹果软件商店的曝光度，又或是想要早点去接触新的 Web API，那么基于 Apache Cordova 的项目（例如 Adobe PhoneGap）则正是我们兴趣所在。

Maxim：我认为，编写原生应用并且无需应对性能问题，对开发者来说是更加便捷和简单的道路。而当我们在开发过程中遇到了性能的时候，原生应用的调优也更容易处理。好的平台生态系统提供了剖析调试的工具，以及解决这些问题的疑难解答。

现在也有一些技术性程序实例，展现了如何使用 JavaScript 开发对性能有重度要求的应用。这些示例令人瞩目，但我怀疑是否有必要。当我们开发应用时，需要面对许多问题，而性能调优是我们最不愿意处理的方面。在我看来，对任何软件开发项目来说，简单性都应该放在第一位。如果我们当前需要开发一个性能要求很高的应用，那么我们应该评估这样的技术：它们证明了自身能够以用户（注：指使用这些技术的开发者）友好的方式，来应对这样的工作需求。

Miguel：毫无疑问，使用原生编译器和原生应用的形式，速度会更快。毕竟，HTML5 和 JavaScript 引擎是在原生的基础资源之上构建的。不过，并不是每个应用都需要系统中大部分底层基础资源的全部能力，而且在很多情况下，利用与否甚至根本无足轻重。

总体来说，HTML 和 JavaScript 在移动设备上的主要问题，并不在于其速度较慢，而是给人的感觉不对。它们没有使用原生特性，行为表征也不同于原生应用，而且有着奇怪的表现。正是这样，才导致一些用户在直观感觉上认为其速度缓慢——他们并不是真的察觉到 JavaScript 代码或 HTML 渲染速度的快慢。Web 应用给他们的感受，就像是一系列相互关联在一起的碎片，每个碎片都必须进行调优。

因此，问题其实在于性能、行为表征、交互，以及能否使用数量庞大的移动 API——要想模拟这些 API 是非常繁琐的事情。

InfoQ：原生开发的一个主要优势，在于最终产出的应用能够为用户提供更好的视觉和感觉效果。苹果通过提供通俗易懂的“iOS 人机界面指南”，来确保大部分应用的视觉和表现比较一致。如果开发者不使用原生 UI 插件，应用或许将无法满足用户的期望。那么你们是否认为这是一个严重的问题？

Chris：这主要取决于应用本身。对大部分应用来说，这确实是个问题。所有的非原生 UI 插件，对用户来说都是需要学习的新鲜事物。例如，如果我们构建一个待办事项清单（todo list），那么我们并不希望用户不得不学习全新的 UI 范式，并因此感受到过于沉重的负担。不过对游戏来说，我们则总是希望能够创造定制化的 UI。此外，一些非常盛行的网站（例如 Facebook），可能也会加入少量定制插件，因为其应用的用户粘性非常高。

Daniel：这与应用的类型密切相关——例如，是传统的 B2C 应用，还是某些休闲类应用，二者差异很大。Web 应用框架可以通过精巧地运用 CSS，来复现原生组件的视觉和使用效果，因此一般来说这不是个问题。

Sencha 的移动框架 Sencha Touch，针对每个设备和平台都提供了一些开箱即用的主题。开发者可以使用它们，将其运用到所有的 UI 组件和交互中，为用户带来能够与原生应用相媲美的视觉和使用效果。这些主题，可以根据用户运行 Web 应用所使用的设备动态设定，而且还可以针对特定的颜色主题或品牌进行定制。

Brian：如果开发者将自身产品锁定在苹果人机交互指南（Apple HIG）的特定版本上，那么他们将发现自己需要针对后续版本重写其应用。而那些构建起“自己的”品牌 (注：指有着自己独特的用户体验设计，而不是紧密跟随苹果人机交互指南) 的开发者们，他们不仅拥有跨平台的应用设计，而且甚至无需操心新平台的发布。Uber 的应用是一个将用户体验扩展至不同设备和平台的绝佳例子。

用户体验是一个重要的问题。软件的成功，毫无疑问与其能否提供良好的最终用户体验密切相关。开发 GUI 时所作的技术选择，将影响许多方面。不过，技术本身显然不会“完成”或“破坏”为提供良好用户体验所进行的工作。在这一点上我们不能偷工减料。要想获得伟大的用户体验，就意味着我们必须雇佣优秀的用户体验专家，并持续不断地进行定性和定量分析。无论进行何种技术选择，要想制作伟大的应用，都不存在任何捷径。

话虽如此，现在已经证实了 Web 技术能够扩展到多种屏幕尺寸、设备方向（横纵屏幕），以及平台的未来实现。

Maxim：任何时候，如果应用不能够满足用户的期望，都将是一个严重的问题。然而，这并不意味着我们如果在应用中引入定制化的 UI，就必定无法满足用户期望。我们只需要让自己的应用中定制的 UI，能够像原生用户体验那样符合用户直觉并使其感到愉悦即可。不过，这永远是个高难度的问题，特别是当我们的应用瞄准了跨平台发行的时候。

而我想要再次质疑这种毫无意义的增加工作量的做法——创建定制化 UI，且使其能够为 iOS、Android 和 Windows Phone 用户提供自然的、直观的体验。不要误解我的意思，确实有一些有意义的例子。比如游戏往往伴随着定制化 UI。另外网站也是运行在不同的操作系统和浏览器之上的定制 UI 的良好例子。

但消费者会做出自己的选择，他们宁愿安装应用而不是访问网站。他们这样做的目的，是为了追寻更好的用户体验。而影响用户体验的最重要因素之一就是 UI。人们希望在熟悉的环境中完成操作。不过当我们设计网站的时候，则略有不同。Web 上没有熟悉的环境，因此参考的样本基本上就是另一个网站。而当构建一个应该解决某问题的应用时，我们应该问自己：定制化 UI 是否能够帮助用户理解并解决这个问题，或是反而增加用户的疑惑。毕竟，别人可能基于原生 UI 开发一个解决该问题的应用，并把我们踢出局。

Miguel：只有当它成为我们业务上的问题，或是阻碍了我们前进的脚步时，才成其为问题。

许多垂直应用永远不会面临任何竞争，因此它们没有动力去解决这些问题。这也正是为何企业级软件如此糟糕，因为它们所处的环境缺乏竞争，或是具有高昂的迁移成本。当我们的软件锁定了用户的时候，我们就不会有动力去改变应用，对其进行进一步的润色加工。在某些情况下，业务成本核算将促使我们打算只提供恰到好处的解决方案，而所谓的“润色加工”则是一些我们明明可以提供但却将要忽略的东西。

只有当面临竞争或业务需求发挥影响力的时候，开发者才会倾向于寻找最简单交付路径之外的解决方案。

InfoQ：应用开发过程中涉及的工作，不仅仅在于编写代码，还包括对功能、性能及用户行为进行测试。你们使用或提供了哪些工具，用于支持这些不同领域的测试？

Chris：我们很少遇到不得不测试性能的情况，因为我们开发的是原生应用，而对原生应用来说，性能一般都不是个问题。站在功能的角度，我们的开发团队与设计师一起，花费了大量的时间去尝试那些感觉很给力的东西。另外，我们非常乐于通过 Twitter 和电子邮件收集客户的反馈，并与许多客户保持联系。因为我们团队规模不大，所以每个人都加入了这个流程中。此外，我们还使用自动化回归测试，以确保我们的产品质量。

Daniel：Sencha 开发者们可以选择使用多种测试工具，其中比较流行的一套工具是由 Bryntum 开发的 Siesta 。Siesta 是一个 JavaScript 单元测试工具，而且它支持对 DOM 进行测试并模拟用户交互。这意味着它能够测试应用中的大部分功能。

Appurify 则提供了另一种测试功能（最近 Google 收购了它），它能够在云端运行的物理设备上，自动化测试应用的 UI 和性能表现。这是一项非常有帮助的工作，因为它意味着其用户（开发者们）将无需购入多种型号的设备，或是管理与这些设备对应的数量庞大的各种配置（例如不同的操作系统版本）。

当需要调试特定的故障或是分析特定的性能问题时，现代浏览器中的开发者工具提供了大量的功能支持，例如记录和分析浏览器窗口内发生的所有活动——包括布局、数据请求、内存使用和事件等。浏览器的开发者工具可以通过插件得到进一步的扩展，例如 Firefox 的 Illuminations 或用于 Google Chrome 的 Sencha App Instpector 。与原生浏览器工具提供的更通用的 HTML5 调试工具相比，它们都针对 Sencha 框架提供了更深入和更智能的分析。这让开发者在使用昂贵的框架（例如 Sencha Ext JS 或 Sencha Touch）的时候，能够快速查看他们的应用中正在发生什么。

Brian：目前我们正在针对 Apache Cordova 和 Adobe PhoneGap 进行大量的手工单元测试。我们的目标是将这套架构整理成可安装的插件。另一方面，用户空间将与 Saucelabs Appium 结合，以便进行自动化测试。另外，我还想要推荐大家看一下 Parashuram’s browser-perf package 。

Maxim：作为测试驱动开发的铁杆粉丝，我编写单元测试以确保应用逻辑的正确性。性能缺陷方面的最主要指征是 FPS 速率的下跌。无论何时，只要性能问题出现，我就会使用平台提供的分析工具，来找出性能关键代码并对其进行重构。单元测试令重构过程变得非常便捷，因为它们能够告诉我，在性能优化之后应用逻辑并未被改变。

现在有许多跟踪服务，让我们能够获得关于用户行为的匿名数据。这些服务一般提供针对特定平台和开发语言的 SDK。

Miguel：Xamarin 提供了一系列为数众多的测试服务，涵盖了从非常简单到非常复杂的测试情景。

测试云是我们的拳头产品。它是一套由约 700 部设备组成的集群——这些设备规格丰富，并搭载着各个版本的 Android 和 iOS——我们将测试云提供给开发者，以便其进行自动化测试。开发者在构建自己的应用时，可以将其上传到我们的测试云，由我们针对开发者希望支持的各个平台运行测试套件，并将测试过程中出现的问题生成一份详细的报告。我们的常规工作，还包括帮助开发者找出不同平台上的差别和问题。例如，最近我们帮助一个客户测试的时候发现，目前流行的 OpenGL 优化中的某个特定类，在使用某款 CPU 的所有设备上均未得到支持。

另一方面，我们还提供了 Calabash 系统，它让开发者能够为其移动应用编写测试套件——就像普通的单元测试框架那样，开发者能够在每次构建自己的应用时，持续地运行它。

InfoQ：管理者们往往表示，将要使用 HTML 和 JavaScript 来实现应用，因为“这么多年以来，我们早就已经很了解应该如何做 Web 应用了”。即使真是这样，一般为桌面端和移动设备开发 Web 应用也会有许多不同，包括基于 JavaScript 的业务逻辑等方面。使用 JavaScript 编写业务逻辑，是否像使用 Objective-C 或 Java 一样容易？人才市场中，能够胜任此类任务的 JavaScript 开发者数量是否足够多？

Chris：我不认为它们之间有什么不同，这三种语言都非常相似（除了一些语法上的细节差异）。

Daniel：我认为，为多个平台开发 Web 应用和编写业务逻辑的难易程度，很大程度上取决于 JavaScript 应用的结构以及所使用的框架。例如，Sencha 同时为桌面和移动应用开发提供了 JavaScript 框架（Sencha Ext JS 和 Sencha Touch）。这两种框架基于相同的机制，而 Ext JS 甚至除了桌面外还支持平板电脑，因此代码可以轻易在桌面、平板和移动应用之间共享。

Sencha Touch 和 Ext JS 都具有 MVC 架构的特性，将应用的代码分离在不同的区域中：模型（对数据进行定义）、视图（用户界面）和控制器（业务逻辑）。业务逻辑永远包含在应用的控制器中，这意味着这些代码始终处于这样一个区域里。同时，与在视图中零散地直接编写业务逻辑片段的方式相比，这也会促进代码的复用。Sencha 对 MVC 的支持与原生 Objective-C 或 Java 开发模式非常相似。因此，在 JavaScript 中编写业务逻辑同样可以是一件非常便捷的工作——只要为它设计合适的结构。

在开发人员求职市场上，就编程语言方面来说，JavaScript 拥有较大的技术人才基础。 IT Jobs Watch 跟踪了英国的 IT 就职市场，统计了固定工作职位（非临时性工作）要求的编程语言经验排行。在为期三个月的统计样本时间段中（2014 年 6 月至 8 月），要求 Objective-C 的职位数量约在 1000 个上下；要求 Java 的数量在 16000 个左右；而对 JavaScript 有需求的则超过 17000 个。

（来源： Objective-C Jobs 、 Java Jobs 、和 JavaScript Jobs ）

Brian：使用动态语言表达业务逻辑更加容易，但是这需要更加严苛的测试，并将功能封装在不连续的（理想情况下应该是分离的）模块中。原生环境中的工具为开发者提供了许多支持，例如代码生成和编译器警告——编译器厂家宣称，后者能够带来更好的软件。然而实际上并非如此，它只是造就了更加懒惰的开发者。他们并不测试自己的工作，而是将它抛给与开发部门平行的独立 QA 部门，由其在完全不同的环境中进行测试。动态语言环境则会强制性推动创建和维护更好的测试套件，从而促使自身演进为更高质量的解决方案。世界上那些业务量最大的网站都是用这种方式构建的。

在打造绝妙软件用户体验的道路上没有捷径。我们需要在编写代码过程中保持严谨和自律的路线，以获得良好的结果。但是这与原生还是 Web 编码方式无关。两种方式都能够从全面测试、持续集成和持续交付中获益。

Maxim：我上一次涉足 Web 开发，使用 HTML 和 JavaScript 是在 2012 年。彼时我置身于一支技术团队，为移动和桌面端的家居自动化平台开发富互联网客户端。在那段时间里，我注意到了以下现象。对桌面环境的 Web 前端开发者来说，主要需要完成两项任务：

1. 开发应用；
2. 使其能够适配老版本的 IE 浏览器（大部分通过按需引入修补性的代码片段来实现）。

而移动环境的 Web 前端开发者同样也有两项任务：

1. 开发应用；
2. 精简掉应用中的所有非必要功能，以便它能够在糟糕的网络连接和低端 Android 设备上运行。

或许在最近两年里，世界的面貌发生了翻天覆地的变革。然而如果没有的话，那种“这么多年以来，我们已经很了解应该如何做 Web 应用了”的论调就依旧不适用。在桌面或移动环境下开发、构建 HTML 和原生应用，都应该被视作互相间完全不同的工作。在学习了如何构建桌面 HTML 应用后，我们依旧需要学习如何构建移动版的 HTML 应用。即使我拥有构建原生移动应用方面的经验，在进行 HTML 应用开发时，依旧需要学习一些东西。

Miguel：我不认同这个问题里的前提条件。

一些管理者更熟悉伴随 JavaScript 而来的那些微妙的问题，并且倾向于每次都选择更好的语言和 IDE，以便在应用的整个生命周期帮助开发者：从代码完成到智能感知、自动测试、重构工具、长期维护代码库，乃至到能够让团队轻松地成长，而不会让他们自己迷失在意大利面式代码（spaghetti code，指混杂难懂的糟糕代码）的海洋中。

JavaScript 的主要优势在于其普适性，但是 Google 和微软早就认识到，在面对构建复杂系统，并且需要使用很多我刚刚列出的特性时，JavaScript 语言就显得苍白无力了。因此它们分别在 JavaScript 的基础上开发了新的语言以解决这些问题（Google 的 Dart 和微软的 Typescript）。

从目前来看，JavaScript 最大的优点在于，许多人都可以把它与其他一些东西整合在一起。

InfoQ：移动开发不再只局限于智能手机和平板电脑，许多新的设备和界面形式正在浮现。让我们考虑一下那些可穿戴设备，比如 Pebble、Google Glass 或 Gear Fit，在这些设备上，我们将同时面对数据呈现以及全新的设备交互方式这两方面的挑战。原生 SDK 让开发者能够访问那些设备相关的特定功能。但是，考虑一下不远的将来市场上，可能会出现的非常广泛、多样化的设备类型和界面，HTML 和 JavaScript 是否能够覆盖它们并提供支持？

Chris：长远来看，HTML 和 JavaScript 或许最终能够做到。这完全取决于制造商以及他们打算开放出来什么东西。在可以预见的未来，毫无疑问原生开发将比 HTML 有着更多的可能性。

Daniel：原生 SDK 的问题在于，我们只能针对特定平台开发特定的东西。而对 HTML 和 JavaScript 来说，世界上数量庞大的个人设备，都能够渲染基于 Web 的内容。

在 Sencha，我们总是努力支持新出现并逐渐流行起来的设备和平台，而我们的一位工程师完成了一项概念验证，确认了传统的结合 Cordova 打包的 Sencha 移动应用能够在 Google Glass 上运行。

这表明，只要对已有的基于 Web 的应用做一些微小的调整，就能够使其能够适配到更小的设备上。显然，对于 Pebble 或 Gear 2 这样的设备来说，我们都被限制在更小的屏幕空间中，因此设计师或开发者需要更加审慎地思考，需要在屏幕上一次性呈现多少组件，而不是让太多内容淹没设备和用户，以至于令其无所适从！

Brian：恩，毫无疑问，Android Wear 和 Google Glass 都使用了嵌入式 WebView（但不支持 JS）以渲染其界面。这证明了 WebView 确实非常适合横跨不同屏幕尺寸进行渲染，而且尤其擅长以文本为核心的展现任务。Pebble 拥有一套 JavaScript SDK。可穿戴设备的未来将与 Web 结合非常紧密，而界面也将追随这一趋势。

Maxim：当出现新设备，且制造商决定面向第三方开发者开放和提供原生 SDK 的时候，制造商应该表现出自己的某些愿景。我认为，硬件 / 操作系统制造商所展露出的清晰明确的愿景，将为第三方开发者带来巨大帮助。如果在制造商的规划中，第三方开发者将针对其平台开发 Web 应用，那么一切都没问题。如果制造商不这么打算，但第三方开发者却使用浏览器作为后门进入这个平台，那么对应用开发者和用户来说，这都将变得十分痛苦。

InfoQ：移动应用针对的往往是个人用户，对这个群体来说，应用能够快速、定期地提供涵盖新功能和 Bug 修订的升级版非常重要。一般来说，开发者运用敏捷过程以实现这一目标，并力争进行持续交付。从敏捷的角度看，HTML 和 JavaScript 似乎具有显而易见的优势——在原生应用开发的世界里，是否也有能够与之媲美的东西？

Chris：如果将移动应用与移动网站进行对比，那么我们会发现明显的差别：对移动网站进行变更总是更容易。而如果我们将原生应用与 HTML5 应用（例如使用 PhoneGap 或类似技术创建），则没有区别，至少在苹果平台上，无论使用二者之中那种方式，苹果官方均不允许已安装应用下载新的代码。尽管站在技术上看，HTML 应用本身具有持续更新的能力，但这却是被禁止的。

Daniel：在开发原生应用的过程中，我们可以使用诸如 TestFlight 等服务向β用户推送更新。在企业环境中，还可以面向企业内部用户，使用 TestFlight 进行应用的大规模部署，从而绕过苹果软件商店。这意味着用户无需等待应用审核周期，就能够获得新的版本。

Brian：如果尝试使用混合开发，那么我们就能够利用持续交付的优势，而不必受限于苹果软件商店的审核。苹果最近放松了在这方面的姿态。在这个问题上我显然是有立场偏颇的，但是说实在的，混合方式结合了两种模型中各自最佳的部分。我们能够享受通过苹果软件商店分发获得的曝光度，享受原生平台结合插件的能力，并且还能够按自己的意愿将代码推送到产品中。

Maxim：这完全取决于我们正在构建的应用。对于个人用户非常关注频繁升级这个话题，我持有不同意见。他们需要的是应用能够工作。如果我们在第一个版本就能够提供良好的用户体验，那非常好！而且这对于软件商店中的应用评分也更有利，因为每个版本的用户评分都是从零开始的（注：这意味着，每次升级后，显示的应用评分都会被归 0，这可能会影响新用户对应用的选择）。

不过，发布用来解决 Bug 的更新是非常重要的，而提供新特性或许也会有所帮助：）。从这个角度看，Web 拥有最好的交付机制。如果我们构建一个 Web 应用，那么我们想要多么频繁地发布都可以，而且我们可以进行局部回滚、A/B 测试等等。不过，请注意我说的是 Web，而 HTML 和 JavaScript 并不等同于 Web。通过苹果软件商店分发应用时，苹果不允许在审核通过后，应用内部再下载任何代码。这意味着，如果我们将 HTML 应用打包成原生应用并在苹果软件商店中发行，几乎就失去了我刚才提到的便利。我们依旧可以使用 Web 来加载配置，并进行诸如 A/B 测试等工作，但是在应对紧急发现的 Bug 时，这种方式并不会为我们提供帮助。

Miguel： 原生开发者最多只能够在发现重大缺陷的时候，提示用户进行升级。

这意味着，当我们遇到类似 IBM 最近发现的那个漏洞（恶意用户可以劫持展现的银行信息）一样，尽管对于使用 HTML 和 JavaScript 开发并通过原生容器封装的应用来说，可以将 HTML 和 JS 代码完全托管在服务器侧并进行更新，但数量庞大的此类应用，仍旧需要对容器本身进行升级。

不过，这里也有其他一些替代方案，我们可以让服务器来控制那些呈现在用户面前的内容——通过传输 HTML 和 JavaScript 或通过传输其他形式的结构化数据。

InfoQ：“JavaScript 无处不在”——这往往被认为是在服务器端使用 JavaScript 的一项优势。如果服务器端和客户端使用相同的技术栈，开发者可以复用代码和工具。那么在移动应用领域是否也有类似的可能？在原生世界中，是否同样能够复用代码和工具？

Chris：在进行 Mac 桌面编程的时候，我的很多技能和代码都得以复用。而且我还使用 Objective-C 编写了服务器端代码，并且正在尝试使用 Swift 来进行服务器端开发。

Daniel：代码复用是有可能的，因为诸如 Cordova 等工具可以被用来创建混合应用，因此开发过程与普通 Web 应用几乎一致。

但是这里（混合开发）的主要优势是，应用开发者不必学习不同平台上的原生语言。对服务器端 /Web 而言，只有一种变体（服务器端），但却能覆盖 3 种或更多的原生平台。在跨平台交付时，HTML5 显然是更便捷的途径。

Brian：我们再次享受到了混合开发带来的潜在便利。我们在客户侧制作了大量的模板，接下来还会在服务器侧复用它们。其它不这么明显但同样令人振奋的是，我们可以同时在客户侧和服务器侧运行我们的测试套件。总的来说，让 JS 无处不在是一个重大的胜利，特别是这门语言正随着 ES6 标准逐步成熟。

Maxim：在代码复用的时候会遇到一个问题——耦合。当我们在服务器端和客户端使用相同的代码时，我们必须先检查一下是否会对服务器端的实现造成影响，而后才可以变更客户端。当我们拥有一个长生命周期的产品时，这会显得尤为麻烦。

在移动应用领域也存在相同的问题。如果我为若干平台编写一款移动应用，并复用其中大部分代码，那么我实际上创建了一个一体化的核心。在这种情况下，每当我将要对它做一些变更，都会影响到所有的平台。在前一个话题中，讨论了交付机制的问题，它因我们选择发布的不同平台而异。Web 是最快速的交付机制，而苹果软件商店则是最慢的。有一句老话说：“链条的强度取决于其最薄弱一环”。在进行跨平台开发时，我必须聚焦于各个平台中的最薄弱环节。这意味着，当我改变了业务逻辑中的某个关键点的时候，我需要等到苹果应用商店的发布完成后，才能够改变我的 Web 应用。而如果我要做一些复杂的视觉展现（UI），则必须考虑我希望支持的性能最低的 Android 设备。

我并不是说代码复用不好，只是想指出，任何事情都有其代价。

Miguel：是的，我们在客户端和服务器端两侧同时使用 C#或 C。

InfoQ：在最近几个月里，应用内建插件进行分析的做法逐步兴盛流行。你们是否使用了一些类似于 Splitforce 的工具，另外对于产出完美的产品，分析到底有多重要？

Chris：我们有自己的分析系统。我们相信，分析有助于获得用户行为方面的洞见。我们还通过邮件、Twitter 和线下方式与用户进行大量沟通。这一点甚至更为重要，因为它促使我们站在大局角度，获得更好的视野。而且它有助于我们理解，我们的应用如何与用户的日常工作流相互契合。

Daniel：取决于正在开发的应用的类型。在理解最终用户如何使用我们的应用方面，分析工具能够提供有力的帮助；对于找出应用中哪些部分相比其他更受用户青睐方面也是如此。这样我们就能够将未来的开发精力聚焦在应用中的流行部分，而不是挥霍在那些用户较少使用的部分。

Brian：既然问到了这个问题，我想介绍一下我们的 Adobe PhoneGap Enterprise 产品，它与 Adboe Marketing Cloud 相互结合。它能够针对内容优化及内容发布到产品应用中的工作流程，进行深入分析和 A/B 测试。基本上这项工具非常贴心。：）

Maxim：如果应用想要取得成功，A/B 测试和商业分析非常关键，而在我最近两年投身的移动游戏开发领域里尤其如此。

人类其实并不是一定要玩游戏，游戏并非生存的关键要素。我们玩游戏是因为喜欢——我们喜欢这种体验。A/B 测试和商业分析帮助我们针对目标用户群体，找出最佳用户体验。离开这些工具，我们只能够对不同的功能特性是否能取得成功进行押宝。而对于一家谋求可持续发展的企业来说，这是无法接受的。

Miguel：这块领域现在拥有来自诸如 Twitter、Amazon、Google、Microsoft 等众多公司的产品，有助于了解用户如何使用自己的软件。现在，这已经是一块非常成熟的领域，而且这么做已经成为标准做法而不是个例。

参与讨论的成员

Chris Eidhof是一位来自德国的软件开发者，目前定居于柏林。他的大部分精力投入在 iOS 和 Mac 应用开发方面，例如 Deckset 。此外，他还创立了 UIKonf 和 objc.io ，并撰围绕着使用Swift 进行函数式编程写了一本书。

Daniel Gallo拥有 9 年以上的开发经验，曾经使用多种不同技术开发基于 Web 的创新型应用，并且尤其精通 ASP.NET 、C#和 JavaScript。在 2012 年初，Dan 加入 Sencha 成为其欧洲销售工程师之一，从事 Sencha 产品线的售前技术支持工作。

Maxim Zaks曾在若干 Java Enterprise 和 Web 的项目中担任开发和咨询的角色，并曾出任某个基于 Eclipse 的 IDE 开发项目的首席开发人员。现在，他正在为 Wooga 开发 iOS 平台上的休闲游戏。

Brian LeRoux是 Adboe PhoneGap 的首席产品经理及对外代表，同时也是 Apache Cordova 的 VP。他是 Node Firm 的会员，也是一位移动 Web 黑客和啤酒爱好者，并且曾针对一个 JavaScript 问题与其他许多人一起在 wtfjs 上撰文。读者可以在他的个人网页上了解更多信息。

Miguel de Icaza是 Xamarin 的联合创始人，Xamarin 创作了 MonoTOuch 和 Mono(针对 Android 类库)，让开发者能够使用 C#，为 iPhone、iPad 和 Android 开发移动应用。在创立 Xamarin 之前，Miguel 缔造了 Gnome 和 Mono，并与他人共同创建了 Ximian。

在过去几年间，移动应用以雷霆之势席卷全球。我们在工作和休闲时间中使用互联网的方式，已经随着移动应用的前进脚步发生了变革。在此期间，许多创建移动应用的技术浮现在世间；而在开发应用的时候，人们也开始考虑“移动优先”的做法。然而，哪怕现在移动设备似乎早已无处不在，未来的时代却只不过刚刚揭开帷幕。我们正在面对全新一代的移动设备，诸如可穿戴设备或众多移动配件——正是它们构成了“万物互联”的世界。我们将面对全新的用户界面，通过它们数据展示及指令接收处理。同时，我们还将看到，越来越多的公司将真正地践行“移动优先”的思路。而在未来数年中，这一切都将影响我们设计、开发和测试软件的方式。

本篇 InfoQ 文章是针对日新月异的移动技术世界撰写的系列文章之一。读者可以点击这里，订阅该系列文章，并接收更新提醒。

查看英文原文： Virtual Panel on App Development