【歷史角度】前端混合開發技術的選型之路

語言: CN / TW / HK

我正在參加跨端技術專題徵文活動,詳情檢視:https://juejin.cn/post/7101231224038883336

一、歷史的選擇

  歷經多年的手機開發,最終被安卓和ios一通天下。我還記得很多年前,我特別想買的一款諾基亞塞班系統的手機,後來一個親戚買了之後,各種app不支援,手機還是好的,還挺新,但是不好使了。還記得那些年的Windows Phone,我一直覺得和現在的window10設計還是一致的。


  歷史的選擇,讓我們進入移動網際網路的時代,也有了我們這個行業的大規模發展。而JavaScript的卓越發展,幾乎也是一場侵佔的歷史,從大家開始認為這門指令碼語言,它不一定執行在瀏覽器上開始,它就做出了,它的飛速發展。例如JavaScript+C++ = node,也或許也誕生了 electron、JavaScript+java = 安卓、JavaScript+object-c = ios。

  2008年8月,世界上一段PhoneGap程式碼誕生了,出現的原因是一名iOS程式設計師無法忍耐Object-C生硬而又陌生的語法。而這名程式設計師又恰恰注意到了Web指令碼偉大的前景,他發現Object-C顯然不如簡單的HTML+JavaScript容易理解,而相對於熟練的Object-C程式設計師,顯然熟練的前端開發者更容易找到也更容易培訓。於是他就認識到世界上需要這樣一種中介軟體,讓Web開發者所熟悉的HTML、CSS、JavaScript技術能夠簡單地部署在移動裝置上,並且能夠同iPhone實現簡單的功能互動(比如攝像頭和重力感應)。

最早的跨平臺開發(摘自《Apache Cordova移動應用開發實戰》王亞飛,王洪飛編著)

二、樂此不疲的想做一款自己的app

  我們不難發現,選擇很多app都似乎比你更瞭解你自己,那麼它到底做了些什麼呢?我們來瞅瞅....
  大家都在說,小米的miui12動了網際網路的蛋糕,它指定了規則,讓大家一下子有一點懵,那麼我們就用miui看看一般手機app,都獲取了些什麼。


  那麼我們排除這些使用者隱私的內容外,我們還能用app做一些什麼網頁完不成的任務呢?

| 獲取當前應用的版本號 | 獲取網路連線資訊 | 獲取GPS資料  | 視覺化訊息提醒  | | --- | --- | --- | --- | | 獲取裝置資訊  | 在裝置上讀/寫  | 檔案上傳或者下載  | 呼叫裝置上的攝像頭  | | 控制應用的啟動畫面  | 獲取裝置上聯絡人的資訊  | 二維碼掃描和建立  | 呼叫系統預設鍵盤  | | 可以調整裝置亮度  | 裝置螢幕方向  | Hardware Nofifications(硬體訊息提醒)讓裝置蜂鳴或振動  | 可以獲取電池狀態資訊  | | 檢測app是否被安裝  | 微信分享、登入、支付  | 手電筒外掛  | 等等 |

當然了可能對於大多公司來說,及時的推送(騷擾訊息),作為一個公司戰略而且,有一個能上架推廣的app,就像有一個官網一樣重要,它可能沒有價值,但是可以唬住一些合作方。

三、技術的選擇

思考維度

  如果你所處的環境公司的金幣就像開了無限一樣,那麼我不建議你看下去,畢竟有錢的公司,使用者的體驗才是最重要的。

現在學ios,就是49年入國軍

  這句話,似乎總是開發們互相嘲諷玩笑,但是它也是一種技術成本壓縮下的無奈,因為畢竟不是每一家公司都有這個實力和經費,去養活一個Android團隊和一個ios團隊,當然也可能就是兩個開發,但是這個也是一個要算計的成本。
  而這一切,也和混合開發技術的誕生有關。當然較為有錢的公司,會選擇,養活少量的Android團隊和ios團隊,讓他們做一個大致的框架,然後通過webView(如果你不能理解這個控制元件,那麼你就認為是iframe也不打緊),這樣的技術手段,做一些通訊,來實現一個app,這也是混合開發的一種。

