Gartner 網路應用程式 行動應用服務 智慧手機 智慧型手機 Smart Phone API 原生碼

提升手機使用者經驗 原生/網路應用程式各有所長

2012-02-06
廠商搶攻龐大的智慧型手機應用程式服務商機的同時,卻會面臨該開發原生或網路行動應用程式的抉擇。原生行動應用程式受到蘋果iPhone大力鼓吹,建立更高標的使用者經驗;而網路應用程式則具備成本優勢,如何選擇端視各廠商業務目標,以及對使用者使用習慣的調查。
大多數的企業會同時提供網路(Web-based)與原生(Native)行動應用程式服務,決定的因素包括使用經驗品質、應用程式的複雜度、目標平台、成本、靈活度與風險。 目前的網路技術與架構,包括HTML5,皆有助提高行動網路應用程式的範圍與豐富性,但不會取代原生碼(Native Code)。

打算提供消費者行動服務的客戶經常詢問可否發展精簡型(網路)或原生行動應用程式。

本文中,將網路應用程式定義為在行動裝置上透過瀏覽器使用的軟體;原生應用程式則定義為從網路商店下載安裝到行動裝置上的軟體(表1)。

業務目標/使用習慣為關鍵

研發原生或網路行動應用程式的任何決策,皆須取決於業務目標和顧客使用習慣。

業務目標提供重要決策資訊,如顧客身分、解決方案的預期壽命、可接受的風險程度與成本限制等。不見得每次都能訂出全面與量化的行動業務目標,但即使是不甚完全的目標亦有益做出決策。

行動服務的目標客群會影響技術的選擇,尤其是在20112012年,許多客戶尚未擁有智慧型手機。了解高價值顧客的使用裝置和習慣非常重要,若可能,應先調查顧客使用的手機類型及是否使用行動網路或下載行動程式。

原生應用程式使用經驗品質較佳

原生應用程式的主要優勢之一是提供最好的使用經驗。原生應用程式可讀取感應器,如全球衛星定位系統(GPS)衛星導航系統與加速度計(Accelerometer),並可使用複雜的繪圖、觸控螢幕與手勢、提供先進的視覺效果,如擴增實境(Augmented Reality)。未來可期待HTML提供更多這類的功能,如同原生應用程式可滿足最佳使用經驗。

Android、蘋果(Apple)iOS、Symbian和RIM等行動作業系統(OS)演變迅速,每年都推出一款以上的新平台。新增的應用程式介面(API)可增加新平台功能與雲端服務,如導航、情境、網路商店支付與行動商務。行動作業系統演變將超過HTML標準演進的速度,因此原生應用程式可使用更進階的功能。情境式行動應用程式須即時監控使用者行為並主動發出通知,此動作須取得裝置代碼,因此不適合透過網路進行。

網路應用程式具成本優勢

了解應用程式的使用者數量對成本效益分析相當重要。能執行動態轉換的行動網路工具可支援絕大多數的手機,包括功能型手機(Feature Phone),甚至智慧型手機專屬網站可以服務的用戶數,遠比單一原生應用程式版本還多。在許多情況下,程式設計師必須在用戶規模和使用經驗中擇一選擇。

行動網路應用程式的每位用戶成本較低,因為只要花一次費用,便可支援許多裝置,因此目標客群是鎖定一般的大眾。原生應用程式的成本則會隨著複雜度而變化,目標客群通常較為少數,如特定平台用戶。隨著智慧型手機的普及化,成本結構也將有所變動。

另外,行動網路應用程式較具彈性,可以在伺服器上直接變更程式和立即發布。原生應用程式較不具彈性的原因包括,其通常是透過網路商店提供,申請與審核流程需數週才能完成,一旦提供新版的應用程式後,使用者必須進行安裝,舊版可持續使用一段時間,以及若須支援多平台,原生應用程式的開發和測試流程較為複雜和緩慢。

網路應用程式技術/商業風險較低

原生應用程式涉及的技術風險比網路應用程式高,因為開發的過程較複雜、風險較大,甚至測試本身就很複雜。如觸控螢幕、衛星導航系統和加速度計等涉及使用者經驗的應用,不同的平台或許須開發多種應用程式版本。

一些行動網路程式轉換工具(Mobile Web Adaptation Tools)是由發展完善且在業界擁有良好聲譽的公司所提供,因此,要找到商業風險低的工具及供應商是有可能的。不需額外開發工具的行動網路程式,可能承受的風險甚至更低。

使用多平台開發工具的原生應用程式,若是創新但規模較小的供應商,開發風險通常較高。企業得在以下兩者中做困難的抉擇,一種是安全、但費用相對較高的方式,如使用原生軟體開發工具包(SDK)與工具開發不同的應用程式版本。另一種是速度較快、費用較低,但風險較高的方式,如使用小型供應商的多平台開發工具。在評估供應商風險之際,企業不僅要考量供應商未來生存的可能性,也須評估其支援能力。

網路狀況影響網路應用程式效能

行動網路應用程式通常須要搭配好的手機網路或無線區域網路(Wi-Fi)訊號,因此企業須了解消費者使用情境。採用原生或網路應用程式還需要其他操作上的配套,如手機的電池壽命等,另一常見的問題是網路效能,原生應用程式可被寫入以除去許多網路效能變數,但有些網路應用程式會隨著網路的品質造成效能上的差異。

