移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)選型策略

史兆彥, 李 翔

(中遠(yuǎn)海運(yùn)科技股份有限公司，上海 200135)

0 引 言

移動(dòng)硬件技術(shù)、移動(dòng)通信技術(shù)和互聯(lián)網(wǎng)技術(shù)的迅猛發(fā)展使得移動(dòng)應(yīng)用得到迅速普及和快速發(fā)展。據(jù)統(tǒng)計(jì)[1]，截至2017年底，每個(gè)智能手機(jī)用戶的平均APP數(shù)量達(dá)到40個(gè)以上，平均每天花費(fèi)在各類APP上的時(shí)間達(dá)到約4.2 h。因此，對(duì)于企業(yè)品牌的宣傳、產(chǎn)品的推廣和服務(wù)的擴(kuò)展而言，除了開(kāi)發(fā)傳統(tǒng)的管理系統(tǒng)和網(wǎng)站以外，移動(dòng)用戶的接入是企業(yè)應(yīng)用無(wú)法忽略的重要組成部分[2]。

然而，移動(dòng)設(shè)備(特別是手機(jī))操作系統(tǒng)的不同使得開(kāi)發(fā)移動(dòng)應(yīng)用的技術(shù)不盡相同。對(duì)于企業(yè)而言，面對(duì)諸多的應(yīng)用類型和開(kāi)發(fā)技術(shù)，沒(méi)有現(xiàn)成的指導(dǎo)策略可供參考。因此，本文對(duì)移動(dòng)應(yīng)用的分類、開(kāi)發(fā)模式、技術(shù)路線和開(kāi)發(fā)團(tuán)隊(duì)等因素進(jìn)行相關(guān)探討，為企業(yè)移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)選型提供策略參考。

1 移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)的發(fā)展現(xiàn)狀

根據(jù)NETMAKETSHARE的統(tǒng)計(jì)數(shù)據(jù)[3]，Android和iOS已占據(jù)手機(jī)操作系統(tǒng)98%以上的市場(chǎng)。由于Android和iOS的開(kāi)發(fā)技術(shù)完全不同，早期很多企業(yè)必須針對(duì)這2個(gè)平臺(tái)開(kāi)發(fā)具有相同功能的APP，會(huì)耗費(fèi)大量的人力和財(cái)力資源，增加開(kāi)發(fā)和維護(hù)成本。

為解決該“不一致”帶來(lái)的問(wèn)題，出現(xiàn)諸多跨平臺(tái)的移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)，其中基于HTML5的移動(dòng)開(kāi)發(fā)技術(shù)得到廣泛認(rèn)可，即開(kāi)發(fā)一套移動(dòng)Web頁(yè)面，用戶可通過(guò)瀏覽器訪問(wèn)移動(dòng)Web頁(yè)面，但系統(tǒng)的性能和用戶體驗(yàn)與原生應(yīng)用(Native APP)有本質(zhì)上的差別。在此情況下，基于HTML5的混合移動(dòng)開(kāi)發(fā)技術(shù)(Hybrid APP)開(kāi)始出現(xiàn)，其本質(zhì)是將一個(gè)Web應(yīng)用嵌入到Native APP中。然而，Hybrid APP的性能與Native APP依然有著不小的差距，“用戶體驗(yàn)”的更高要求催生出新的跨平臺(tái)移動(dòng)開(kāi)發(fā)技術(shù)，以React Native技術(shù)為代表的基于JavaScript的Native開(kāi)發(fā)技術(shù)應(yīng)運(yùn)而生，其本質(zhì)是在APP運(yùn)行時(shí)通過(guò)JavaScript調(diào)用原生功能完成操作，性能幾乎與Native APP相同；同時(shí)，統(tǒng)一的開(kāi)發(fā)語(yǔ)言、一次編寫、分別編譯和多端運(yùn)行等特性使得跨平臺(tái)移動(dòng)應(yīng)用開(kāi)發(fā)方面的問(wèn)題幾乎能全部解決。

2 移動(dòng)應(yīng)用開(kāi)發(fā)模式的分類比較

