最近總能看到相似「App已死,服務永生」、「App必死,web永生」 、「App已死,微信建站已生」這樣的文章。不曉得這些網絡寫手究竟是想表明某些公司的立場、仍是想要表達怎麼樣的一個情結,文章中語氣都是如此之確定,好像你們真的有什麼仇什麼怨同樣。html
回顧軟件發展的歷史,C++開始流行時,就有人因其優秀的面向對象能力而預言C語言已死;Java語言開始流行時,也有人因其出色的跨平臺能力和完備的內存管理機制而預言C++已死;在web盛行的年代,更是而有人因看好這種輕量級的B/S交互模式而預言原生應用已死。可實際上呢:這麼多年過去了,根據TIOBE發佈的編程語言排名結果(2015年2月版本),c和c++這兩類古老語言都位於前3;原生應用也在智能手機時代從新迴歸主流地位。科技的發展就好像大天然的進化同樣,是一個極其複雜的過程。咱們非要試圖從某一個簡單側面去解釋或者預言這個過程演變,其結果每每都是比較片面的。從大型機時代的T/S架構,到PC機時代的C/S架構,互聯網時代的B/S架構,以及移動互聯和大數據時代提出的IaaS、PaaS、SaaS以及BaaS架構;全部的軟件架構都是爲特定的技術時代和應用環境而服務的。就好像「java好仍是.net好」這樣的討論,這些年來就歷來沒停過,都快讓人聽得耳朵起繭子了。可最終又如何,java和.net二者各自都發展的好好的,科技的發展會以某些人的主觀傾向爲轉移嗎? 技術自己就無所謂好壞,最多隻能說哪項技術更適合你而已。因此咱們在討論哪一項技術好哪一項技術很差這類命題的時候,應該首先明確一個大前提:咱們到底要作什麼?前端
服務仍是App?html5
咱們所說的服務,一般狀況下應該理解爲移動互聯時代裏的BAAS模式的服務,也就是爲移動互聯網應用開發而提供的雲服務。其主要內容包括:數據存儲、數據推送、版本管理、數據統計等幾大類服務。因而可知服務和App之間原本就是兩個不一樣層面的東西,根本就不該該相互比較,更不該該說誰能替代誰。個別人偷換概念,甚至在文章中用微信服務號當作服務來講事,這種說法雖然有失水準,但倒是別有用心的,根本不值得咱們過多的討論。java
Web仍是App?react
去年的10月份,W3C的HTML工做組正式發佈了HTML5的正式推薦標準(W3C Recommendation)。這一消息讓不少人爲之滿心鼓舞,還有些人所以而判定web的迴歸以及App的滅亡。但咱們當仔細瀏覽W3C官方規劃的HTML5發展計劃,可能會發現現實並無咱們想的那麼樂觀:c++
http://dev.w3.org/html5/decision-policy/html5-2014-plan.html程序員
W3C官方公告稱:「模塊化一直在標準制定過程當中扮演着重要角色。爲了實現功能的獨立、快速進化,工做組會使用所謂的‘擴展規範’(extension specifications)。有一些最終會做爲獨立文檔公佈,併成爲HTML規範家族的一部分,其它則會整合到HTML5規範裏,成爲基礎。」web
目前來看HTML5.1纔會是真正的HTML5,HTML5只是個妥協方案。就好像微軟的windows8到windows8.1的升級同樣,windows8的按時推出徹底是一種市場策略,而windows8.1雖然只是一個小版本變化,卻在系統體系結構層面作了巨大的調整。 HTML5.1預計2016年第四季度公佈後,工做組會重複上述步驟再搞一個新的HTML5.2,繼續完善、豐富功能。具體時間沒說,但估計獲得2018年了。而從HTML5每一個方案的公佈到得到幾大廠商瀏覽器的穩定支持,通常還要再等待至少1年多的時間。就算咱們等到了HTML5.1或HTML5.2的到來,它就必定可以全面的解決咱們移動端應用開發的問題嗎?編程
HTML5標準在正式經過的前些年,早就已是實時上的標準了。不管Webkit內核、仍是Firefox內核、IE內核(9.0之後版本)都前後對其實現了全面的兼容。以PhoneGap產品爲首基於HTML5技術的移動中間件早在2008年就出現了,事實上咱們本身的中間件產品在3.0以前也是以HTML5技術爲核心的。但這幾年發展過來,這一類中間件技術並無實現對原生App開發的大規模替代,反卻是有些被開發者們愈來愈淡忘了。這也難怪,咱們真的很難從AppStore裏能找到一款徹底基於HTML5技術開發且讓人以爲還算優秀的應用。雖然HTML5技術結合原生App開發的模式已經比較成熟,但若是想讓HTML5技術徹底替代原生App開發,這麼多年來,其可行性目前應該仍然停留在實踐的路上…windows
HTML5的草案最先是在2007年就被W3C接納了,同年9月IPhone1代手機纔對外發布。確切的說HTML5的最初設計根本就沒有考慮現有智能手機的體系結構,不是爲智能手機時代而生。我認爲將來主流移動應用開發技術的改進首先會體如今如下3個方面:即UI視圖的標籤化,邏輯語言的腳本化以及底層技術的開放能力。初一看,HTML/HTML5技術已經自然的知足了前兩條,其實則否則。瀏覽器DOM的實現過程和原生UI的實現過程存在着本質上的差異,這就決定了從web頁面到原生頁面之間根本就沒法作到平滑過渡。對於底層技術的開放能力,不該該僅僅停留在簡單API擴展能力上,更應該支持UI標籤的擴展。或許咱們能夠憧憬和期待將來HTML6標準的到來,或許在移動端HTML標準根本就不是必須的,咱們徹底能夠找到更好的替代方案。
Facebook在移動端的技術發展路線就是對以上技術發展趨勢一個很好的驗證。Facebook以前曾經推出了react框架,它採用的全新思路雖然基於瀏覽器DOM的前端UI框架,同時也徹底接管了UI開發中最爲複雜的局部更新部分,擅長在在複雜場景下保證高性能。儘管react框架在web體系下已經很是優秀,然而web終究是web,不管怎麼改進仍是達不到原生應用的效果,Facebook最終也所以放棄了HTML5方案,在移動端轉入純原生開發的模式。近期Facebook官方宣稱他們將要推出react-native計劃,React Native徹底不用DOM,開發者可使用<View>取代<div>,使用<Image>替代<img>等,能夠擴展自定義標籤並實現原生對接,能夠經過JavaScript來寫高質量的應用。在我看來,雖然react-native還還沒有正式推出,但它的技術結構已是已知中間件產品中最早進、最能表明將來發展趨勢的。它所推崇的UI視圖的標籤化,邏輯語言的腳本化以及底層技術的開放能力。
爲何必定要把Web模式和原生App模式分開來對立呢?這二者原本就有着各自不一樣的優點。Web已經成爲App的一部分,和App組件融一塊兒各自完成其擅長的工做。 因此,Web和App都是咱們須要的,要取長補短結合在一塊兒作。
微信仍是App?
談到微信應用,天然是發自心裏的佩服。國產的App產品可以作到如此之優秀的程度,確實讓人折服。微信應用發展到今天,僅註冊用戶就已經發展到了6億多,其市場發展的定位也遠不止其早期起家時的語音通信和即時通訊那麼簡單了。朋友圈的分享模塊,讓微信佔領移動社交網絡的高地;公衆號及開放平臺,讓微信成爲智能手機端的信息門戶;掃一掃功能,讓微信成爲移動端訪問網頁或者下載應用的標準入口;如今又微信開放了設備接入能力,不只僅是在爲O2O市場的發展作準備,更是已經開始染指我的健康設備的領域了。再加上微信錢包、微信支付、微信商城、微信遊戲等重磅型的巨無霸功能,真是微信觸手無處不及呀。細分析微信的這些功能,其實早已涉及到了雅虎、谷歌、Facebook、阿里巴巴和蘋果等多家互聯網大佬們的核心服務範圍。前段時間微信又發佈新功能,在廣州、深圳、佛山展開試點,啓動城市服務這個全新的領域。騰訊的總體佈局之大,看來真是想讓微信作移動互聯網的「惟一應用入口」,其野心已經很明顯了。
咱們大可沒必要被微信的洶涌攻勢所嚇倒,冷靜的思考,微信的快速膨脹快速擴展戰略,其實自己也沒那麼可怕。每一個垂直細分的行業都有本身的價值衡量標準,短時間的流量如沒有長期優質的服務爲基礎也是徒勞,只有堅持作品質作價值纔是正道。就好像當年的QQ同樣,即時通訊帶來的大量流量,確實可以帶動起巨大眼球經濟,好比其帶動了騰訊遊戲的快速發展。可是騰訊也曾投巨資嘗試過作搜索引擎、作新聞資訊、作網上購物,最終還不是也都敗下陣來。
凡事物極必反,今天微信確實太強太大了,強大得讓人擔憂是否它是否早已經觸及了「去中心化」的天然發展規律。人們真正離不開的是「點對點」的溝通(即時通信),而不是點對多的溝通(社交網絡)。微信的最大弱點應該就在於人們對「私密小圈子」的渴望,這偏偏也是微信早期得到成功的緣由。目前爲止微信的用戶一直在增長,咱們每個人在微信上都能看到本身的七大姑八大姨、單位的同事、領導、各類類型的客戶、還有一大批賣東西的人(說的好聽一點叫搞微信營銷的人)都在裏面了,致使原有的私密空間變得愈來愈不私密,這樣下去微信恐怕也將面對相似「大批用戶逃離Facebook」同樣的局面。國內也發生過相似的狀況,當初你們一窩蜂的涌入開心網,以前沒玩過這類東西嘛,熱情事後又一窩蜂所有逃離出去!
放在微信裏打開的即便是普通web頁面,初一看也會讓人以爲閃閃發光。然而移動端終究和PC端不一樣,長期來看各類細分功能的用戶體驗效果仍是相當重要的。微信也有其自身的技術短板,例如:微信的web擴展應用必須有網絡的環境下才能打開;微信本身的「返回」鍵和web應用內的「返回」鍵還會互相干擾等。可是沒辦法,微信支持的擴展能力也只限Web。微信最新版本的安裝包已經有55M多了,再無限制的增長功能只會讓微信愈來愈冗腫而加速毀滅。若是你想期望着在微信中擴展實時導航、虛擬現實、文檔類解析、面部識別、3D控制、離線地圖等這些功能,對不起,這些功能在微信裏都是作不到的。
今天的微信已經成爲移動應用的發佈的重要渠道之一,大有「蘋果、安卓、微信一個都不能少」的勢頭。不管智慧城市應用仍是行業解決方案應用,咱們既要保持保持蘋果、安卓、微信(將來還會包括windowsPhone)等幾個平臺的同步發展,又要控制風險,不要把資源所有投入到其中的某一個渠道中,特別是不能把寶全都輕易的壓在微信平臺上,要充分考慮將來的風險。就比如在「呼機、手機、商務通一個都不能少」那個狂熱的年代,那些壓巨資於呼機或商務通的代理商們,最後的結局也差很少都和呼機或商務通同樣,所有消失了。
微信想要作移動終端惟一入口,着實仍是有很大困難的。微信只是一個普通應用而已,它再強大也必須運行在在蘋果和安卓的系統上運行。特別是蘋果公司,每一年都在不斷調整對上線App的政策要求,而微信仍在不斷開放和擴展開放第三方應用,誰敢保障蘋果公司哪天不會和微信翻臉。在安卓系統體系內,阿里、百度、小米、魅族這些公司都基於安卓內核在作本身雲操做系統,而且這些系統在國內的市場佔有率至關之高。IT生態圈的平衡發展,上下游之間即相互依賴又相互制約,長期來看主導權不可能只由微信一家說的算。正如馬化騰本身所說"戰勝微信的確定不會是微信,而是另外更好玩的",科技的發展每時每刻都在不斷向前推動,這也許並不是危言聳聽。
因此,咱們要原生App也要微信,但不能只要微信。
原生開發之困惑
咱們說App死不了,並不表示說App的很好嗎?其實開發App是一個極其痛苦的過程。總有人找出一些理由說App已死,甚至還有些人對原生App開發模式明確給以仇視的態度,這些也都有其現實緣由的,我徹底可以理解。智能手機的時代確實發展的太迅猛,過程當中除了對傳統行業形成了強烈的衝擊外,同時也形成了IT行業內部一些資源的明顯失衡。客觀的說,對於絕大多數的移動應用項目而言,原生開發過程絕對是一個昂貴的陷阱。目前原生開發者(特別是IOS的開發者)工資水平確實過高:剛畢業的學生,培訓的2~3個月,就能要到10K的月薪。有個2~3年開發經歷且有些經驗的,就敢叫到20K的月薪。App應用需求爆發性增加致使了市場供求關係的現狀,這讓IOS原生開發人員愈來愈緊俏,競爭已經不只僅是非理性,甚至已經開始有些瘋狂了。在拉勾網上,招聘3~5年以上原生開發的工程師,月薪可以給到50K的竟然也大有人在。最讓人接受不了的是這麼高的工資,竟然一直都是供不該求。這讓市場上的大多數公司如何忍受,讓那些經驗豐富的老程序員們情何以堪呀?
這讓我想起了2000年互聯網剛興起那個時候的情形,在網泡沫破滅以前,剛畢業普通作網頁的學生就能拿到10K工資,和如今的情況何其類似。
每個原生應用開發的項目都是一個巨大的坑。要麼等着競爭者經過移動互聯技術把你戰勝,要麼跳進坑,本身招人來開發移動應用。特別是對於面向互聯網的2C應用或者企業內BYOD的應用,更是須要至少招聘IOS、Android兩個以上的原生開發團隊,開發成本也隨之加倍。最可怕的是,須要面對大量的黑屏、閃退、屏幕適配等底層技術陷阱。再加上技術人員流失更換頻率較高,業務系統維護週期較長,操做系統平臺升級後的兼容性問題(例如IOS7 UI佈局結構的強制調整問題、IOS8的64位內核強制升級問題)。處處都是技術陷阱,這豈是每一個小項目的成本可以承受的呀。
因而乎,不少開發者就會很天然的想到了Web技術,想到了微信平臺。對於一些用戶範圍小、要求性低的App多是無所謂的。但對一些重要的移動應用來講,下降品質下降用戶體驗效果,每每會直接致使該應用的失敗。
原生APP不必定非要由純原生的開發人員才能完成。這些年咱們一直在探尋移動端跨平臺的中間件技術,但願可以以此來大幅度下降移動應用開發成本。
出路在哪裏?
開發高品質的App本就不應是一件困難的事情,咱們一直都指望着可以經過移動中間件技術平臺,讓普通的菜鳥也能夠輕鬆的站到巨人肩膀上。你的應用程序邏輯使用統一的腳本語言編寫並運行,而你的應用程序用戶界面則徹底是原生的,想想都會以爲很酷!科技的發展須要更專業的分工與合做:有人作手機就會有人作CPU模塊、作攝像頭模塊;一樣有人作App應用,也就應該有人作底層的UI組件、作API組件。一個優秀的移動中間件產品就是應該能「讓昂貴項的原生開發人員可以更專一於底層技術創新和組件封裝,讓應用開發人員能夠更加專一於具體項目的業務需求,實現原生開發和應用開發的完美分離!」
目前已有的移動中間件開發技術主要包括:IOS、Android或WindowsPhone的純原生開發;以Html5技術爲核心的中間件開發(例如PhoneGap, HBuilder, AppCan, ApiCloud)、以OpenGL技術爲核心的中間件開發(例如:CrossApp)、以代碼轉換和原生反射技術爲核心的中間件開發(例如:Titanium,Xamarin,React Native),以及以虛擬UI、抽象SDK、動態組件爲核心的中間件開發(例如DeviceOne)。
採用純原生代碼開發App,雖然在能力上是最強大最靈活的,但卻每每都要面臨如下這些問題:多個平臺做戰、開發工期長、開發成本高;原生代碼太靈活技術陷阱太多,再加上開發人員水平良莠不齊,很難控制應用質量;項目中要考慮的設備機型太多,屏幕適配工做量巨大;App升級工做煩瑣、哪怕是很小的缺陷修復都必須通過AppStore的審批,還可能常常被拒…
當咱們考慮跨平臺需求時,很天然就能想到Html5技術。若是僅僅是作一個演示demo或體驗要求不高的app還勉強,然而當咱們真的去嘗試用Html5作真實App項目時,咱們纔會發現它所欠缺可不只僅是運行效率的問題,在很各個方面與原生交互體驗的差距實在是太大了。 到目前爲之咱們都很難從蘋果商店裏找到一個Html5框架作的且體驗還算不錯的應用,咱們還在移動端項目中痛苦的嘗試Html5技術的時候,怎能忽略這個事實呢?
以OpenGL技術爲核心和以代碼轉換和原生反射技術爲核心的中間件產品,實際上並不具有完整的跨平臺能力。就像facebook官方說的那樣,他們所要達到的目標只是」learn once, write anywhere」而已,還不是」write once, run anywhere」。用Javascript語法僅僅是簡單的調用IOS現有類庫,其開發難度是可想而知的。
虛擬UI、抽象SDK、動態組件爲核心的中間件,是目前最新的中間技術。目前來看,這類產品在技術上優點仍是比較明顯的。但因爲此類產品推出時間過短,市場檢驗的時間還夠,因此咱們還只能對此採起觀望和嘗試的態度,後續其可否真的成爲第一個值得咱們依託的移動中間件平臺,這還要拭目以待。
多樣性的趨勢是移動互聯時代發展的特色,不管在智能設備端、物聯網傳感器端、仍是各類終端上的應用,都會變得豐富多彩。然而,發展多樣性並不表示不能解決碎片化的問題,相信將來每一個人最經常使用的App應該也不會太多。包括聽音樂、看視頻、玩遊戲這些娛樂類的應用,還有即時通訊應用、城市服務應用、辦公管理應用、健康管理應用、我的信息管理類應用等。每一個垂直細分方向上的應用,最終可能只有1~2家可以存活。可否下降開發成本是事關發展事關生死的問題,但高品質應用對於優秀的移動應用產品來講也是相當重要的。咱們期待着可以真正解決問題的移動中間件產品可以早一天到來。