技術優勢

那麼我們就該討論一下,這種技術的優勢。

研發效率:最大化程式碼複用,降低開發成本,效率提升是貫穿整個業務技術方向,以後app上線之後,可持續降低後續的維護成本,加快迭代速度,這是一個持續的效率收益。
自我價值:學習之後,無疑是提高了前端團隊的技術地位,也是評估跨端技術的一個重要考核點。跨平臺可以降低用人成本,避免了同時養兩個(Android/iOS)開發團隊的現狀。對於開發者而言,跨平臺可以降低學習成本。
多端致性:好產品在多端UI設計上,往往是整體風格統一,所以業務方採用原生各自獨立開發完成後,還需額外花不少時間來修改UI以保證多端一致性。
使用者體驗:技術的而言,就如魚和熊掌不可兼得的關係,在方便開發的同時,也同時犧牲了效能的體驗。如果你發現魚和熊掌可以兼得,那麼就會有一項技術,退出了它歷史的舞臺。
大體來說跨平臺開發可以由以下三點用來概況。
Web技術: 主要依賴於WebView的技術,功能支援受限,效能體驗很差,比如PhoneGap、Cordova、小程式。 
原生渲染: 使用JavaScript作為程式語言,通過中間層轉化為原生控制元件來渲染UI介面,比如React Native、Weex。  
自渲染技術: 自行實現一套渲染框架,可通過呼叫skia等方式完成自渲染,而不依賴於原生控制元件,比如Flutter、Unity。 

四、現有技術方案

2011年 Cordova

技術的誕生

  Cordova提供了一組裝置相關的API,通過這組API,移動應用能夠以JavaScript訪問原生的裝置功能,如攝像頭、麥克風等。 Cordova還提供了一組統一的JavaScript類庫,以及為這些類庫所用的裝置相關的原生後臺程式碼。     Cordova支援如下移動作業系統:iOS, Android,ubuntu phone os, Blackberry, Windows Phone, Palm WebOS, Bada 和 Symbian。 

  2008年8月,PhoneGap在舊金山舉辦的iPhoneDevCamp上嶄露頭角,起名為PhoneGap是創始人的想法:“為跨越Web技術和iPhone之間的鴻溝牽線搭橋”。當時PhoneGap隸屬於Nitobe公司,而從Nitobe的部落格上你可以看到最初創作者對他的評價“他有點像為iphone而開發的AIR”(Air桌面技術使得web開發人員使用。
  HTML,CSS,Javascript開發桌面應用程式)。2009年2月25日,PhoneGap0.6釋出,是PhoneGap歷史上第一個穩定版本,分別支援IOS,Android,BlackBerry平臺。在那個時候,PhoneGap已經決定了它所擔當的歷史任務,直到現在。慢慢的PhoneGap開始支援更多平臺。而在此時,被喬布斯宣佈死亡的Flash持有者adobe開始意識到,這個專案似乎是自己放棄Flash而尋找替代的一個產品。於是2011年10月4日,Adobe宣佈收購Nitobe,在收購之後Adobe其實並沒有做太多的貢獻,只是把原來的PhoneGap和PhoneGap Build 提供服務並做好宣傳工作。
  後來Adobe將Phonegap捐獻給Apache基金會,作為開源專案。但專案初期依然只是Adobe公司內部員工來維護該專案,而由於Adobe公司依然保留著PhoneGap的商標所有權,導致在那以後的一段日子裡,PhoneGap一直被認為是Adobe公司的私有財產。直到PhoneGap1.4釋出時,Cordova這個名字才真正被Apache公佈(期間有過一次更名叫Apache Callback)。看到這段歷史你可能會想到另一端歷史Javascript和ECMAscript,你會發現Cordova之於PhoneGap和ECMAscript之於Javascript是多麼的相似。

