【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 2015-01-30
  • 本文字数:14886 字

    阅读完需:约 49 分钟

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

本篇 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

2015-01-30 15:052235
用户头像

发布了 256 篇内容, 共 67.9 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

详解基于 Celestia、Eclipse 构建的首个Layer3 链 Nautilus Chain

西柚子

Spring进阶:定义bean时容易踩的两个坑,连老手也容易犯错

程序员拾山

spring

Docker 环境搭建

流火

Docker

免费赠送测试开发精品课,提高职场竞争力!

测吧(北京)科技有限公司

测试

Matlab实现小波变换

timerring

图像处理 数字图像处理

好用的数据校验&修复工具gt-checksum开源啦

GreatSQL

greatsql社区 gt-checksum

英特尔公司高级副总裁、中国区董事长王锐: 下一个中国是中国!

科技之家

阿里云函数计算助力高德 RTA 广告投放系统架构升级

Serverless Devs

Serverless 高德

软件测试 | Sonarqube架构

测吧(北京)科技有限公司

测试

ChatGPT,开启人机交互新篇章 | 社区征文

柒号华仔

人工智能 openai ChatGPT

【Java优化实战】「微基准系列」带你脚踏实地的进行开发和使用JMH测试和提升应用程序和服务指南

洛神灬殇

Java JMH 3月日更 JMH性能基准测试

5分钟部署百台云上计算机,22支参赛队伍快速接入南网电力调度AI应用大赛

云布道师

无影云电脑

推荐这5个很牛的开源项目,程序员直呼内行

引迈信息

开源 低代码

软件测试 | 测试左移代码分析

测吧(北京)科技有限公司

测试

你应该了解哪些延迟数字?

Kian.Lee

I/O Latency CPU 寄存器 RAM SDD L1\L2\L3

放弃网站不是明智之举,中小企业要选择适合自己的营销模式

石头IT视角

1行Python代码,把PPT转成图片,python-office功能更新~

程序员晚枫

Python Office 自动化办公

四步走搭建自己的专属 ChatGPT(附开源代码)| 社区征文

FN0

AI 话题广场 ChatGPT

用友成为铸基计划-2022标准建设贡献单位!

用友BIP

ListView简单实用

攻城狮Wayne

ListView baseadapter stackfrombottom

Jetpack-Compose 学习笔记(一)—— Compose 初探

修之竹

android Compose android jetpack

软件测试 | Sonarqube scanner使用

测吧(北京)科技有限公司

测试

4.基于Label studio的训练数据标注指南:情感分析任务观点词抽取、属性抽取

汀丶人工智能

自然语言处理 数据标注 实体抽取

这样在 C# 使用 LongRunnigTask 是错的

newbe36524

C# Docker Kubernetes

2022 IoTDB Summit:中冶赛迪工业互联网平台与CISDigital-TimeS(基于IoTDB)在钢铁行业的实践

Apache IoTDB

大数据 开源 IoTDB

2022 IoTDB Summit:宝武智维徐少锋《Apache IoTDB 在宝武装备远程智能运维平台中的使用案例》

Apache IoTDB

大数据 时序数据库 IoTDB

GPT-3/ChatGPT复现的经验教训

OneFlow

人工智能 深度学习 GPT-3 ChatGPT

设计模式之美—接口隔离

GalaxyCreater

设计模式

三天吃透SpringMVC面试八股文

程序员大彬

Java spring springmvc

2022 IoTDB Summit:IoTDB PMC 乔嘉林《端边云协同:Apache IoTDB 全新单机分布式架构》

Apache IoTDB

C++ 线程池

王玉川

c++ 编程语言 多线程 线程池

针对移动应用开发的虚拟讨论_JavaScript_Ralph Winzinger_InfoQ精选文章