行動網路的安全性相對較佳,係因留在行動裝置的資料通常很少或完全沒有,不過安全或驗證的選項數量通常少於原生代碼,原生應用程式可支援更廣的安全策略。

多數情況下,支援網路應用程式較容易,因為客戶端裝置較不容易出錯。原生應用程式的支援部分則較為複雜,尤其是支援Android等較不完整平台時。不過,隨著網路應用程式複雜化,使用客戶端代碼(Client-side Code)開發比重越來越高,支援情況將變得越來越複雜,兩者的差異將縮小。

以消費性應用程式為例,假設一個競爭對手推出原生應用程式,多數行動網路應用程式便相形見絀,即使都提供相同的功能。蘋果(Apple)iPhone等部分平台鼓勵開發商開發原生應用程式,以使用更多的平台應用程式介面。這為使用者期待設下高標準,讓網路應用程式變得較不具競爭力。

不過,開發原生應用程式比開發行動網路應用程式需要更進階的技術,主要是因為工具市場高度分散,這類技術較為缺乏。

行動網路應用程式開發方式

不同的行動網路應用程式開發方式,造就不同的應用程式特色,以下將一一說明。

利用具有網路功能的行動應用開發工具
  用於創造行動網路應用程式的開發工具,須投注大量的資金與努力,才能開發出適用於行動裝置的高品質產品;此類型的部分工具能同時開發網路與原生應用程式。

基於JavaScript架構與儲存庫
  有助開發商創造更複雜、客戶端應用程式,有時可使用部分底層的平台API。

透過網路轉換或行動入口工具
  這類工具根據不同裝置的需求,利用現有網路或入口網站動態轉換內容或網站架構。特色是能夠快速部署,但品質不如專為手機用戶優化的應用程式。

建立智慧型手機專屬網站
  搭載先進HTML瀏覽器的智慧型手機,可以讀取傳統網站的頁面,只要內含vanilla HTML,以及不支援Flash和外插式裝置等功能即可。假使能知道使用此類裝置的用戶數量,就可以利用現有工具創造一個網站,為手機用戶提供小型、簡單的網頁服務。

無須做任何事
  亦即假設用戶會用自己的手機去讀取現有的網站,所以無須進行任何程式開發。雖然是免費的,但這種瀏覽方式不太能提供令人滿意的使用經驗。

原生應用程式開發方式

與行動網路應用程式開發方式相同,不同的開發方式,亦會發展出不同的原生應用程式,以下介紹原生應用程式開發方式。

使用原生平台軟體開發工具
  提供最深度的整合與最豐富的功能,但僅限於單一平台。

一般性多平台開發工具
  可支援一種以上的行動平台,不過,「寫入一次便可到處執行」的目標仍處於想像階段,因為犧牲讓步無法避免。亦即有些工具提供行動裝置共通的API,但會讓單一來源應用程式犧牲掉某些特定平台功能,因此無法開發出能與原生軟體開發工具相互競爭的應用程式。有些工具可以讓開發人員呼叫原生平台的API創造更具競爭力的應用程式,但條件是須要支援各應用程式的多種變數。不過,目前大部分的多平台開發工具尚未能支援全部的智慧型手機平台。

特殊應用多平台開發工具
  用於開發特定應用程式的工具,如零售商店前端使用的應用程式,雖然不具普遍性但有助提高生產力。

Java ME
  行動Java近幾年較不流行,因為太過分散,且像原生代碼般複雜,無法提供原始API功能或多種平台工具。不過,行動Java適用於絕大多數的手機,包括許多功能手機,因此對新興市場很重要。

值得注意的是,過去24個月來,可看到小型供應商推出許多新的多平台工具,相較於知名的供應商,小型供應商推出的工具可能會帶來更高的商業風險。

HTML5不會取代原生應用程式

HTML5為行動瀏覽器應用程式帶來許多進步,包括更高階的JavaScript、支援離線應用程式、部分手機服務,如衛星定位、更先進的繪圖軟體和影音服務,以及資料可永遠儲存在瀏覽器內的功能,有助開發商在日後推出更高階、使用性更高,以及可某種程度離線操作的應用程式。相對地,這會模糊網路和原生應用程式之間的區隔;不過從手機的角度來看,HTML5並非可攜式產品的萬靈妙丹。

這是由於HTML還沒有定義清楚。目前不是所有的行動瀏覽器都可支援HTML5。即使在HTML5裝置推出後,以手機平均壽命只有18~24個月的情況下,用戶若不定期更新手機操作系統,就無法使用HTML5的功能。

此外,許多功能手機並不完全支援HTML5,且使用HTML5標準並不代表就能使用許多平台的API來開發進階手機應用程式,例如感測器、付款功能、行事曆與進階地理定位等。Gartner預估JavaScript程式碼和標準會逐漸運用在這些領域上,但會耗時多年,也僅能用於作業系統應用程式介面的一小部分。

另外,某些多平台工具開始將HTML5發展為一種功能產生程式碼(Code-generation),以提供原生碼或HTML5作為輸出格式的選項。

(本文作者為Gartner副總裁)

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!