商用情況

優缺點

| 優點 | 缺點 | | :---: | :---: | | 開發成本比較低、能夠與老業務(當已有h5端、或未來有h5端)做一次完美的融合。 | 任何快速便捷的方案,它必將犧牲掉技術本身的體驗效果,cordva技術也不例外。 | | 也可以去使用外掛式的方法去呼叫更多的原生api。 | 對於一些老安卓裝置,版本比較低的裝置,他的相容性不是很友好,可能會出現一些問題。 | | 可以多渠道快速的拓展,達到試點的目的。  | 社群完善程度不夠,外掛還是偏民間開源專案。  |

使用場景

  技術的優缺點似乎還是很明顯的,如果你目前處於初創團隊,你的團隊中,不僅原生開發少,而且前端人手,也不富裕的情況下。你的運營似乎也不大清楚,app對團隊發展是否有戰略性價值。此時,你的團隊有一套的自己的h5程式碼(技術棧不限制,不論react、vue、jq、Angular)。
  有一項開源的方案,叫做Ionic,其實就是cordva+Angular一套方案,靈活的使用一下webpack,做一套自動化的cordva+X即可。
那麼我建議最初的情況下,使用這項技術去試點,去拓展,雖然使用者體驗會降低,但是通過資料渠道包採集,才能瞭解市場運營的能力,也方便之後的迭代。

ps: 也可能你是自己的私活,套殼技術也可以增加的私活費用。

官網地址

https://cordova.apache.org/

2015年 React Native

技術的誕生

   React Native (簡稱RN)是Facebook於2015年4月開源的跨平臺移動應用開發框架,是Facebook早先開源的JS框架 React 在原生移動應用平臺的衍生產物,目前支援iOS和安卓兩大平臺。RN使用Javascript語言,類似於HTML的JSX,以及CSS來開發移動應用,因此熟悉Web前端開發的技術人員只需很少的學習就可以進入移動應用開發領域。 

商用情況



優缺點

| 優點 | 缺點 | | :---: | :---: | | 開發成本中等,語法與react寫法沒有太大區別,本身的控制元件提供較為完善 | 僅支援ios與Android端,web端無法使用,增大了程式碼的複用。 | | 社群完善,外掛也比較豐富,有facebook作為大廠背書。 | 大版本升級如換血,可能會花費一些時間。 | | 體驗較好。  | |

使用場景

  不難看出,在過去的幾年裡,RN這項技術,收到了廣泛的前端跨平臺技術的追捧。這點從招聘上來看,這一點就很廣泛,它的工資普遍比普通的前端而言會略高一點,它也希望你懂關於原生元件混合開發,而在這些年成長的努力下,其實這套元件的呼叫上而已,已經比較穩定,加上Facebook目前還不會打自己臉的情況,這項技術的發展還是比較好的。
  在前端團隊人手不緊張的情況下,而你恰巧也懂react,(其實你就算只懂vue,學起來也很快),這項技術的穩定發展,還是值得你去使用的。

官網地址

https://reactnative.dev

約2015年後 uni-app

技術的誕生

   很多人以為小程式是微信先推出的,其實,DCloud才是這個行業的開創者。 W3C和HTML5中國產業聯盟,推出了HBuilder開發工具,為後續產業化做準備。
  2015年,DCloud正式商用了自己的小程式,產品稱為“流應用”,它不是B/S模式的輕應用,而是能接近原生功能,效能的動態App,並且即點即用。
  為引入技術發揚光大,DCloud將技術標準捐獻給工信部所屬的HTML5中國產業聯盟,並推動各家流量巨頭接受該標準,開展小程式業務。
  一個使用 Vue.js 開發所有前端應用的框架,開發者編寫一套程式碼,可釋出到iOS、Android、H5、以及各種小程式(微信/支付寶/百度/頭條/QQ/釘釘/淘寶)、快應用等多個平臺。
  nvue基於weex那一套的增強版。 

  這裡呢為什麼討論是uni-app而不是weex,weex在那時候,還是現在rn的推出後,紅火了一波,畢竟是阿里出品,也給更多的vue玩家打了一針強心劑。

