跨平臺領域的淘金潮:為什么跨平臺開發(fā)工具會改變現(xiàn)狀
本文來自國外知名調查分析機構Vision Mobile數(shù)月前發(fā)布的2012跨平臺開發(fā)工具報告,報告專業(yè)而具洞見地對當前跨平臺工具市場現(xiàn)狀和未來做了調查分析,強烈推薦給關注此領域的開發(fā)者。
跨平臺的淘金
2012年標志著移動平臺領域的一個拐點。Apple的iOS和Google的Android平臺已經推進到以前無法想象的高度,截至2011年年底,在這兩個平臺上,分別有超過540,000和350,000種應用程序,這些應用程序來自成百上千的開發(fā)者。正因為所謂的網絡效應(network effects),Apple和Google對競爭者已經建立起巨大的壁壘,即使是像微軟這樣花費超過10億美元進行營銷的競爭對手,仍然遠遠落后于Apple和Google。
然而,正當Apple/Google的雙寡頭壟斷看起來似乎堅不可摧之時,對諸如Microsoft的 WP7 以及 Samsung的Bada這樣的競爭者來說,前進道路上的障礙正在被掃除:跨平臺的工具讓開發(fā)者可以針對多個平臺進行開發(fā),讓代碼有較高的重用率,從而讓增長的開銷較小。
簡言之,跨平臺的開發(fā)工具(CPTs)允許開發(fā)人員開發(fā)針對多個平臺的應用,針對各個平臺的開發(fā)可以基于相同的核心代碼庫,或使用相同的設計工具。CPTs的影響是兩方面的,它們可以減少移動開發(fā)進入壁壘,又使得開發(fā)者轉向新的開發(fā)平臺更容易,從而對某個平臺的黏度降低了。
開發(fā)的民主化 首先,跨平臺的工具允許開發(fā)人員為他們之前所不能進行開發(fā)的平臺進行開發(fā)。 CPTS使得進入門檻降低了,例如,現(xiàn)在Web開發(fā)人員僅使用HTML和JavaScript就能夠創(chuàng)建本地智能手機應用程序。CPTS可以提供易于使用的語言和開發(fā)工具,并便于模塊化開發(fā)和軟件組件重用。有些工具還允許開發(fā)人員使用相同的代碼庫來針對多種屏幕進行開發(fā)—— 并且,這種開發(fā)不止局限于手機,還針對平板電腦、游戲機、臺式電腦和電視機。這便是軟件開發(fā)的“民主化”,即平臺可以開放給所有類型的開發(fā)者。
減少開發(fā)者的平臺固化 跨平臺工具的第二個影響是戰(zhàn)略性的。CPTs減少了平臺的退出壁壘,也即“開發(fā)者平臺固化(developer lock-in)”。例如,CPTs讓開發(fā)者在為iPhone開發(fā)的同時也可以為Android和Windows Phone 7開發(fā)。在App的生態(tài)系統(tǒng)中,競爭體現(xiàn)在四個方面:app的數(shù)量,top app的可用性,app投入市場的時間(一個app很難同時出現(xiàn)在所有平臺的app stores中)以及總體的app質量。在理論上講,跨平臺的工具使得網絡效應減小了,從而使非Android和Google平臺更容易參與競爭,比如現(xiàn)在Bada平臺就更容易參與競爭了,因為CPTs允許開發(fā)者在為Android開發(fā)的同時也能為Bada開發(fā)。換句話說,跨平臺的工具讓小的平臺不僅可以在數(shù)量方面與大的平臺競爭,也能在app的可用性、到達市場的時間和質量方面進行競爭。
眾所周知,Apple試圖通過在Apple的設備上禁止Adobe的Flash runtime來增加開發(fā)者對于Apple的XCode工具以及iOS API的黏度——它成功做到了。然而,跨平臺工具讓打破Apple的限制更為容易,它們可以將runtime和app進行打包,或者在編譯連接的時候將與平臺無關的代碼翻譯成本地代碼。
正如我們將要看到的那樣,2012標志著跨平臺工具在技術上的成熟。使用Flash或者Java這種通用的方法已經失去了其吸引力,新的基于thin runtimes、cross-compilers 以及 hybrid web apps的方法更為喜聞樂見。2011年在初創(chuàng)階段受到批評的工具現(xiàn)在要么獲得了VC,要么被收購,要么發(fā)布了主要的產品。例如,MoSync 2.7使得網絡編碼變?yōu)榭赡埽⑶宜蚆armalade一起增加了實時本地UI元素。此外,Sencha已經準備發(fā)布Touch version 2.0,在該版本中,Sencha推出了自己的web打包方法(web wrapper solution)以及流水線式的構建流程。其他的,比如LiveCode Android deployment pack以及Mono for Android,都是在2011年才正式發(fā)布的。
與此同時,HTML5系列的技術已經過了狂熱的高峰期正在慢慢走向低谷(此觀點來源于Gartner’s Hype Cycle)。HTML5還沒有真正成為一個平臺;它缺乏一些必要的元素,比如實施的一致性、主流的發(fā)布渠道(也即app stores)以及除mobile ads以外的盈利模式。然而,因為跨平臺工具的存在,HTML5(包括Javascript)正讓mobile app逐步發(fā)展。有好幾十個工具致力于讓web開發(fā)者使用現(xiàn)有的技術構建‘native’ 或者 ‘hybrid’的手機應用,這其中包括Appcelerator, PhoneGap, Rhodes, Sencha 2.0 以及Worklight。同時,mobile frameworks在致力于讓web apps能提供一個“near native”的用戶體驗,這其中包括jQuery Mobile, Sencha, iUI, 以及適用于游戲的Impact.js.。CPTs以及為HTML5掃清了道路,不僅讓它可以成為一個平臺,而且會成為智能手機apps的主流開發(fā)技術。
#p#
跨平臺領域的贏家與輸家
在寫這份報告的時候,跨平臺開發(fā)正十分流行,隨處可見收購、資產剝離和融資。Adobe的Flash,曾經作為跨平臺解決方案的經典方法,正面臨退出,Adobe在2011年11月,宣布了將會停止為mobile browser開發(fā)Flash插件。同時,Adobe會同時終止Flex SDK,而將力量集中于ActionScript-only開發(fā)。從2011年中期起,跨平臺工具提供商方面的收購包括RhoMobile, Metismo, Aptana, ParticleCode, Nitobi, Strobe和Worklight。另外,Alcatel Lucent在2010年收購的Open-Plug因為資金缺乏而不得不停止它的產品(本章后面的案例研究將會談到這一點)。同時,Sencha,一個高調的開發(fā)native、touchscreen UI的Javascript框架,在2010年和2011年完成了兩輪融資,籌到了2900萬美元。下面的三個表列出了跨平臺工具領域主要的收購、退出以及VC融資。

