转载

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

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

本篇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前端开发者来说，主要需要完成两项任务：

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

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

开发应用；
精简掉应用中的所有非必要功能，以便它能够在糟糕的网络连接和低端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

正文到此结束