但是就很不幸,weex可能就是歷史上一個KPI的恥辱專案,也就是後面他就沒了,而uni-app做的也就是撿起來的這件事。

  這一專案的特點,也就和最大程度的跨平臺息息相關。

4.3.2 商用情況

等等

優缺點

| 優點 | 缺點 | | :---: | :---: | | 開發成本更貼近vue技術棧的前端開發 | 複用性也同時帶來了,相容性的問題,每一個小程式的廠商,和各個端的廠商,總有那麼幾個api呼叫會有問題。  | | 社群完善,外掛也比較豐富,有dcloud作為主力推廣。 | 體驗一般。  | | 複用性從理論上極高,支援多端打包執行釋出。  | |

使用場景

  對更多公司而言,使用uni-app的最大特點就是可以最大程度的去跨平臺,加上它很適合很多新人上手,使用起來也很簡單方便,HBuilder也是做的很不錯的開發工具,它的優點強大,也正是它最大的缺點。就是有太多的不可控因素,畢竟對很多開發而言,api的相容性可能是你會遇到的重大問題。
  我的建議是,技術上和公司的發展息息相關,如果未來技術上,可能重點的鋪開的試點,而不是作為很多私有api的不同(有去做相容的時間,可能你重開一個專案的時間都夠了),這樣的情況下使用這項技術也是一個不錯的選擇。

官網地址

https://uniapp.dcloud.io

2018.6.7 taro