目前應(yīng)用程序基本上分為4種模式，其中：第一種是需安裝的Native APP模式；第二種是借助手機(jī)瀏覽器運(yùn)行的網(wǎng)頁(yè)應(yīng)用(Web APP)模式；第三種是融合上述2種模式得到的混合模式(Hybrid APP)，這種APP雖然也需獨(dú)立安裝，但部分功能是借助內(nèi)置瀏覽器Web頁(yè)面運(yùn)行的。近年來(lái)，隨著移動(dòng)應(yīng)用用戶的大量累積，有些移動(dòng)應(yīng)用本身轉(zhuǎn)變成了應(yīng)用平臺(tái)，在此基礎(chǔ)上發(fā)展出基于特定應(yīng)用擴(kuò)展方式的寄生模式，即無(wú)需獨(dú)立安裝新的應(yīng)用，依賴于特定的應(yīng)用環(huán)境運(yùn)行，如支付寶應(yīng)用和微信小程序等。表1為這些移動(dòng)應(yīng)用類型的對(duì)比[4-6]。

3 移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)棧的分類比較

不同的移動(dòng)應(yīng)用類型在實(shí)現(xiàn)方式上對(duì)應(yīng)著不同的應(yīng)用開(kāi)發(fā)技術(shù)棧，主要包括傳統(tǒng)模式、Bridge模式和寄生模式等3種。

3.1 傳統(tǒng)模式的技術(shù)棧

與傳統(tǒng)PC應(yīng)用開(kāi)發(fā)模式類似，針對(duì)不同應(yīng)用類型采取不同的開(kāi)發(fā)方案。Native模式對(duì)應(yīng)Native APP的開(kāi)發(fā)，需針對(duì)不同的平臺(tái)使用不同的開(kāi)發(fā)語(yǔ)言和工具,乃至設(shè)備。Web模式對(duì)應(yīng)Web APP的開(kāi)發(fā)，使用HTML5等Web開(kāi)發(fā)技術(shù)實(shí)現(xiàn)，針對(duì)移動(dòng)設(shè)備的特點(diǎn)，一般采用適于移動(dòng)設(shè)備的前端Web框架或基礎(chǔ)組件庫(kù)。Hybrid模式對(duì)應(yīng)Hybrid APP的開(kāi)發(fā)，使用Web技術(shù)和少量的Native技術(shù)實(shí)現(xiàn)。國(guó)內(nèi)的AppCan框架是一個(gè)比較出色的Hybrid框架[10];Ionic是當(dāng)前廣泛采用的Hybrid框架，通過(guò)Cordova將一個(gè)Web應(yīng)用嵌入到Native APP中。

3.2 Bridge模式的技術(shù)棧

Bridge模式是使用第三方開(kāi)發(fā)語(yǔ)言編寫Native APP的方式,本文為區(qū)分與Hybrid APP實(shí)現(xiàn)方式的差異，將其稱為Bridge模式。該模式的實(shí)現(xiàn)思想在Hybrid APP的設(shè)計(jì)中就已形成。在Hybrid APP中,Web頁(yè)面與Native之間存在一種稱為JSBridge的通信機(jī)制，可實(shí)現(xiàn)Web頁(yè)面與Native功能的互操作；Bridge模式將其進(jìn)一步發(fā)展，摒棄使用Web View渲染的做法，改用Bridge的方式調(diào)用原生功能，使用一種語(yǔ)言編寫跨平臺(tái)APP，抽象出與平臺(tái)無(wú)關(guān)的業(yè)務(wù)代碼實(shí)現(xiàn)通用，基本上實(shí)現(xiàn)“一次編寫，分別編譯，多端運(yùn)行”的開(kāi)發(fā)部署模式。Bridge模式目前有2種代表性的實(shí)現(xiàn)方案，即基于C#的Xamarin方案和基于JavaScript的Native解決方案。

1) 基于C#的Xamarin跨平臺(tái)移動(dòng)開(kāi)發(fā)解決方案[7]由Mono發(fā)展而來(lái)，Xamarin包含Xamarin.Android、Xamarin.iOS和Xamarin.Forms，其本質(zhì)上是對(duì)原生API做一層C#的封裝。Xamarin的開(kāi)發(fā)思路是使用C#完成通用的、與平臺(tái)無(wú)關(guān)的邏輯部分，針對(duì)不同平臺(tái)UI和交互方式，使用API訪問(wèn)和操控Native組件，實(shí)現(xiàn)不同平臺(tái)的UI開(kāi)發(fā)。

