當(dāng)前常見的移動(dòng)開發(fā)技術(shù)主要分為原生開發(fā)和跨平臺(tái)技術(shù)，下面就對(duì)各自進(jìn)行簡(jiǎn)單的介紹。
1、原生開發(fā)
??原生應(yīng)用程序是指某一個(gè)移動(dòng)平臺(tái)（比如iOS或安卓）所特有的應(yīng)用，使用相應(yīng)平臺(tái)支持的開發(fā)工具和語(yǔ)言，并直接調(diào)用系統(tǒng)提供的SDK API。比如Android原生應(yīng)用就是指使用Java或Kotlin語(yǔ)言直接調(diào)用Android SDK開發(fā)的應(yīng)用程序；而iOS原生應(yīng)用就是指通過Objective-C或Swift語(yǔ)言直接調(diào)用iOS SDK開發(fā)的應(yīng)用程序。
主要優(yōu)勢(shì)：
- 可訪問平臺(tái)全部功能（GPS、攝像頭）；
- 速度快、性能高、可以實(shí)現(xiàn)復(fù)雜動(dòng)畫及繪制，整體用戶體驗(yàn)好；
主要缺點(diǎn)： - 平臺(tái)特定，開發(fā)成本高；不同平臺(tái)必須維護(hù)不同代碼，人力成本隨之變大；
- 內(nèi)容固定，動(dòng)態(tài)化弱，大多數(shù)情況下，有新功能更新時(shí)只能發(fā)版；
在移動(dòng)互聯(lián)網(wǎng)發(fā)展初期，業(yè)務(wù)場(chǎng)景并不復(fù)雜，原生開發(fā)還可以應(yīng)對(duì)產(chǎn)品需求迭代。 但近幾年，隨著物聯(lián)網(wǎng)時(shí)代到來、移動(dòng)互聯(lián)網(wǎng)高歌猛進(jìn)，日新月異，在很多業(yè)務(wù)場(chǎng)景中，傳統(tǒng)的純?cè)_發(fā)已經(jīng)不能滿足日益增長(zhǎng)的業(yè)務(wù)需求。
不能滿足需求的主要表現(xiàn)： - 動(dòng)態(tài)化內(nèi)容需求增大；當(dāng)需求發(fā)生變化時(shí)，純?cè)鷳?yīng)用需要通過版本升級(jí)來更新內(nèi)容，但應(yīng)用上架、審核是需要周期的，這對(duì)高速變化的互聯(lián)網(wǎng)時(shí)代來說是很難接受的，所以，對(duì)應(yīng)用動(dòng)態(tài)化(不發(fā)版也可以更新應(yīng)用內(nèi)容)的需求就變的迫在眉睫。
- 業(yè)務(wù)需求變化快，開發(fā)成本變大；由于原生開發(fā)一般都要維護(hù)Android、iOS兩個(gè)開發(fā)團(tuán)隊(duì)，版本迭代時(shí)，無論人力成本，還是測(cè)試成本都會(huì)變大。
2、跨平臺(tái)技術(shù)
為解決原生開發(fā)出現(xiàn)的問題，出現(xiàn)了很多跨平臺(tái)技術(shù)，跨平臺(tái)多指 Android 和 iOS 兩個(gè)平臺(tái)，主要分為三類：
- H5+原生（微信小程序）
- JavaScript開發(fā)+原生渲染 （React Native、Weex、快應(yīng)用）
- 自繪UI+原生（QT for mobile、Flutter）
| 技術(shù)類型 | UI渲染方式 | 性能 | 開發(fā)效率 | 動(dòng)態(tài)化 | 框架代表 |
|---|---|---|---|---|---|
| H5+原生 | WebView渲染 | 一般 | 高 | 支持 | 微信小程序 |
| JavaScript開發(fā)+原生渲染 | 原生控件渲染 | 好 | 中 | 支持 | RN、Weex |
| 自繪UI+原生 | 調(diào)用系統(tǒng)API渲染 | 好 | Flutter高，QT低 | 默認(rèn)不支持 | QT、Flutter |
2.1、H5+原生混合開發(fā)
??這類框架主要原理就是將APP的一部分需要?jiǎng)討B(tài)變動(dòng)的內(nèi)容通過H5來實(shí)現(xiàn)，通過原生的網(wǎng)頁(yè)加載控件WebView (Android)或WKWebView（iOS）來加載。這樣以來，H5部分是可以隨時(shí)改變而不用發(fā)版，動(dòng)態(tài)化需求能滿足；同時(shí)，由于h5代碼只需要一次開發(fā)，就能同時(shí)在Android和iOS兩個(gè)平臺(tái)運(yùn)行，這也可以減小開發(fā)成本，也就是說，H5部分功能越多，開發(fā)成本就越小。我們稱這種h5+原生的開發(fā)模式為混合開發(fā) ，采用混合模式開發(fā)的APP我們稱之為混合應(yīng)用或Hybrid APP ，如果一個(gè)應(yīng)用的大多數(shù)功能都是H5實(shí)現(xiàn)的話，我們稱其為Web APP 。
??原生開發(fā)可以訪問平臺(tái)所有功能，而混合開發(fā)中，H5代碼是運(yùn)行在WebView中，對(duì)于大多數(shù)系統(tǒng)能力都沒有訪問權(quán)限，所以，對(duì)于H5不能實(shí)現(xiàn)的功能，都需要原生去做。WebView便是原生API與JavaScript之間通信的橋梁主要負(fù)責(zé)JavaScript與原生之間傳遞調(diào)用消息，而消息的傳遞必須遵守一個(gè)標(biāo)準(zhǔn)的協(xié)議，它規(guī)定了消息的格式與含義，我們把依賴于WebView的用于在JavaScript與原生之間通信并實(shí)現(xiàn)了某種消息傳輸協(xié)議的工具稱之為WebView JavaScript Bridge, 簡(jiǎn)稱 JsBridge，它也是混合開發(fā)框架的核心。
??微信小程序是目前混合開發(fā)框架的典型代表也是最常見的一種，它是在webview中去渲染的，并非原生渲染，但將來可能會(huì)采用原生渲染。
??混合應(yīng)用的優(yōu)點(diǎn)是動(dòng)態(tài)內(nèi)容是H5，web技術(shù)棧，社區(qū)及資源豐富，缺點(diǎn)是性能不好，對(duì)于復(fù)雜用戶界面或動(dòng)畫，WebView不堪重任。
2.2、JavaScript開發(fā)+原生渲染
React Native
??React Native (簡(jiǎn)稱RN)是Facebook于2015年4月開源的跨平臺(tái)移動(dòng)應(yīng)用開發(fā)框架，是Facebook早先開源的JS框架 React 在原生移動(dòng)應(yīng)用平臺(tái)的衍生產(chǎn)物，目前支持iOS和Android兩個(gè)平臺(tái)。RN使用Javascript語(yǔ)言，類似于HTML的JSX，以及CSS來開發(fā)移動(dòng)應(yīng)用。相對(duì)于混合應(yīng)用，由于React Native是原生控件渲染，所以性能會(huì)比混合應(yīng)用中H5好很多，同時(shí)React Native使用了Web開發(fā)技術(shù)棧，也只需維護(hù)一份代碼，由此便實(shí)現(xiàn)了跨平臺(tái)。React Native 是React 在原生移動(dòng)應(yīng)用平臺(tái)的衍生產(chǎn)物。
Weex
??Weex是阿里巴巴于2016年發(fā)布的跨平臺(tái)移動(dòng)端開發(fā)框架，思想及原理和React Native類似，最大的不同是語(yǔ)法層面，Weex支持Vue語(yǔ)法和Rax語(yǔ)法，Rax 的 DSL(Domain Specific Language) 語(yǔ)法是基于 React JSX 語(yǔ)法而創(chuàng)造。與 React 不同，在 Rax 中 JSX 是必選的，它不支持通過其它方式創(chuàng)建組件，所以學(xué)習(xí) JSX 是使用 Rax 的必要基礎(chǔ)。而React Native只支持JSX語(yǔ)法。
快應(yīng)用
??快應(yīng)用是華為、小米、OPPO、魅族等國(guó)內(nèi)9大主流手機(jī)廠商共同制定的輕量級(jí)應(yīng)用標(biāo)準(zhǔn)，目標(biāo)直指微信小程序。它也是采用JavaScript語(yǔ)言開發(fā)，原生控件渲染，與React Native和Weex相比主要有兩點(diǎn)不同：
- 快應(yīng)用自身不支持Vue或React語(yǔ)法，其采用原生JavaScript開發(fā)，其開發(fā)框架和微信小程序很像，值得一提的是小程序目前已經(jīng)可以使用Vue語(yǔ)法開發(fā)（mpvue），從原理上來講，Vue的語(yǔ)法也可以移植到快應(yīng)用上。
- React Native和Weex的渲染/排版引擎是集成到框架中的，每一個(gè)APP都需要打包一份，安裝包體積較大；而快應(yīng)用渲染/排版引擎是集成到ROM中的，應(yīng)用中無需打包，安裝包體積小，正因如此，快應(yīng)用才能在保證性能的同時(shí)做到快速分發(fā)。
總結(jié)
JavaScript開發(fā)+原生渲染的方式主要優(yōu)點(diǎn)如下：
- 采用Web開發(fā)技術(shù)棧，社區(qū)龐大、上手快、開發(fā)成本相對(duì)較低。
- 原生渲染，性能相比H5提高很多。
- 動(dòng)態(tài)化較好，支持熱更新。
不足如下：
- 渲染時(shí)需要JavaScript和原生之間通信，在有些場(chǎng)景如拖動(dòng)可能會(huì)因?yàn)橥ㄐ蓬l繁導(dǎo)致卡頓。
- JavaScript為腳本語(yǔ)言，執(zhí)行時(shí)需要JIT(Just In Time)，執(zhí)行效率和AOT(Ahead Of Time)代碼仍有差距。
- 由于渲染依賴原生控件，不同平臺(tái)的控件需要單獨(dú)維護(hù)，并且當(dāng)系統(tǒng)更新時(shí)，社區(qū)控件可能會(huì)滯后；除此之外，其控件系統(tǒng)也會(huì)受到原生UI系統(tǒng)限制，例如，在Android中，手勢(shì)沖突消歧規(guī)則是固定的，這在使用不同人寫的控件嵌套時(shí)，手勢(shì)沖突問題將會(huì)變得非常棘手。
2.3、自繪UI+原生
??自繪UI+原生是通過在不同平臺(tái)實(shí)現(xiàn)一個(gè)統(tǒng)一接口的渲染引擎來繪制UI，而不依賴系統(tǒng)原生控件，所以可以做到不同平臺(tái)UI的一致性。
QT for Mobile
??QT是一個(gè)1991年由Qt Company開發(fā)的跨平臺(tái)C++圖形用戶界面應(yīng)用程序開發(fā)框架。2014年4月，跨平臺(tái)集成開發(fā)環(huán)境Qt Creator 3.1.0正式發(fā)布，實(shí)現(xiàn)了對(duì)于iOS的完全支持，新增WinRT、Beautifier等插件，廢棄了無Python接口的GDB調(diào)試支持，集成了基于Clang的C/C++代碼模塊，并對(duì)Android支持做出了調(diào)整，至此實(shí)現(xiàn)了全面支持移動(dòng)端開發(fā)。
優(yōu)點(diǎn)：
- 性能高；由于自繪引擎是直接調(diào)用系統(tǒng)API來繪制UI，所以性能和原生控件接近。
- 靈活、組件庫(kù)易維護(hù)、UI外觀保真度和一致性高；由于UI渲染不依賴原生控件，也就不需要根據(jù)不同平臺(tái)的控件單獨(dú)維護(hù)一套組件庫(kù)，所以代碼容易維護(hù)。由于組件庫(kù)是同一套代碼、同一個(gè)渲染引擎，所以在不同平臺(tái)，組件顯示外觀可以做到高保真和高一致性；另外，由于不依賴原生控件，也就不會(huì)受原生布局系統(tǒng)的限制，這樣布局系統(tǒng)會(huì)非常靈活。
不足：
- 動(dòng)態(tài)性不足；為了保證UI繪制性能，自繪UI系統(tǒng)一般都會(huì)采用AOT模式編譯其發(fā)布包，所以應(yīng)用發(fā)布后，不能像Hybrid和RN那些使用JavaScript（JIT）作為開發(fā)語(yǔ)言的框架那樣動(dòng)態(tài)下發(fā)代碼。
- 開發(fā)效率低：QT使用C++作為其開發(fā)語(yǔ)言，而編程效率是直接會(huì)影響APP開發(fā)效率的，C++作為一門靜態(tài)語(yǔ)言，在UI開發(fā)方面靈活性不及JavaScript這樣的動(dòng)態(tài)語(yǔ)言，另外，C++需要開發(fā)者手動(dòng)去管理內(nèi)存分配，沒有JavaScript及Java中垃圾回收（GC）的機(jī)制。
但QT在移動(dòng)端發(fā)力較晚，且官方推廣不利，支持不夠，導(dǎo)致其移動(dòng)開發(fā)社區(qū)太小，學(xué)習(xí)資料不足，生態(tài)不好。
Flutter
??Flutter是Google發(fā)布的一個(gè)用于創(chuàng)建跨平臺(tái)、高性能移動(dòng)應(yīng)用的框架。Flutter和QT mobile一樣，都沒有使用原生控件，相反都實(shí)現(xiàn)了一個(gè)自繪引擎，使用自身的布局、繪制系統(tǒng)。目前Flutter活躍用戶正在高速增長(zhǎng)，文檔、資源也越來越豐富，開發(fā)過程中遇到的很多問題都可以在Stackoverflow或其github issue中找到答案。