技術的誕生

  Taro 是一個開放式跨端跨框架解決方案,支援使用 React/Vue/Nerv 等框架來開發微信/京東/百度/支付寶/位元組跳動/ QQ 小程式/H5 等應用。現如今市面上端的形態多種多樣,Web、React Native、微信小程式等各種端大行其道,當業務要求同時在不同的端都要求有所表現的時候,針對不同的端去編寫多套程式碼的成本顯然非常高,這時候只編寫一套程式碼就能夠適配到多端的能力就顯得極為需要。
  有意思的故事說,為什麼叫做taro呢?那是因為Taro['tɑ:roʊ],泰羅·奧特曼,宇宙警備隊總教官,實力最強的奧特曼。

商用情況

優缺點

| 優點 | 缺點 | | :---: | :---: | | 社群比較完善。 | 和uni-app複用性也同時帶來了,相容性的問題,每一個小程式的廠商,和各個端的廠商,總有那麼幾個api呼叫會有問題。  | | 複用性從理論上極高,支援多端打包執行釋出。  | 體驗一般。  | | | 外掛市場比較欠缺。 |

使用場景

   總的來說,它所可能遇到的問題,幾乎和uni-app,你也可以把它當做react版的taro的思路。對於新手使用者,可能對於首次電腦的配置,你可能要費一點心思,它的版本構建上,更加偏向指令化的設計。
   對於ui框架來說,目前還沒有一套真正可以跑全端的開源ui專案,而在版本上也依賴性畢竟強。但是好在團隊比較友好,有專門的對外體驗群,issue的恢復也足夠的即使,加上最近3.0的上線,也會成為一種不錯的選擇,而且體驗上會比uni-app更加好。
技術上的選擇,可能和之前說過的uni-app,他們存在同樣的毛病,這一點也是在所難免,但是你如果在時間也算富裕,體驗又有點追求的,可能在uni-app於它的選擇中,也會偏向與它。

官網地址

https://taro.aotu.io/

2018 Flutter

技術的誕生

  Flutter是谷歌的移動UI框架,可以快速在iOS和Android上構建高質量的原生使用者介面。 Flutter可以與現有的程式碼一起工作。在全世界,Flutter正在被越來越多的開發者和組織使用,並且Flutter是完全免費、開源的。 
相比較目前的混合開發方案,Flutter 提供了大量的文件,能非常快速且友好的讓你加入到這個大家庭。它並不止 WebView,也用通過解釋 JS 後去作業系統的原生控制元件,Flutter 核心只有一層輕量的 C/C++程式碼(Engine),Flutter 在 Dart 中實現了其他大部分系統(組合、手勢、動畫、框架、widget 等),因此,開發人員可以輕鬆地進行讀取、更改、替換或移除等操作。這為開發人員提供了對系統的巨大可定製性。
  針對移動端,Flutter 提供了符合 Android 風格的 Material 和符合 iOS 風格的 Cupertino,同時對不同平臺也做了不同的相容,更好地保留了平臺的特性,如 ScrollView,在 iOS 平臺中,滑動的時候就擁有回彈的效果,在 Android 平臺中,表現出來的就是阻尼的效果。當然,有的時候 Flutter 的 Framework 提供的 UI 格並不能滿足我們的需求,我們還可以去自定義控制元件。
   Flutter 在開發中支援 Hot Reload,相比較原生,這樣的方式能更高效地開發,真正做到所寫即所得。

商用情況

優缺點

| 優點 | 缺點 | | :---: | :---: | | 使用者體驗上混合開發中最佳。  | 前期學習成本太高。 | | 社群完善。 | | | 有Google作為主力推廣。 | |

使用場景

  Flutter無疑是這幾年混合開發技術上,最熱門的話題。它的熱度評論,也算是一種火爆,民間也傳言,看跨平臺技術,看一看閒魚團隊。首先,我這裡要說一聲抱歉,我除了跑完了完整的demo之後,並沒有使用這項技術作為商用技術的手段。為什麼呢?那麼我們來分析一下。
  無疑問的說,混合開發的使用者體驗,Flutter是目前最好的技術體驗,至於原因,大家也知道,是因為它的引擎中的自渲染。但是它的學習成本,就另一個角度的代表了用人的成本,
  對於個人發展而言,比如說,我使用以上任何一個技術,不管這樣的技術如何迭代,我之後是否換公司,我所思考的深度,還是在三大框架與jq之間,即使未來不做混合開發,其實問題也不大。但是flutter這項技術採用了dart.js,當然了它還是代表了JavaScript中的特性,但是寫法上卻和我們普通的網頁佈局,有所不同。如果有一天被淘汰,可能對於我們前端未來的發展有限,可能就是說,會是加分項,但是不會也不太會是減分項。
  而對於公司而言,可能老專案組人員的替換上,新入職的標準就要加上會使用flutter,或者給新人足夠的時間去適應,也是無形中增加了成本。

官網地址

https://flutter.dev/

五、總結


   大家可以不難看到,跨平臺技術,從2008年,想減輕一些原生開發的工作量,到現在2020年,我們馬上要步入的5G時代而言,其實著重點可能會產生一些不一樣的地方。可能之前只是考慮如何只做一個app,現在可能會考慮到公司使用者流量的入口(但凡有點名氣的公司,都有一套小程式),如何多樣化,寧可多做,也不願意錯過任何一個時代的風口。
  技術的本身都是有著它足夠的價值,可能有人會覺得react>vue>jq等等,這樣技術棧的鄙視鏈,但是我認為,沒有所謂不好的技術,因為技術本身他的團隊,還在迭代,還在發展,這就已經說明了問題。魚和熊掌不可兼得,如果可以,那麼一定會淘汰一項技術。
  在合適的場景,和對未來的正確估計下(別老想著自己未來是個多好多大的專案),使用一些合適技術,這樣才能更好的體現專案和產品的價值。