2) 基于JavaScript的Native開(kāi)發(fā)技術(shù)是使用JavaScript,通過(guò)JSBridge調(diào)用原生組件。不同于Hybrid使用Web View,該模式的頁(yè)面代碼由JavaScript 引擎處理，并管理渲染Native視圖，調(diào)用原生 API 和用戶交互。該模式的代表是Facebook的React Native技術(shù)[8]。國(guó)內(nèi)阿里巴巴的Weex也采用這種技術(shù)路線[9]，其在頁(yè)面渲染上跳出瀏覽器環(huán)境, 既擁有原生Native的交互體驗(yàn)，又能保持Web高效和靈活的特點(diǎn)，支持跨平臺(tái),通過(guò)JavaScript調(diào)用原生平臺(tái)標(biāo)準(zhǔn)組件，使APP獲得平臺(tái)一致的效果和體驗(yàn)，有著媲美Native的性能和流暢性。

表1 移動(dòng)應(yīng)用類型對(duì)比

3.3 寄生模式的技術(shù)棧

寄生模式主要實(shí)現(xiàn)基于宿主APP的功能擴(kuò)展開(kāi)發(fā)，依賴于宿主APP本身的功能。以微信公眾平臺(tái)[11]為例，分為微頁(yè)面模式和小程序模式，2種模式都是基于微信的跨平臺(tái)方案。

1) 微信服務(wù)號(hào)和訂閱號(hào)除了提供交互轉(zhuǎn)發(fā)服務(wù)以外，還提供頁(yè)面嵌入功能，在開(kāi)發(fā)頁(yè)面時(shí)，可調(diào)用微信API實(shí)現(xiàn)部分原生功能，頁(yè)面代碼運(yùn)行在微信內(nèi)置的瀏覽器中，這種方式可看作是基于微信的Hybrid模式。

2) 微信小程序使用JSBridge,通過(guò)微信調(diào)用本地資源，在體驗(yàn)上優(yōu)于訂閱號(hào)和服務(wù)號(hào)，具有Native APP體驗(yàn)。小程序開(kāi)發(fā)框架提供有視圖層描述語(yǔ)言WXML和WXSS及基于JavaScript的邏輯層框架，并在視圖層與邏輯層之間提供有數(shù)據(jù)傳輸和事件系統(tǒng)，這種方式可看作是基于微信的Bridge模式。

3.4 開(kāi)發(fā)模式的技術(shù)棧比較

開(kāi)發(fā)模式并沒(méi)有優(yōu)劣之分，選擇哪種開(kāi)發(fā)模式與企業(yè)產(chǎn)品的要求、產(chǎn)品定位、開(kāi)發(fā)周期和團(tuán)隊(duì)技術(shù)人員的技術(shù)積累有很大關(guān)系。企業(yè)需根據(jù)自身?xiàng)l件進(jìn)行選擇，表2為移動(dòng)開(kāi)發(fā)模式的技術(shù)棧比較。

表2 移動(dòng)開(kāi)發(fā)模式的技術(shù)棧比較

4 移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)選型策略

移動(dòng)應(yīng)用的類型選擇確定了其開(kāi)發(fā)模式，開(kāi)發(fā)模式的確定影響著技術(shù)棧的選擇，技術(shù)棧的選擇影響著開(kāi)發(fā)團(tuán)隊(duì)的建設(shè)；反之，開(kāi)發(fā)團(tuán)隊(duì)的技術(shù)積累會(huì)影響技術(shù)選型和開(kāi)發(fā)模式，進(jìn)而影響移動(dòng)應(yīng)用的類型選擇。

4.1 移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)棧參考架構(gòu)