投資涌入
正當投資者們正在尋找下一個經濟增長點時,跨平臺工具出現(xiàn)在他們的視野,在這個領域,籌集到超過兩億美元。在主要風投資金的支持下,Appcelerator扮演了中間人的角色,它自己在試圖app的生態(tài)周期中提供更為端到端的解決方案,收購了Particlecode, Aptana 和Cocoafish。Worklight在被賣到IBM之前,獲得了2100萬美元的投資,而Pyxis在籌到100萬美元以后,重命名為Verivo。


CPT中的資產剝離:OpenPlug案例
在一片大好的投資環(huán)境下,跨平臺工具的競爭中也出現(xiàn)了一些失敗的例子。2010年9月,Alcatel-Lucent收購了OpenPlug。這個電信基礎設施供應商,希望建立一個電信運營商和開發(fā)者之間的戰(zhàn)略平臺。然而一年以后,在2012年12月,OpenPlug宣布終止運營,因為它吸引不到足夠的開發(fā)者。
這個公司最初是有著嵌入式軟件背景的公司,曾經為非智能手機(feature phones)開發(fā)過名為ELIPS Suite的操作系統(tǒng),這個系統(tǒng)在2008年大量生產,尤以和Sony Ericsson的結合最為出名。那時候,手持設備代工生產商(handset OEMs)將注意力從非智能機轉向了在智能機中采用Android以對抗Apple的iPhone帶來的競爭壓力。
結果,OpenPlug轉向了生產跨平臺的runtime和toolset,并于Adobe MAX 2009會議上發(fā)布了beta版,該版本以ELIPS Studio冠名。它的目標用戶群是那些想要從桌面端拓展到智能機的Adobe開發(fā)者。這樣是不合時宜的,因為這個時候恰逢Adobe為iPhone推出了Flash packager,為Mobile推出了AIR。ELIPS Studio那時候使用的還是Adobe豐富的應用框架(Flex以及MXML),這個框架很快便受到HTML5的挑戰(zhàn),并最終被Adobe所淘汰。OpenPlug還被指責說不能讓toolset和Adobe的MXML 和AIR APIs更為兼容。
最終OpenPlug沒能找到一個盈利模式,它面臨的最主要的問題是勸說習慣了免費增值產品的用戶付費試用它的支持功能和專業(yè)服務。它的競爭對手Appcelerator讓這一問題更為嚴重,因為Appcelerator有豐富的VC資金,因此Appcelerator的產品都是免費的。和其他產品不同,OpenPlug沒有任何云服務產品,也就沒有其他銷售來源。
OpenPlug的母公司Alcatel-Lucent,作為一個運營商,顯然不能幫助OpenPlug找到開發(fā)者。相反,這個公司發(fā)現(xiàn),開發(fā)者們都沒有把運營商看做mobile app生態(tài)系統(tǒng)中的一個重要部分。在終止運營以前,OpenPlug聚集了22,000注冊開發(fā)者,但只有少量是活躍用戶,大多數(shù)人只是嘗試寫過“Hello World”后便不了了之了。
跨越趕時髦的階段
跨平臺工具已經度過了“趕時髦”的階段,而成為現(xiàn)今的主流了。一個工具提供商——Sencha——聲稱有160萬開發(fā)者,并且有30萬注冊社區(qū)用戶。游戲開發(fā)平臺Unreal聲稱有100萬的SDK安裝量。Unity在2011年有很大增長,它有80萬注冊開發(fā)者,其中有20萬是活躍用戶。Appcelerator原本有25萬用戶,現(xiàn)在隨著它收購Aptana并將它的“Titanium”技術整合到流行了Aptana IDE中,它的用戶猛然增加了160萬。PhoneGap已經被下載60萬次,并且被整合到幾十個移動應用平臺以及App builders中。跨平臺工具對于消費者也有影響。Corona聲稱用它的工具創(chuàng)建的應用已經有6000多種,這些應用在2011年的下載量有3500萬次。Appcelerator聲稱用它創(chuàng)建的應用有35000種,并且有4000萬設備部署(device deployments)。
在跨平臺工具出現(xiàn)的背后
跨平臺工具的出現(xiàn)主要是為了處理在mobile apps開發(fā)中出現(xiàn)的三個市場上主要的障礙:平臺碎片、進入新平臺的壁壘以及管理開發(fā)資源。
處理平臺碎片
跨平臺的工具出現(xiàn)之初便是為了解決設備和平臺的碎片化。Java ME可以處理幾十種2000s系列的由定制操作系統(tǒng)驅動的手機——但是開發(fā)者需要能支持超過200種設備,以便能為在任何一個國家內的80%的設備做開發(fā)。Mobile web站點也是因為瀏覽器對標準執(zhí)行很差而很難找到通用解決方法;即使在現(xiàn)在,Windows Phone上的IE對HTML5的支持度只比得上Apple的Safari所能支持的一半。另外,要能夠發(fā)布類似于app感覺的應用,HTML5還有很長一段路要走,還需要不菲的調整。為iPad以及Android tablets開發(fā)了Financial Times HTML5 app的Assanka,說它為了開發(fā)iPad 版本的Financial Times HTML5 app,花了24人月(估計為US$400,000),然后又花了另外12人月將這個app移植到Android上去。
除了設備間的碎片,平臺碎片也是很嚴重的。Android因為它的運行時碎片而臭名昭著;在2012年2月,有三個不同版本的Android平臺(API levels 7,8 and 10),互相之間只有超過2%的相同點。所有這三個版本都落后于最新發(fā)布的版本,這個版本是API level 15的,前面過渡性的API levels (11-14)是針對平板電腦的(由Gingerbread發(fā)布)。
對了應對碎片化問題,跨平臺工具提供商在云中提供了一些設備相關優(yōu)化手段以及web資源重新表現(xiàn)方法。數(shù)據(jù)庫中的設備詳細參數(shù)和性能可以幫助優(yōu)化圖像大小、重新確定布局以及用戶界面、實施一些折中而非強迫開發(fā)者一定要找到通用的方法。從傳統(tǒng)上講,設備性能數(shù)據(jù)庫(device capability databases)是由像Wurlf, DotMobi 以及 DetectRight.這樣的專營公司提供的。慢慢的,device databases有了更多來源,比如通信架構公司(如WDS, Ericsson, mFormation, Ascom),通信公司本身(如AT&T device capabilities API),以及已有的跨平臺工具(如Netbiscuits, Mobile Distillery, Sevenval)。BKRender,另外一個跨平臺解決方案,提供了含6000種設備的數(shù)據(jù)庫以及一個HTTP反向代理(an HTTP reverse proxy)來優(yōu)化移動在站點。
一些CPTs因為內部咨詢項目的碎片化問題需求而成長起來。其中的一個例子是Enough Software,,它是給Java ME apps提供優(yōu)化工具的。Enough Software走的是跨平臺工具領域中的典型路線——先解決他們在自己的項目中遇到的碎片化問題,然后將解決方案轉化為一個商業(yè)工具。這條路隨后被Pyxis (Verivo),、Netbiscuits、Marmalade 以及 DragonRad所模仿。
盡管CPTs開始解決一些平臺碎片化問題,但是又出現(xiàn)了新維度的碎片化。Handy Games的CEO Christopher Kassulke說,“現(xiàn)在的碎片化已經是4D matrix的了”。他提示開發(fā)者要處理平臺間的碎片化,如軟件平臺,計費平臺(以及定價模型),廣告平臺以及社交平臺。
#p#
讓為新平臺以及設備開發(fā)成為可能
對于參與到我們的在線調查的2500位開發(fā)者來說,我們發(fā)現(xiàn)影響跨平臺工具選擇的最重要的因素是該工具支持的平臺廣泛程度。除了占統(tǒng)治地位的iOS平臺以及Android平臺,許多平臺都在爭奪亞軍位置——包括Windows Phone 7, Bada以及BlackBerry,更不用說針對各式屏幕的平臺了,比如針對桌面機屏幕、游戲機屏幕和機頂盒平臺屏幕。我們發(fā)現(xiàn)開發(fā)者都將iOS和Android作為起跳板,并在隨后拓展到新的平臺。現(xiàn)今非常流行的Appcelerator 和Marmalade工具的用戶中有超過90%是定位在iOS,有超過80%是定位在Android。而CPT的整個用戶群中有超過70%是定位在iOS,有超過60%是定位在Android。
在VisionMobile Developer Economics 2011年度報告中,我們發(fā)現(xiàn)開發(fā)者平均關注的平臺個數(shù)為3.2個。大概過了一年,在跨平臺工具報告中所作的調查里,我們發(fā)現(xiàn)開發(fā)者平均關注的平臺個數(shù)變成了人均3.8個平臺——而對于跨平臺工具活躍用戶而言,這個數(shù)字增長到4.5.換句話說,跨平臺工具讓開發(fā)者可以同時使用的平臺數(shù)目增加了。
從經濟角度來說,開發(fā)者可以同時使用的平臺數(shù)據(jù)增加是有利于節(jié)省開銷的。對于一個開發(fā)者而言,針對另外一個平臺重寫一個應用耗時耗力。通常要為一個新平臺再做開發(fā)需要增加超過初次開發(fā)開銷的50%。兩外,由于各個平臺和不同app stores相對應,app的提交和宣傳開銷也會增加。
我們同時還發(fā)現(xiàn)CPTs被用來處理新屏幕,也即新的聯(lián)網設備、臺式機、機頂盒和游戲機。在我們的調查中,27%的人提到他們還會應用他們主要的跨平臺工具去處理Windows PC,另外有24%人會借用跨平臺工具處理Mac臺式機。由于Eric Schmidt預言說2012年中期在北美有超過半數(shù)的電視機將使用Android驅動,對新屏幕的處理能力將會成為跨平臺工具的一個主要的增長點。由于我們的調查時間稍微靠前,在2011年底才出現(xiàn)的智能電視,沒有表現(xiàn)出多大的勢頭。只有一個被調查者希望能有對智能電視的支持,還有一些人提到了智能電視平臺,比如Google TV 和 LG TV。另外有一些開發(fā)者希望能有對Playstation3 和Vita、 Xbox 以及 MS Surface Table的支持。Linux被證明是最流行的備選平臺,這是我們之前沒有看到的,有76個受訪者指出他們在處理嵌入式、服務器以及臺式機問題時會應用Linux平臺。
管理開發(fā)資源
跨平臺工具出現(xiàn)的第三個重要原因是開發(fā)者資源管理問題。不管是單人開發(fā)還是頂級的五個游戲軟件供應商聯(lián)合開發(fā),在為移動端進行開發(fā)時,都要面臨這樣的問題。
每一種主要的智能機、PC或游戲平臺都有它自己的指定語言、它自己的API集、它自己的開發(fā)環(huán)境和它自己的app store。下面的表展示了主要的智能機平臺的區(qū)別。

假設一個例子,有一個小的apps公司,它為iOS,Android以及Windows Phone7開發(fā)。他們需要雇傭三個團隊,這三個團隊擅長的技能都不一樣。他們需要維護三套不同的代碼庫,并在功能增加或者修復bug時同時對這三套代碼庫進行操作。這是一個很大的挑戰(zhàn),也是為什么很多apps在不同stores的發(fā)布時間有幾個月的延遲。另外,隨著各個團隊的工作進行,質量以及設計的一致性都會發(fā)生改變,尤其是將對新平臺的開發(fā)外包給第三方的時候。為多個平臺開發(fā)時,后期維護也很困難,因為三個平臺需要各自建立開發(fā)文檔,內部用戶支持文檔也需要三份。
因此,跨平臺工具能為軟件工作室提供產品投入市場時間的優(yōu)勢、為其節(jié)約開銷。“我們發(fā)現(xiàn)通過使用跨平臺工具,我們的產品投入市場的時間平均減少了70%。” InRuntime的CEO Paulius Uza如是評價。他接著說:“即使我們只是要為單個平臺構建單個應用,我們也會選擇跨平臺工具。”
原文鏈接:http://www.webapptrend.com/2012/05/2940.html
【編輯推薦】



























