外物互联:针对移动应用开发的虚拟讨论

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

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

[[127383]]

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

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

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

记者:现在有着数量庞大、类型多样的移动应用开发技术,用于构建基于交叉编译器的原生应用、混合应用或是基于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能 够使用存储、离线和同步存储。

记者现在有许多讨论,围绕着原生应用与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是非常繁琐的事情。

#p#

记者原生开发的一个主要优势,在于最终产出的应用能够为用户提供更好的视觉和感觉效 果。苹果通过提供通俗易懂的“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:只有当它成为我们业务上的问题,或是阻碍了我们前进的脚步时,才成其为问题。

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

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

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

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系统,它让开发者能够为其移动应用编写测试套件——就像普通的单元测试框架那样,开发者能够在每次构建自己的应用时,持续地运行它。

记者管理者们往往表示,将要使用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 JobsJava 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***的优点在于,许多人都可以把它与其他一些东西整合在一起。

记者移动开发不再只局限于智能手机和平板电脑,许多新的设备和界面形式正在浮现。让我 们考虑一下那些可穿戴设备,比如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应用,那么一切都没问题。如果制造商不这么打算,但第三方开发者却使用浏览器作为后门进入这个平台,那么对应用开发者和用户来说,这都将变得十分痛 苦。

记者移动应用针对的往往是个人用户,对这个群体来说,应用能够快速、定期地提供涵盖新 功能和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或通过传输其他形式的结构化数据。

#p#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参与讨论的成员

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

 

 

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

 

 

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

 

 

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

 

 

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

 

 

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

英文原文:Virtual Panel on App Development

译文出处:InfoQ

责任编辑:闫佳明 来源: infoq编译
相关推荐

2011-05-11 09:47:14

mobl移动web开发

2019-08-29 09:00:55

开发Flutter框架

2014-07-28 09:15:02

开发框架

2013-10-22 09:54:42

开发者应用

2012-03-19 21:25:47

2012-12-21 14:59:52

Tabris

2014-07-30 14:52:32

应用App产品

2013-09-24 09:52:33

移动应用虚拟化

2013-01-05 10:28:18

虚拟化移动应用

2012-08-30 09:41:23

移动应用开发

2015-08-19 10:07:18

云应用移动云应用云应用开发

2013-03-15 13:51:31

在线教育移动互联网

2014-05-30 17:53:43

移动互联网

2013-08-26 10:29:22

移动互联网入口应用

2011-08-02 09:04:02

移动应用开发

2016-09-13 16:47:33

移动·开发技术周刊

2011-05-19 10:46:58

Office应用访谈金山

2012-06-01 14:57:00

移动应用开发7个致命错误

2013-09-10 13:30:51

移动应用移动开发应用缺点

2012-01-18 14:29:42

移动Web应用开发
点赞
收藏

51CTO技术栈公众号