移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)棧主要是框架和組件庫(kù)的選型，架構(gòu)師的主要工作已從原來(lái)的實(shí)現(xiàn)技術(shù)框架(加法)轉(zhuǎn)變?yōu)閺暮Ａ考夹g(shù)中選擇最合適的技術(shù)組件(減法)。企業(yè)的移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)需對(duì)移動(dòng)應(yīng)用的類型和技術(shù)領(lǐng)域進(jìn)行分析，結(jié)合團(tuán)隊(duì)自身的技術(shù)積累和可能的投入總結(jié)出一套應(yīng)對(duì)移動(dòng)開(kāi)發(fā)模式的技術(shù)棧。圖1為移動(dòng)開(kāi)發(fā)技術(shù)棧參考模型，針對(duì)不同類型的開(kāi)發(fā)模式，給出相應(yīng)的技術(shù)選擇域，對(duì)技術(shù)團(tuán)隊(duì)建設(shè)具有指導(dǎo)意義。

技術(shù)棧模型選擇以React Native技術(shù)為核心，同時(shí)融合HTML5的移動(dòng)前端解決方案，兼顧微信平臺(tái)的開(kāi)發(fā)，具有以下特點(diǎn)：

1) React Native采用JavaScript語(yǔ)言，前端開(kāi)發(fā)人員可通過(guò)培訓(xùn)快速投入開(kāi)發(fā)；

2) 跨移動(dòng)平臺(tái)適配能力，基于React Native，通過(guò)封裝或引入基礎(chǔ)組件形成基礎(chǔ)組件庫(kù)，實(shí)現(xiàn)“一次編寫，分別編譯，多端運(yùn)行”的跨平臺(tái)目標(biāo)；

3) React Native的機(jī)制能實(shí)現(xiàn)與Native APP的集成和代碼混編，為集成歷史組件和應(yīng)對(duì)性能需求提供實(shí)現(xiàn)方式；

4) 為應(yīng)對(duì)快速變化的場(chǎng)景，參照Hybrid APP的思想提出RN Bridge的思路，融合前端開(kāi)發(fā)技術(shù)，使用基于React Native的Web View渲染可變更界面，UI混搭取長(zhǎng)補(bǔ)短，發(fā)揮Native和HTML5各自的優(yōu)勢(shì)應(yīng)對(duì)功能頻繁變更的需求；

5) 微信平臺(tái)的開(kāi)發(fā)依賴于微信的接口，經(jīng)過(guò)適配，訂閱號(hào)和服務(wù)號(hào)的開(kāi)發(fā)可共用RN Bridge的Web頁(yè)面。

4.2 選型策略參考模型

針對(duì)移動(dòng)開(kāi)發(fā)諸多的模式選擇和技術(shù)棧，如何找到最適合本企業(yè)的開(kāi)發(fā)技術(shù)是移動(dòng)開(kāi)發(fā)團(tuán)隊(duì)最關(guān)心的問(wèn)題。圖2為選型策略參考模型，使用決策樹(shù)模式展示。企業(yè)可根據(jù)自身團(tuán)隊(duì)的特點(diǎn)和技術(shù)積累，參照參考模型選擇技術(shù)棧。圖2中，箭頭上的條件決定著選擇路徑的走向。參考模型中并未囊括所有的選擇可能和開(kāi)發(fā)技術(shù)，可根據(jù)實(shí)際條件和技術(shù)偏好添加或移除相關(guān)分支。

參考模型將應(yīng)用類型、開(kāi)發(fā)模式和實(shí)現(xiàn)技術(shù)結(jié)合起來(lái)，從高層級(jí)的應(yīng)用類型分類到低層級(jí)實(shí)現(xiàn)技術(shù)，清晰展示了技術(shù)選型的路徑走向。

4.3 選型的綜合因素

技術(shù)因素與技術(shù)團(tuán)隊(duì)的建設(shè)互為影響，技術(shù)選型影響著開(kāi)發(fā)團(tuán)隊(duì)的技術(shù)組成和技術(shù)積累，同時(shí)團(tuán)隊(duì)現(xiàn)有的技術(shù)積累和人員配置又影響著技術(shù)選型。企業(yè)在做移動(dòng)應(yīng)用時(shí)，通常需同時(shí)考慮用戶對(duì)應(yīng)用的功能性和非功能性需求指標(biāo), 而非單純的技術(shù)因素，下面對(duì)一些影響選型的限制因素進(jìn)行分析。

