再论:web app和native app之争 混搭可能引领未来?

前文,我提到了以HTML技术为基础来开发客户端应用程序的优点。首先,最重要的当然是跨平台的可移植性。个人计算机渐渐地不再是主要的运作平台,移动设备诸如手机、平板计算机数量迅速增加,而且提供随时可用的便利性;Windows也渐渐势微、Web成为网络服务应用的主流;而iOS及Android也都各拥山头、互不相让。在这种情况下,在各种平台上的可移植性就成了一项关键的优势。

而现今的网络服务自从进到Web 2.0时代后,改版的速度更是远较从前来得飞快许多,此种模型可以因应频繁的功能修改及扩增。

Native app

此外,由于在服务器端的技术,Web已经成为主流的平台,不仅相关的技术,诸如规模可扩充性、稳定度、容错、等等,都已经有一定的成熟程度,而且大多开发团队中的系统管理者、开发者,也都很熟悉、习惯在Web平台上作业。这使得即使你要开发的是移动设备上的App,也都能尽量运用相同、已被既有团队成员熟悉的技术来达成。而且过去开发团队所累积的既有资产,像是链接库或应用程序框架,也都能便利地套用。

正因为以HTML技术为基础来开发客户端应用程序,有这些极具吸引力的优点,这才使得许多开发团队纷纷决定采用。正如过去Facebook,以HTML5技术来开发iOS及Android上的App一样。

用HTML开发App所面临的挑战
不过,这种架构并非全然只有优点而无缺点,否则Facebook也不会决定弃用,而且宣称使用HTML5来打造移动设备上的App是他们公司创立以来最大的决策错误了。那么,使用这种模型的缺点,又有那些呢?

首先,以HTML技术为基础的客户端应用程序,提供的用户体验可能弱于原生的应用程序,许多丰富的视觉效果或是与用户的互动方式,都会受限在HTML的本质,而没有办法做到。

相反的,原生的App可以直接运用原生的API,来运用原生平台就提供的视觉或操作控制,也就能发挥该原生平台最大的机能,不致于受限在HTML的本质之上。

其次,也可能是一个关键的因素,那就是效能的问题。原生的App在呈现任何信息时,都是使用原生的组件来达成。而不论是处理来自使用者的输入,或是在接口上做出任何视觉效果的变化,都是使用原生的组件、API,因此,其效能便是原生平台上所能提供的最佳结果,因为中间再也没有任何其他的中介层,足以影响效能。

相反的,对于使用HTML技术的应用程序来说,是把浏览器视为一个运行的平台,所以整个浏览器呈现HTML页面的引擎,以及执行JavaScript程序的引擎,就成了一个很庞大的中介层。这个中介层势必具备一定的通用性,以便可以提供HTML通用性的作用。

而通用性通常影响到的就是效能,因此介于原生层和应用程序之间的这个中介层,就会影响到最后实际运行的效能。

举例来说,当你想要在智能型手机上呈现一个很长的清单时,使用HTML来呈现这信息,最终就有可能受限在手机浏览器的呈现效能,而使得画面的卷动效果不是十分流畅,甚至会有类似像”卡卡”的感觉。相反的,若是你自行用原生的用户接口来实作这件事,就可以在清单呈现上做很多效能优化的动作。针对不同的用户接口特性,量身打造最有效率的呈现方式。

HTML App的强项

以HTML技术为基础的呈现方式,最适合应用的情境,就是用来呈现图与文混杂的信息。

HTML本身就像是个排版的语言,这使得它很容易可以因应不同尺寸的呈现画面来适当的排列若干图与文的信息。

对于想同时兼容个人计算机、各式屏幕尺寸平板计算机、智能型手机上的图文信息呈现的App,以HTML技术来实现是相当理想的。

开发者不需要设计复杂的呈现机制,也不用理会各种排版的规则,只要交给HTML以及已经熟悉在各种不同画面尺寸上呈现信息的设计者,就能妥善的将丰富的图文信息在画面上排列美观。不过,这样子的便利要付出的代价往往就是效能。

在Fastbook对决Facebook的例子里,我们看到Fastbook一样采用HTML5技术,也做出了速度极快的App,但这并不是说HTML5就能比原生的应用程序来得快。Fastbook在资料的加载等存取上下了不少功夫,因为他们观察到Facebook效能的问题,不单发生在HTML5的信息呈现上,更有其他的环节与效能息息相关。

这说明了,之前以HTML5技术写成的Facebook App其效能不彰虽是事实,但原因也不完全出在HTML5之上。

我们只能够说,若是能经过有效的设计及调校,以HTML5技术写成的App是可以提供足够流畅的效能。不过,原生App的效能所占的优势也是肯定存在,这都是本质上存在的特性。当然,这也提供一个反思,那就是即使采用原生的方式来开发App,倘若其他的部份仍然存在效能低落的设计,整体运行的效能一样不会理想。

混合式App开发的兴起
在了纯原生及纯基于HTML技术两种方式之外,还有一种方式现在也颇为流行,就是将二者混合在一起。这种混合的方式,便是希望同时取得二者的优点,当然也就是尽可能避开二者的缺点,让两种方式互补。

在这种混合的模式中,需要呈现大量图与文信息混杂、或是时常需要动态改变的部份,就利用HTML的方式来呈现,因为这正是以HTML为基础的模式的优势。相反的,需要效能、需要善用原生平台上组件特性,或是只有透过原生的API才能做到的功能,就利用原生的程序代码来实作。

在混合的模式下,主体或许还是以HTML的浏览器组件,但是透过建立JavaScript程序,以及原生程序代码之间的沟通管道,就可以一方面在JavaScript端启动原生程序代码的执行,并且可以传入参数及取得回传结果,也可以让原生程序代码回过头来,再呼叫浏览器组件中的JavaScript程序。只要能够让原生端及HTML端的程序代码相互沟通,那么就可以达成这种混用的模式。

透过混用的模式,就可以依据应用程序本身的特性,分别从原生的部份以及HTML的部份撷取其长处,同时规避其缺点,可以说是在二者之间取得平衡点的作法。

原生 vs. HTML vs. 混合
在这个简短的系列文章中,我们看到了客户端应用程序逐渐运用HTML主流技术的一个趋势,也分别看到了原生应用程序,与以HTML技术为基础之应用程序的优缺点。

在现今平台众多、功能变化迅速的环境下,使用HTML技术于客户端已成一种重要的应用模式。不过,受限于较简单的使用者体验、无法使用原生支持,以及效能上需要更加费心等种种的条件,原生的应用程序仍然有其发展的空间。

究竟要采用那一种模式,端视应用的环境及条件,并没有那一种模式能够取得绝对的支配性地位。此外, 混用两种模式的方式可以兼收二者的优点,也是一种可以考虑的方向。

移动信息化交流QQ群:一号群:211029692 二号群:344692795 CIO交流群:316076815(需认证)

移动化问答社区:wenda.yidonghua.com



1 星2 星3 星4 星5 星 (还没有打分,快来打分吧!)
Loading...
 
已有 0 条评论
返回顶部

无觅相关文章插件,快速提升流量