1) 平臺(tái)要求：應(yīng)用運(yùn)行的目標(biāo)平臺(tái)確定針對(duì)平臺(tái)差異采取的應(yīng)對(duì)策略，確定是選擇使用針對(duì)平臺(tái)的差異化開(kāi)發(fā)的原生技術(shù)還是跨平臺(tái)技術(shù)。

2) 性能要求：性能要求越高，對(duì)硬件的利用和操控能力的要求越高，調(diào)用底層的中間步驟就要越少?？缙脚_(tái)的解決方案幾乎都是以損失性能換取的，但跨平臺(tái)的優(yōu)勢(shì)同樣非常明顯。

3) UI交互模式：對(duì)于不同的操作系統(tǒng)，UI交互的特點(diǎn)不完全一致，需考慮在交互模式上是采用多平臺(tái)一致的模式還是采用契合不同平臺(tái)的交互特點(diǎn)的方式。

4) 投入成本：采用不同的技術(shù)實(shí)現(xiàn)同樣的功能所需的人力成本和時(shí)間成本是不同的。

5) 研發(fā)周期：時(shí)間因素是項(xiàng)目的一個(gè)重要影響因素，研發(fā)周期越長(zhǎng)，越有時(shí)間研究，但大多數(shù)項(xiàng)目都是盡量壓縮工期。因此，在保證其他因素盡量不受影響的前提下,采用最快的開(kāi)發(fā)模式是第一選擇。

6) 變更頻度：Native程序很難實(shí)現(xiàn)在線更新，應(yīng)用變更越頻繁，越傾向選擇能在線更新的開(kāi)發(fā)模式,甚至是Web方式。

7) 業(yè)務(wù)類型：業(yè)務(wù)類型不同，應(yīng)用的受眾不同，推廣模式也不相同，若非必要，用戶更傾向于不安裝新的APP。因此，若要快速推廣，借助現(xiàn)有的微信公眾平臺(tái)或支付寶擴(kuò)展程序是可行的。

8) 團(tuán)隊(duì)技術(shù)儲(chǔ)備：現(xiàn)有開(kāi)發(fā)人員的技術(shù)儲(chǔ)備往往影響著應(yīng)用實(shí)現(xiàn)技術(shù)的選擇，前端開(kāi)發(fā)人員會(huì)選擇與前端開(kāi)發(fā)相近的技術(shù)。同樣，技術(shù)的選擇影響著團(tuán)隊(duì)人才隊(duì)伍的建設(shè)。

9) 社區(qū)資源：遇到的問(wèn)題能否通過(guò)社區(qū)資源得到解決，一般流行程度越高的框架，獲得答案的可能性越大。

這些影響選型的因素可歸類為目標(biāo)環(huán)境(平臺(tái)、性能和UI交互)、成本約束(成本、研發(fā)周期)、業(yè)務(wù)需求(業(yè)務(wù)類型、更新頻度)和技術(shù)儲(chǔ)備(團(tuán)隊(duì)儲(chǔ)備、社區(qū)資源)等，開(kāi)發(fā)團(tuán)隊(duì)需根據(jù)需求識(shí)別出核心的影響因素，選定應(yīng)用類型，進(jìn)而綜合考慮其他因素，參照選型策略參考模型選擇開(kāi)發(fā)模式和具體的實(shí)現(xiàn)技術(shù)。

5 結(jié) 語(yǔ)

本文基于“沒(méi)有最好的技術(shù)，只有最適合的技術(shù)”的思路，給出一種選型策略參考模型。移動(dòng)應(yīng)用開(kāi)發(fā)技術(shù)的選型是一個(gè)多因素權(quán)衡的過(guò)程，本文僅提供一種基于開(kāi)發(fā)技術(shù)的選型思路。面對(duì)眾多的開(kāi)源組件和框架，開(kāi)發(fā)人員需有效識(shí)別需求，選擇最適合的開(kāi)發(fā)技術(shù)，完成開(kāi)發(fā)模式和技術(shù)棧選型。